Healthcare App Development

I want to describe a specific failure mode, because I've now heard three other founders describe the same thing with completely different vocabulary, and I think we're all talking about the same disease.

Here's the shape of it. Somewhere between month twelve and month eighteen, shipping gets slow. Not dramatically — no single sprint where everything collapses. Just a steady, unremarkable decline that you don't notice until you compare a feature you shipped last week against a feature of identical scope you shipped last year. Ours took about three times longer. Same team, same stack, roughly the same complexity.

The instinct is to blame the codebase. Everyone on the team blamed the codebase. Our lead engineer had been saying "this thing needs a rewrite" for four months, and honestly, he had receipts — the test suite took nine minutes, we had three different patterns for handling API errors, and there was a service nobody wanted to touch because the person who wrote it had left.

We almost did the rewrite. What stopped us was an argument I lost.

The argument I lost

One of our engineers pushed back on the rewrite by asking a question that seemed almost insultingly basic at the time: which specific tickets took 3x longer, and what did they have in common?

Nobody had checked. We'd all been operating on vibes and frustration, which — I've since learned — is how most rewrite decisions actually get made.

So we spent two weeks going backward through about sixty closed tickets. Rough categorization, nothing scientific. What came out was uncomfortable.

The slow tickets weren't spread evenly across the codebase. They clustered. Roughly 70% of our worst time overruns touched one thing: how we'd modeled the relationship between a user and an organization.

Early on — like, week three of building, when we had zero customers and no reason to think about it — we'd decided a user belonged to exactly one organization. It was the obvious call. It was also wrong, and it became wrong the moment our first mid-size customer asked whether their consultant could access two workspaces.

We didn't rebuild the model. We shimmed it. Then we shimmed the shim. By month eighteen there were, by our count, eleven separate workarounds for that single assumption scattered across the codebase, and every new feature that touched permissions had to be built to accommodate all eleven. That's where the 3x lived.

The rest of the codebase was fine. Ugly in places, but fine. Ugly code is cheap. Wrong assumptions are expensive.

What we actually did

We didn't rewrite. We did a scoped rebuild of the identity and permissions layer — about 40% of the code by line count, though that number is misleading because it was maybe 15% of the surface area users could see.

Four months. Two engineers on it full-time, the rest of the team shipping normally. We ran the old and new models in parallel for six weeks with a translation layer between them, migrated customers in cohorts starting with our smallest accounts, and killed the old path once the last cohort was through. Two incidents, both minor, both caught before customers noticed.

A full rewrite, by our estimate, would have been somewhere north of a year with the whole team. I have no idea whether that estimate was any good. Rewrite estimates are famously fiction.

The part I'd tell my earlier self

The lesson isn't "don't rewrite." Sometimes you should. The lesson is that slow shipping is a symptom, and almost nobody diagnoses it before prescribing.

A rewrite is a very expensive treatment for a condition you haven't identified. If your velocity has dropped, the two weeks you spend auditing where the time actually went is the cheapest work you will do all year — and it's the only thing that tells you whether you're facing a diffuse problem (which a rewrite might fix) or a concentrated one (which a rewrite is wild overkill for).

There's a second, less comfortable lesson. That user-to-organization decision was made during MVP app development, by me, in about ninety seconds, on the reasonable grounds that we had no customers and needed to ship. I don't think that decision was wrong given what I knew. But I'd been told, like everyone gets told, that MVP decisions are cheap because you'll throw the MVP away. We didn't throw it away. Almost nobody throws it away. The MVP just quietly becomes the product, and the ninety-second decisions become the load-bearing walls.

So now I keep a short list — genuinely short, four or five items — of decisions I'd classify as structural. How identity works. How money moves. How data is scoped and isolated. Those get a day of thought even when we're moving fast, because they're the ones that don't stay cheap.

Everything else, I'll happily do badly and fix later. Ugly code is cheap.

Where I'm still unsure

I don't know whether we'd have been better off doing the full rewrite. We're eight months past the rebuild now and velocity recovered to roughly where it was at month twelve — not better, just recovered. There's an argument that we bought back the old speed and kept all the other debt, and we'll pay for it again in two years.

There's also an argument that the year we didn't spend rewriting is the reason we're still here.

Both arguments are unfalsifiable, which is the deeply annoying thing about this entire category of decision. You never get to run the control group.

If you've done the full rewrite — did the problems you were trying to escape actually stay gone? That's the thing I've never gotten a straight answer on.

Every founder thinks their idea is the exception. The one that doesn't need validation because it's "obviously" needed. I've watched enough of these ideas die quietly six months after launch to know: obvious is not the same as validated.

Here's the uncomfortable truth. Most startup ideas aren't bad — they're just untested. And the gap between "sounds good in a pitch deck" and "someone will actually pay for this" is where most of the money disappears. Development is expensive. Validation is cheap. Yet founders routinely reverse that order.

If you're about to spend money building something, do these five things first.

1. Talk to 20 people who are NOT your friends

Friends and family are the worst validation panel you can assemble. They love you, so they'll tell you what you want to hear. "That's such a cool idea!" is not market research.

Find 20 strangers who actually fit your target user. Cold DM them, post in relevant communities, ask for 15 minutes of their time. Don't pitch — ask about their current process. How do they solve this problem today? What do they use? What annoys them about it? What have they already tried and abandoned?

If people can't describe the pain in their own words without you prompting them, the pain might not be big enough to build a business on.

2. Try to sell it before you build it

This is the fastest gut-check there is. Build a one-page landing site describing what you're building, the core benefit, and a clear call to action — "Join the waitlist" or "Pre-order now." Run a small ad budget behind it, or share it organically where your audience hangs out.

You're not measuring page views. You're measuring intent: email signups, pre-orders, or better, actual payment commitments. A hundred people saying "cool idea" in the comments means nothing. Ten people giving you their card details means everything.

3. Build the fake version first

Before writing a line of production code, build the "Wizard of Oz" version — where the front end looks real but the back end is manual. Booking a service? You confirm it by hand. Automating a report? You generate it yourself and email it over.

It's unglamorous and doesn't scale, but it tells you two critical things: whether people actually use the thing once it exists, and where the real friction points are — which are almost never where you assumed they'd be.

4. Check if the market is already voting with its wallet

If nobody else is attempting to solve this problem, that's not automatically a good sign — sometimes it means there's no money in it. Look for adjacent or competing solutions, even clunky ones like spreadsheets, WhatsApp groups, or Craigslist-style workarounds. Their existence is proof people are already paying (in money or effort) to solve this. Your job becomes making that solution better, not creating demand from scratch.

5. Set a validation budget and a kill number, before you get emotionally attached

Decide upfront: "I will spend ₹50,000 and 4 weeks testing this. If I don't see X signups / Y pre-orders / Z paying customers, I stop and rethink."

Write this down before you start. Once real money and time go into building, sunk cost bias kicks in hard, and founders keep shipping features to a market that never asked for them in the first place.

The point of all this

Validation isn't about proving you're right. It's about finding out you're wrong as cheaply and quickly as possible, so the version you eventually build is the one people were already asking for.

Development cost isn't just money — it's the 3-6 months you can't get back if the idea doesn't land. Spend that time listening and testing first. Building comes after, not instead.

How does BNPL impact credit scores compared to traditional credit systems?

Traditional credit directly affects credit scores through repayment history, utilization, and debt management. BNPL systems, however, often have limited reporting to credit bureaus. Is this a disadvantage for users trying to build credit history?

Should a BNPL App Development company integrate stronger credit reporting features?