Ask most developers about the part of the job they enjoy least and debugging tends to come up quickly. It is the unglamorous work. The retracing, the narrowing down, the sitting with a problem that refuses to explain itself. However, it’s still necessary. And as a matter of fact, Nupur on our team enjoys it.
That says something about how she got here. Nupur Patel joined Lane Four as a QA, which meant she spent her first stretch with us testing other people’s Apex classes, validation rules, and automations. She learned the platform from the direction most developers only encounter after the fact, which is the point where things break. Today, as a Salesforce Developer and Senior Automation Specialist, she builds the custom side of our client solutions: Lightning Web Components, Apex classes, Experience Cloud sites, and the API integrations that connect Salesforce to the rest of a client’s stack. And she still writes code the way a tester reads it.
We sat down with Nupur to talk about her move from QA into development, the technical constraints she designs around every day, how she keeps quality from becoming the thing that slows a project down, and of course, how she connects with life at Lane Four.
After solely being in a QA role at Lane Four, what drew you to expanding into development, and was there a specific area you wanted to build your expertise in?
Nupur Patel: “When I was first hired at Lane Four, I came in as QA. In that role I was working with the devs, of course, but I was also working with consultants, admins, and delivery leads, and I was regularly testing Apex classes, validation rules, and automations. Seeing how those solutions were actually designed is what sparked my curiosity about the development side of Salesforce.
I already had a bachelor’s degree in computer science and information technology, so I had a strong programming foundation. I was just very curious to apply those skills in a development role. I really appreciate Lane Four for that, because we have a culture that encourages people to learn and grow, and I was given the opportunity to make that transition.
Moving from QA into development, I brought a testing mindset with me while also keeping in mind that I now had to build solutions that were scalable and user friendly. Early on, I wanted to focus specifically on Lightning Web Components, Salesforce API integrations, Experience Cloud sites, and Apex. Looking back now, having a QA background has made me a more thoughtful developer. I naturally consider edge cases, usability, maintainability, and testing while I am writing my own code.”
What are some of the technical challenges that come up again and again when you’re working with clients, and how do you typically approach solving them?
Nupur Patel: “A few come up constantly. The biggest one is designing around Salesforce governor limits. For example, there is a limit of 100 SOQL queries and 150 DML statements per transaction. So while I am writing code, I make sure it is bulkified and that I am moving SOQL and DML operations outside of loops to stay within those limits. Using collections like lists, maps, and sets really helps here, because it lets us handle both single records and large data volumes through the same code.
Next is complex business processes. A lot of clients have multi-step workflows that exceed synchronous processing limits. In those cases we use asynchronous Apex; so Queueable, Batch, or Scheduled Apex, which lets us process large data sets while staying inside the platform’s transaction limits.
Finally there is scalability and maintainability. When we design a solution, we are designing for future growth, which means following Salesforce best practices, writing reusable modular code, and implementing proper error handling and logging. That is what makes the automation easier to maintain later. You can troubleshoot it quickly and extend it as the business requirements evolve.”
When you’re scoping out an automation solution, how much of your thinking is about the technical build itself versus the bigger business problem it’s solving for the client?
Nupur Patel: “I always focus on the business problem first, before I start thinking about the technical implementation. I try to understand what the client is trying to achieve, what their current process looks like, and where their pain points actually are.
Once I have that clear understanding, I have what I need to find the best solution. It also makes the build better, because a solution designed around the real problem ends up being more scalable, more aligned to best practices, and easier to maintain.
A technical solution is important, but it is only successful if it actually solves the client’s business problem and makes their processes more efficient.”
Testing and automation tools shift constantly. How do you keep pace with what’s changing, and has something you picked up recently actually reshaped how you approach a build?
Nupur Patel: “I keep learning as part of my routine. I stay up to date with the Salesforce release notes, follow the developer community, use Trailhead, and watch videos or read blog posts to keep track of new features and best practices. I also have a naturally curious mindset, so when a new feature comes out I will usually spin up a developer edition org and implement it there just to see how it actually works.
In terms of something that has reshaped how I work, it would have to be AI (of course). Since we started using AI tools like Agentforce Vibes, they have taken some of the repetitive load off a specific part of my work. I used to write all of my Apex unit tests manually, which is time consuming because it is a lot of code. Now I can generate test classes, improve code coverage, and catch edge cases much faster. I still review and validate everything that gets generated, because knowing whether a test is actually meaningful is the part that takes experience.
We also have a monthly knowledge sharing session across the whole Development team, which helps a lot. Everyone brings something to the table, whether it is something unique you built for a client that month, something new you learned, or a use case like how you are using AI day-to-day to be more effective. We all discuss it, ask questions, and share opinions. It is really valuable to have that space.”
Before anything reaches a client, what does your testing process actually look like?
Nupur Patel: “It usually starts with unit testing, which is testing the small individual pieces of functionality you are building. Then we move to integration testing to make sure the different components, so Flows, Apex, and external integrations, all work together correctly. After that we do end to end testing, which validates the complete business process from start to finish. And finally we support the client with user acceptance testing, where they validate that the solution meets their business requirements. Throughout all of it we are also testing edge cases and error-prone scenarios to make sure the data stays reliable.
Code review depends on the client. For some clients, I develop the code, it merges into their GitHub branch, and someone from their team reviews and approves the changes before it moves to a sandbox for testing. For others, we handle it internally. I write the Apex unit tests and confirm code coverage, and then one of our own consultants or admins goes in and tests the functionality.”
Is there a project where your testing or automation work played a meaningful role in how the client experienced the final result?
Nupur Patel: “There are a few I am proud of, but one in particular stands out. It involved complex CPQ features like MDQ (Multi-Dimensional Quoting), invoice schedules, and decoupling, so we had to thoroughly test the quotes, quote lines, and billing schedules, along with the invoices that would feed downstream into NetSuite for invoicing, across a range of different pricing scenarios.
We wrote custom Apex classes for it, and I wrote comprehensive Apex unit tests that covered real world client scenarios, alongside the integration testing and UAT support. That level of testing made deployment much smoother, because we caught issues before they reached production.
The part I appreciate most is that it is still paying off. Even today, when we update those classes to add new changes or fix a bug, those unit tests act as a safety net for catching regressions early.”
You work closely with consultants in an agile environment, often juggling different priorities and timelines. How do you navigate that, and how do you keep QA from becoming a bottleneck?
Nupur Patel: “It comes down to good time management and clear communication. I usually plan my day either the evening before or first thing in the morning, so I know exactly which projects and tasks I need to focus on. Then I communicate my availability and progress to the consultants and admins I am working with, so everyone has clear expectations. Priorities do change often in an agile environment, so I stay flexible enough to reprioritize while still making sure deadlines are met.
On the bottleneck side, my approach is to catch as many issues as possible before I hand anything over. I write the Apex unit tests to cover the functionality, and once the solution is built I test it end-to-end in a sandbox using real customer data and different business scenarios, so I can validate that the automation behaves the way it is supposed to.
Doing that before it reaches the consultant makes everything much smoother downstream. There are fewer defects and much less back and forth between us.”
Coaching others on QA means translating your instincts into something people who aren’t developers can actually use. How do you approach that kind of teaching?
Nupur Patel: “I keep my explanations as simple as possible. Instead of walking someone through the technical implementation I built, I walk them through what the solution is supposed to do from the user’s perspective.
I give them clear test scenarios, the expected outcomes, and the edge cases they should validate. I also encourage them to ask me questions, and I explain the reasoning behind the current behaviour, so they understand not just what to test but why they are testing it.
If it makes things easier for them, I will attach screenshots, a quick demo video, or links to test data. Having a clear reference makes the testing process much more manageable, especially for people who are not developers.”
Automation work often needs long, uninterrupted focus, but you’re also expected to stay available for the team. How do you protect time for deep, focused building without leaving people waiting on you?
Nupur Patel: “When I am working on something that needs deep focus, I block out uninterrupted hours on my calendar and let the team know on Slack that I am going to be heads down. But I do not disappear. I still keep an eye on Slack and email in case something is genuinely urgent.
I also try to batch my meetings and smaller tasks together, so that later in the day I have dedicated time for development. If someone needs help during that window, I respond as soon as I can or let them know when I will be available. And if it is a production issue or something business critical, I am always happy to pause what I am doing and jump in.
It is about finding the balance between staying productive and being a reliable teammate.”
What’s something about working on this team that you find genuinely enjoyable; something that might not be obvious from the outside?
Nupur Patel: “A couple of things. The first is the dynamic nature of the work and the problem solving. We work with multiple clients, and no two clients are the same. Even though we are all working in Salesforce, every client has different processes, different challenges, and different goals. That keeps the work interesting, because you are constantly learning from different industries and finding creative solutions to problems that are specific to them.
The second one is a little unusual, but I actually enjoy debugging complex issues. I like breaking a problem down step-by-step until I find the root cause. It feels like solving a puzzle, and it is really satisfying when everything finally clicks.”
You’ve also been an active contributor to Lane Four’s Women in Tech and Business program. What has that involvement looked like for you, and why has it been important to you to stay engaged with it?
Nupur Patel: “What I really enjoy about Women in Tech and Business is that it lets you step away from your day-to-day work and hear different perspectives. As developers, we spend a lot of time focused on code and technical problems, so it is refreshing to have those conversations and meet colleagues you do not normally work with. It is a great way to build relationships across the company, and I always walk away from a session with a new idea or a different way of thinking.
I also enjoy the collaboration behind the scenes. There’s a team of us that plans the sessions together. Someone sets the direction for the year, and the rest of us pitch in ideas, recommend a book or a podcast that could be meaningful to discuss with the community, or flag something else that has recently come up and is worth looking into. Once we have a direction, we get together to build out the session itself, whether that is a slide deck or creative exercises for the group.
Working that closely with the group on the planning side has been a great experience. We bounce ideas off each other and figure out how to make the sessions more meaningful for everyone.”
Which Lane Four value do you find yourself leaning on most in your day-to-day work, and why?
Nupur Patel: “I honestly could not pick just one, so I will say two: ‘Be curious’ and ‘Own it and do good work.’
‘Be curious’ because I genuinely enjoy learning new features, exploring different ways to solve a problem, and continuously improving my skills. I am naturally curious, so I like digging into problems, asking questions, and understanding the why behind a solution.
‘Own it and do good work’ because once I take on a task, I treat it as my responsibility from start to finish. I make sure the code works, that it is thoroughly tested, that it meets the requirements, and that it is something I can confidently put my name behind. I want to deliver high quality, reliable work, not just for our team but for our clients, so they can count on us.”
For someone earlier in their career hoping to grow into a developer or automation-focused role, what advice would you give them?
Nupur Patel: “Be curious, and do not be afraid to ask questions. There is no such thing as a bad question when you are learning.
Take every challenge that comes your way as an opportunity to grow. Give yourself the time to understand how things actually work, because that is how you build a new skill set.
And whenever you learn something new, share it with others. It helps your teammates, but it also reinforces your own understanding and builds your confidence as a developer.”
The clearest measure of Nupur’s work is not any single task, alone, that she delivers. It is the test that catches a regression months later, on a build someone else is now maintaining. It is the consultant who picks up her solution and knows exactly what to check and why. It is the deployment that went smoothly enough that nobody thought to mention it.
That kind of quality is easy to overlook, precisely because it works. But it is what lets a delivery team move quickly without quietly accumulating risk, and it tends to come from people who learned early to look for the edge case before it finds them. Curiosity and ownership, the two values Nupur landed on, are not separate instincts in her case. One is why she keeps digging. The other is why she keeps checking.
Rigour like this is not a bonus on our projects. It is the standard, and it is what your team would be working with. Let’s chat!
Let's chat!
