A Story We’ve Lived More Than Once
Early in our relationship with one client, we were building two products simultaneously while they had a third underway with another vendor. Same goals, same timeline, but each product came to us, or them, with a different level of definition. What unfolded was something we’ve seen many times before.
The First App
The first app was greenfield. No predecessor, no legacy assumptions, no “but this is how we’ve always done it.” We were given a problem to solve and the freedom to help figure out how. Before any code was written, we ran discovery sessions with real users — mockups, wireframes, and feedback loops that surfaced how people actually wanted to interact with the product. The layout, the workflows, the core interactions — all of it was validated before development began. What we built matched what users needed because we’d already watched them use it. That app ended up being the highest-value product the client shipped that year, for the business and for its users.
The Second App
The second app had a predecessor the client wasn’t happy with. That frustration opened the door to a more collaborative conversation. We collaborated, pushed on some assumptions, and landed on something better than what either side originally envisioned. A success, though a few features the client championed didn’t get the user adoption they expected.
The Third App
The third app also had a predecessor with plenty of room to improve. But with the scope feeling well-defined, the decision was made to keep the engagement lean with another vendor. The vendor delivered exactly what was asked for. To spec. But it struggled at scale, users were frustrated, and the architecture couldn’t support where the product needed to go. It eventually landed in our hands to rebuild in production.
As a good friend of mine always says, buy it nice or buy it twice. The cost of doing it right the second time far exceeded what doing it right the first time would have cost.
Experience Doesn’t Protect You. Process Does.
Here’s the part that makes this story worth telling: all three apps were purchased by the same company.
- Same buyers
- Same budget cycle
- Same level of sophistication.
This wasn’t a story about an inexperienced client getting burned. It was a story about what happens when discovery gets treated as a luxury rather than a necessity — an easy trade-off to make when the scope feels clear and the timeline feels urgent. They simply made a reasonable assumption on the third app: the solution was obvious, the scope was clear, and upfront investment felt unnecessary. What followed was a product that frustrated users, couldn’t scale, and required significant architectural changes while already in production. The cost of skipping discovery didn’t show up on the original invoice. It showed up later, and it showed up much larger.
When the path forward feels obvious, discovery is the first thing that gets cut. The timeline is set. The spec exists. Why slow down? But the confidence that makes discovery feel unnecessary is often the same confidence that produces software nobody ends up using the way it was intended.
What separates successful software projects from costly ones isn’t always the team or the technology. It’s the willingness to trust the process, to slow down before the build, define the right problem, pressure-test assumptions, and align on outcomes before writing a line of code. Even when, especially when, the answer feels obvious.
Build the Right Thing Before Building It Right
There’s a principle we come back to constantly at SEP: build the right thing before building the thing right. It’s not one or the other. Both matter.
Great execution pointed in the wrong direction is just an expensive mistake delivered on time. And a perfectly defined product built by a team that can’t execute is equally worthless. The goal is both, and that starts with a small investment up front to make sure the larger investment that follows is going in the right direction.
The data backs this up. CB Insights analyzed hundreds of VC-backed companies that shut down and found that poor product-market fit showed up in 43% of them, second only to running out of capital, which CB Insights itself describes as the final cause of death rather than the root problem.
Boehm and Basili’s research, published in IEEE Computer, found that fixing a software problem after delivery is often around 100 times more expensive than fixing it during requirements and design. On smaller systems the multiplier is closer to 5:1, but the direction never reverses. The reality is simple: you pay for discovery either way. Doing it up front is just the cheaper option.
Vendors Build What You Ask. Partners Challenge What You’re Asking For.
There’s a meaningful difference between a software development vendor and a strategic software development partner, and it goes deeper than contract terms or team size.
A vendor’s job is to deliver. Give them a spec, a timeline, and a budget, and they’ll execute. That’s not a criticism. Reliable execution is genuinely valuable, and no amount of strategic thinking makes up for a team that can’t ship. But execution alone isn’t enough if you’re solving the wrong problem. A vendor optimizes for output. A partner is accountable for outcome.
A strategic partner earns a seat at the table before the blueprints are drawn. They ask uncomfortable questions: Does this feature actually serve your users? Is this the right solution to the problem you described, or just the most obvious one? They bring expertise not just in how to build software, but in whether the software being planned is worth building at all. That distinction is the difference between a development team that hands you what you ordered and one that helps you avoid an expensive mistake.
So, Which App Would You Rather Build?
Think back to those three apps. One had every advantage: freedom, collaboration, and a partner invested in getting it right. One had just enough openness to land somewhere better than expected. And one had a team that delivered exactly what was asked for, nothing more, and paid for it long after the project closed.
The difference wasn’t talent. It wasn’t budget or even the technology.
It was the question that got asked, or didn’t, before a single line of code was written: Are we building the right thing?
When you’re evaluating your next software development partner, don’t just ask what they’ve built. Ask what they’ve talked a client out of building. That’s where the real value lives.
✨ AI Post Recap
Skipping product discovery is usually the most expensive decision on a software project, and experienced buyers make it as often as inexperienced ones. The same company bought three apps in the same budget cycle. The two that got real discovery produced the best outcomes. The third was scoped as a low-cost fixed-fee build, was delivered exactly to spec, struggled at scale, and had to be rebuilt. You pay for discovery either way. Doing it first is the cheaper option.
What is product discovery in software development? Discovery is the work done before a build starts: talking to users, pressure-testing what the business needs, and turning a request into a defined problem. It typically runs two to four weeks and produces a scoped feature list, a ranged estimate, and a written out-of-scope list.
What does skipping discovery actually cost? It moves the cost from the front of the project to the end, where it is larger. Defects and wrong assumptions caught after delivery cost substantially more to fix than those caught during requirements and design, and a product built to the wrong spec has to be rebuilt rather than repaired.
What is the difference between a software vendor and a software partner? A vendor executes the spec you hand them and optimizes for output. A partner gets involved before the spec exists, questions whether the requested solution fits the problem, and is accountable for the outcome. When you are wrong, a vendor builds it anyway and a partner tells you.
