Eight months, no plan, nothing shipped. We shipped it in two.

A team had been building a health platform for eight, maybe nine months. The client had run out of money. And there was nothing to ship — not because the code didn't exist, but because nobody in the building could tell you what "done" meant.

That's the part people miss about stuck projects. They're rarely stuck on a hard technical problem. They're stuck because the thing being built was never actually described.

What we walked into

I've inherited messy codebases before. This was a different kind of mess — the kind where the code is the least of your problems:

• No written plan. Not a light one. None.
• No business requirements. Nobody could say what the product had to do, only what had been half-built so far.
• No scope — and, worse, no sense of what was out of scope. Every idea was still theoretically in.
• No design source of truth. No Figma, no UX reference. Screens were invented at the keyboard.
• No QA. No automated tests. "It worked on the last device we tried" was the entire quality process.
• No database migrations, no backups. The schema lived wherever it had last been hand-edited.
• A dev team that couldn't tell you what the app needed next. Not from lack of skill — from lack of a map.

On paper it was "feature-complete." In reality it was unshippable, and every week of unfocused effort was burning a budget that was already gone.

The unglamorous fix: we stopped coding and started writing

The instinct on a late project is to code faster. That's how you get to month nine. We did the opposite — for the first stretch, we barely wrote code at all. We wrote sentences.

We wrote the business requirements. We defined the scope, and we defined the far more valuable thing: what we were not building. We wrote down what "done" meant for every single screen — the states, the errors, the edge cases — so "done" stopped being an opinion and became a checkbox.

A vague ambition that had lived in five people's heads for eight months became one list you could actually finish.

Then we built it properly

With a plan in hand, the engineering went fast — and we built it the way a health platform actually has to exist, not the way a demo does:

- No plan / no requirements
- No design source of truth
- No QA, no automated tests
- No migrations, no backups
- Hand-edited schema
- Unhardened, demo-grade build
- English-only, hardcoded strings

- Written scope + definition of done
- Real design + UX
- Test suite + QA gate
- Migrations + automated backups
- Reproducible schema
- Production-hardened release
- End-to-end EN/AR + RTL

We put in the scaffolding that makes a product safe to actually run: proper database migrations and automated backups, a real test and QA pass before release, hardened builds and store-grade release signing, server-verified payments, crash reporting, and real end-to-end localization (English + Arabic, RTL) instead of hardcoded strings. Reliable voice and video consultations too — the enterprise-grade version of every corner that had been cut.

The result

Two months after we started, it was live.

• 🌐 afyti.co
• 📱 App Store
• 🤖 Google Play

Real patients, real consultations, real payments — the platform that "couldn't be finished" in nine months, finished and shipped in two.

If your project has been almost done for months, be honest about what's missing. It's usually not one more sprint. It's a document — the boring one that says, in plain words, what you're actually building and how you'll know when it's done.