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.
That wasn’t simply a case of underestimated scope. We were building an AI product without fully understanding what customers would need from it. Rather than spend months trying to define the MVP upfront, we deliberately chose to develop it through working software and continuous customer feedback.
Agentic coding turned out to make that approach practical. As implementation became faster, we could afford to keep changing the product as we learned.
By the time we reached production, we had built something different and far more capable than what we’d originally planned.
Where we started
Our customers manage field teams visiting hundreds or thousands of retail locations, deciding who covers which stores, how often they should visit, and how to minimize travel time.
Customer interviews had identified routing and scheduling as major pain points.
We realized that effective routing and scheduling depended on territory planning: deciding how locations should be assigned to representatives while accounting for geography, workload and business constraints. We decided to solve that first.
We knew how customers organized territories and used our reports. What we didn’t know was how they decided which stores needed more attention, how often to visit them, or when to reorganize territories. Those decisions depended partly on information outside Repsly, such as sales data, and we didn’t have a domain expert to help us understand the full picture.
That made discovery difficult. Customers could tell us what problems they had, but they weren’t used to thinking of Repsly as a system that could recommend what to do. We couldn’t simply ask them what recommendations they wanted, and we didn’t yet know the right questions to ask.
We also had a commercial deadline. To have a realistic chance of generating revenue in 2026, we needed the product commercially available by April, before the summer holiday season.
That left little time for lengthy discovery through interviews and design prototypes. We needed customers to interact with working software and their own data so we could learn how they actually made decisions.
Learning through working software would normally be expensive. But we’d been experimenting with agentic coding and wanted to see whether it could make those iterations fast enough to fit our timeline.
Territory Planner was a good test. It had a real customer problem, complex business requirements, substantial data volumes, and a combination of mathematical optimization and reasoning. It would also tell us whether coding agents could handle production-grade development on top of our mature SaaS platform.
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 working across architecture, development and product.
We wouldn’t write production code manually. We would build it through coding agents.
Users started asking different questions
Our initial product was fairly structured.
Analyze the current territory setup. Identify problems. Configure the optimization. Generate recommendations. Review them. Export the proposed changes.
We were learning how to work with coding agents, too. Generating code was relatively easy; making the right changes to an existing system required much more attention to planning, context and verification. 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, representative 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 put the expanded product back in front of users.
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 original architecture.
We changed the architecture to support how people were actually using the product.
With that change in place, users started bringing day-to-day operational problems into the system. They asked about temporary opportunities, representative performance, short-term changes and more flexible ways of working with territories.
That also changed what we could learn from customers. As the product moved beyond providing insights and started making recommendations, we needed a better understanding of how they made operational decisions.
Working with the product gave customers a reason to explain those decisions, and gave us better questions to ask.
Each change allowed users to do more with the product. That exposed new technical limits, but it also revealed more about how their business actually worked and what the product needed to support.
- We learn more
from users - Product changes
- Implementation /
architecture changes - New capability
reaches users - Users do more
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 had become less important, while other needs had become more important.
Routing came back into the picture. We had deliberately postponed it at the beginning, but by then we understood much more about the territory model and the operational behavior routing needed to support.
The product reached GA in May 2026, 40 days later than our original estimate.
With the development capacity we had gained from agentic coding, I think we could have shipped something much closer to our original scope far earlier. Instead, a significant part of that capacity went into capabilities we hadn’t originally planned to build.
By then, the original estimate and the product we were delivering no longer described quite the same thing.
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 the more interesting result was how quickly we could respond to what customers were teaching us.
We could put working software in front of users, see what they actually tried to do, and change the product while that learning was still fresh. Some of those changes required substantial new functionality or architectural work that would previously have been difficult to accommodate within the same timeline.
That didn’t make product discovery, architecture or engineering judgment less important. Faster implementation also meant we could build the wrong thing faster. We found ourselves spending more time thinking about context, boundaries and verification as implementation became cheaper.
We became much faster at turning new learning into a different product.