We built the wrong product for 6 weeks. The client never complained and that was the problem.

Deorwine Infotech — Wed, 17 Jun 2026 10:07:58 +0000

This is not a post about tools, frameworks, or productivity hacks. It's about the time we confidently built the wrong thing and the uncomfortable truth we had to sit with afterward.

A healthcare client came to us with a clear brief: "build a patient booking system." We asked some questions, nodded, and started sprinting.

Week 6. We're doing a progress demo. The client goes quiet halfway through. Then: "This is great. But… our nurses aren't the ones who book appointments. The insurance coordinators are. And their workflow is completely different."
We had built a beautiful, well-tested, on-time piece of software for the wrong human being.

Nobody lied. Nobody miscommunicated. We just never asked who was actually going to touch this thing every day.

The question we skipped
After that project, we started doing something embarrassingly simple at the start of every engagement: we ask to watch someone do the thing we're about to automate. Not a demo. Not a screen recording. Actually sit next to the person, in their environment, doing their real work.
In that healthcare case, if we'd done this in week 1, we'd have noticed the insurance coordinators were copying data between 3 systems using a spreadsheet they'd built themselves. That spreadsheet was the real product. We could have replaced it in 2 weeks instead of 6.

The most expensive line of code is the one that solves the wrong problem. It's not the code that crashes. It's the code that works perfectly and quietly for months before anyone realises it was never needed.

Mistake 2: we let "good enough" ship as "done"
There's a version of this everyone recognises: technical debt. But I'm talking about something subtler - experience debt.
We shipped a mobile app for an on-demand service. The booking flow took 11 taps. Our QA team signed it off. Our PM signed it off. The client signed it off. We launched.
The conversion rate was 23% lower than projections. We looked at the heatmaps. Users were dropping off at tap 7. Nobody in our entire review chain had done the booking as if they were tired, or on a slow connection, or doing it while standing in a laundry room holding a basket.
We rebuilt the flow to 5 taps. Conversion jumped. The 11-tap version was never broken, it was just built by people who already knew how it worked.
Before you ship anything user-facing: hand your phone to someone who has never seen the product and ask them to complete the main action. Don't explain anything. Just watch. The silence where they hesitate is your bug list.

Mistake 3: confusing "the client approved it" with "it's right"
Clients approve things for reasons that have nothing to do with quality. They're busy. They trust you. They don't know what they don't know. Approval is a social act, not a technical one.
We got into a habit of shipping things because the client said yes not because we genuinely believed it was the right call. This is a slow-moving form of dishonesty. You're outsourcing your professional judgment to someone who hired you specifically because they don't have it.

If you wouldn't put your own name on it and show it to someone you respect, "the client approved it" is a cope, not a defence.

The fix isn't to override clients. It's to be explicit when you disagree. "We'll build this because you've asked for it, but we want to flag that we think X will cause Y, can we note that in writing?" That sentence has saved us from post-launch blame-shifting more times than I can count.

Mistake 4: treating deployment as the finish line
We used to celebrate deployments. Now we celebrate the first 30 days after deployment. There's a difference.
One platform we inherited had no error monitoring, no alerting, and no on-call rotation. It had been "live" for 4 months. When we looked at the logs, there were 400 silent errors a day that nobody knew about. Real users hitting real failures. Just... silently.
js// The three things we set up before every launch

// 1. Error tracking (we use Sentry)
Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 1.0 });

// 2. Uptime alert — 5-min check, PagerDuty or even just email

// 3. A single dashboard: error rate, p95 latency, active users
// If you can't see these three numbers, you're flying blind.
Deployment is when the real information starts arriving. The users who break things in ways you never imagined, the edge cases your tests didn't cover, the performance cliff that only shows up at 3am when the cron job runs. You need to be watching.

Mistake 5: the documentation you write for your future self
A senior developer left one of our projects midway. We had a good handover doc. Or so we thought. The new developer came back three days later: "I can see what the code does. I have no idea why any of the decisions were made."
That distinction — what vs. why — is almost everything in documentation. The code tells you what. Comments tell you what the code does. What you actually need is a decision log: why did we choose Postgres over Mongo here? Why is this API endpoint structured this way and not the more obvious way? Why does this weird workaround exist?
We now keep a plain DECISIONS.md in every repo. One entry per architectural choice. Date, context, options considered, decision, and the person who made it. Takes 10 minutes per decision. Has saved us hundreds of hours of archaeology.

The through-line
None of this is revolutionary. It's just easy to skip when you're moving fast. And we've skipped all of it at least once.
Most project failures aren't technical. They're conversational. They're the question not asked in week 1, the concern swallowed in week 4, the handover that assumed the other person knew what you knew.

What's yours? Drop the mistake your team keeps making even though you know better. Genuinely curious whether these patterns are universal or if we're just uniquely bad at this.

DEV Community: Deorwine Infotech

We built the wrong product for 6 weeks. The client never complained and that was the problem.