Boris MasnecWe built in roughly six months what we estimate would have taken at least 18–24 months through our conventional development process.
And we still finished 40 days later than originally planned.
The 18–24 month figure is a retrospective engineering estimate, not a controlled productivity measurement. We didn’t build the same product twice, so I don’t think it would be fair to turn that estimate into a claim that agentic development made us three or four times faster.
What I find more interesting is why we were late despite having substantially more development capacity than we were used to.
We didn’t use that capacity primarily to finish the original product faster. We kept using it to change the product as we learned what users actually needed.
The difference between what we planned in September 2025 and what reached production in May 2026 taught me more than the productivity number did.
We started with two questions
Customer interviews had identified routing and scheduling as major pain points.
As we studied how customers actually planned field operations, we realized there was a dependency we couldn’t ignore. Efficient routing and scheduling depend on reasonably well-designed territories.
So we deliberately reduced the initial scope. We would solve territory planning first and add routing and scheduling later.
At the same time, we had a completely different question.
We had been experimenting with AI-assisted development and working with our engineering teams on agentic coding. There was interest, but also reasonable skepticism. Could coding agents really handle complex production development on top of a mature SaaS platform?
I didn’t know, and I didn’t think another demo or prototype would answer that question. We decided to use Territory Planner to find out.
By early November, we had a small dedicated team: one developer, one manual tester, a part-time Product Manager, a part-time Engineering Manager, and me moving between architecture, development, product and whatever else was needed.
For this project, developers wouldn’t write production code manually. We would build it through coding agents.
The original product hypothesis lasted until internal testing
Our initial product was fairly structured.
Analyze the current territory setup. Identify problems. Configure the optimization. Generate recommendations. Review them. Export the proposed changes.
Our early technical prototypes had already taught us some important boundaries. Calculations, data preparation and optimization moved into deterministic software. AI increasingly became the interface to those capabilities rather than their replacement.
The coding experiment was changing too.
We learned quickly that generating code wasn’t particularly difficult. Getting an agent to make the right change in an existing system was harder. The result depended heavily on the context we provided before implementation and on how we verified the result afterwards.
Those lessons eventually became our Planning → Implementation → Verification approach.
Then internal testing started in the second half of December, with people from Product, Customer Success, Professional Services and Sales.
They didn’t use the product quite the way we expected.
Instead of starting with optimization, they explored. They asked about costs, places that hadn’t been visited enough, rep performance and anomalies in their data.
One of the early questions was essentially:
“I need to cut my expenses by 20%. How can I achieve this?”
Our product hypothesis had been centered on helping users optimize territories. The people testing it were first trying to understand what was happening in their business.
Supporting that wasn’t a small UX adjustment. Open-ended exploration of business data was a substantial new capability and, under our conventional development model, adding it at this point would have been a significant scope decision.
By then, however, the agentic development experiment had changed the cost of making that decision. We decided to build it and see what happened.
The product started changing faster
Alpha testing started in mid-January.
Customers repeated much of the behavior we’d seen internally. They explored their data, validated their setup and investigated problems before they were ready to optimize anything.
Supporting that behavior created longer and less predictable conversations, which exposed limitations in our single-agent architecture. Users moved between optimization, data exploration and configuration, while expecting the system to preserve the relevant context.
We eventually introduced specialized agents, separated different kinds of context and memory, and strengthened how AI responses were grounded in data.
This wasn’t part of the original architecture. We made those changes because actual usage was showing us where the simpler architecture stopped working.
The new architecture supported more complex conversations, and those conversations exposed additional product needs. Users started bringing day-to-day operational problems into the system. They asked about temporary opportunities, rep performance, short-term changes and more flexible ways of working with territories.
There wasn’t a clean separation between product discovery and technical implementation anymore.
A product change led to different user behavior. That behavior exposed an architectural limitation. Fixing the limitation enabled users to do something else, which often gave us the next product problem to think about.
- Users behave
differently - Product changes
- Implementation /
architecture changes - New capability
reaches users - Users do more
That cycle happened several times during the project.
The product we shipped wasn’t the product we estimated
By Beta at the end of February, we were no longer simply building a more complete version of what we had scoped in September.
Some things we had expected to matter did improve the product but didn’t seem to influence buying decisions very much. Improvements to optimization settings and the Territory Health experience, for example, made the product clearer without becoming decisive reasons to buy.
Other capabilities became blockers.
Routing came back into the picture. We hadn’t discovered it late; it had been one of the original customer pain points and we had deliberately postponed it. But now we understood much more about the territory model and the operational behavior that routing needed to support.
Users also continued pushing the product toward day-to-day operational problems and longer, more flexible interactions.
We kept implementing what we learned.
The product reached production on May 3, 2026, 40 days later than our original estimate.
With the development capacity we had gained, I think we could have shipped something much closer to our original scope earlier. Instead, a significant part of that capacity went into capabilities we hadn’t originally planned to build.
Faster implementation changed what we could afford to learn
When we started, I thought about agentic coding primarily as an engineering productivity question:
Can we implement software faster?
After this project, I no longer have much doubt that we can.
But that’s not the part of the experience I find most interesting anymore.
In a conventional product development process, there can be considerable distance between learning something and getting the resulting change back in front of users.
A user does something unexpected. We investigate it. Product scope changes. Engineering evaluates the change. Architecture may need to change. The work competes with everything already on the roadmap. Eventually that new understanding becomes software and reaches users again.
During this project, that distance became much shorter.
We could implement our current understanding, expose it to users, discover where it was wrong and change it while the learning was still fresh.
That doesn’t remove the need for product discovery, architecture or engineering judgment. Faster implementation also means it’s possible to build the wrong thing faster. If anything, we found ourselves spending more time thinking about context, boundaries and verification as implementation became cheaper.
What changed was our ability to respond to evidence.
We started with a territory optimization product and an experiment in agentic development. Six months later, both the product and the way we were building it had changed substantially through repeated interaction with real users.
The result wasn’t simply that we executed the original plan faster.
We became much faster at turning new evidence into a different product.