Four shipped builds, four features cut in week one, zero of them rebuilt since. Across ONETAPP, SIT Manager, Tirth, and HospiHealth, the pattern is the same: the cut wasn't a compromise made under deadline pressure — it was a decision made before a line of code existed, and every one of those decisions held.
We publish build postmortems one at a time. This one is different — it's the cross-section. Four named builds, four concrete things we didn't ship, and the reasoning that survived contact with real users. If you're scoping your own first version, these are the receipts.
1. ONETAPP: cut the mobile app, the leaderboard, and the publisher API
ONETAPP is a gaming rewards platform — Electron desktop app, landing site, user panel, admin dashboard — built from a one-line brief to a live cohort of thirty-two users in ten weeks. The original brief assumed mobile. We spent three days of week one arguing it out of scope: gamers sit at a desk with Steam open, and a background app competing for a phone screen they weren't looking at made no sense.
Three things got cut in that same week-one session: the mobile companion app, a public social leaderboard, and a publisher API for game studios to add challenges directly. None were cut because they were bad ideas. They were cut because none had users yet to validate them — a leaderboard with forty entries reads as abandoned, and a publisher API with zero publishers is a maintenance burden with no one using it.
2. SIT Manager: cut real-time notifications, mid-migration
SIT Manager replaced eight years of fragile legacy PHP for Suvaidya Institute — two prior agencies had stalled for nine and six months respectively; we shipped a working first version in fourteen days and the full system in under eight weeks. The cut here wasn't a feature struck from the original spec. It was scope we let creep in and then pulled back out.
We introduced real-time notifications in week six, mid-migration, and it added risk during the most fragile part of the engagement — the cutover from a fifteen-month-stalled legacy system was the actual product at that point, and notifications weren't it. The lesson wasn't "don't build notifications." It was: don't add scope during a cutover, no matter how small the feature looks.
3. Tirth: cut the booking platform, kept the trust layer
Tirth is a platform for religious travel across India's faiths, a market running almost entirely on WhatsApp, cash, and a trust chain between priest, guide, and pilgrim. After three weeks of research — forty pilgrims, twelve guides, six temple-side operators — the obvious build was a booking platform: inventory, payments, reviews, listings. Every prior attempt in that market had built exactly that. Every prior attempt had died inside two years.
We cut the booking platform before we built it. Tirth shipped as a guide-first directory instead — named, vetted guides with testimonials, ending in a WhatsApp handoff, not a closed transaction. The guide network grew 4x in the first quarter through guide-to-guide referral, which doesn't happen inside a stripped-down transaction layer.
4. HospiHealth: cut the marketplace, built custom admin instead of a SaaS tool
HospiHealth needed a founder-story page, a jobs portal, and an admin dashboard for a hospital consulting firm — eight weeks, brief to live. The original brief wanted a job-board marketplace: public listings, candidate profiles, a matching interface. We cut it in week one. A marketplace needs two-sided volume to read as alive, and a new firm with one employer and no candidate base yet would launch a marketplace with five listings and zero applicants — worse than no marketplace at all.
The cut saved six weeks. The jobs portal that shipped instead — a structured intake form — has since taken in forty-three applications across three roles, all through a custom admin we built instead of routing sensitive CVs and salary data through a third-party SaaS tool.
What holds across all four
| Build | What got cut | Why | Result |
|---|---|---|---|
| ONETAPP | Mobile app, leaderboard, publisher API | No users yet to validate any of the three | Shipped in 10 weeks; none rebuilt since |
| SIT Manager | Real-time notifications (mid-build) | Added risk during the cutover, the actual product moment | Full migration in under 8 weeks |
| Tirth | The booking platform itself | Market runs on trust, not transactions | Guide network grew 4x in Q1 via referral |
| HospiHealth | Job-board marketplace | No volume yet to make two-sided matching work | Saved 6 weeks; intake form got 43 real applications |
The common thread isn't "cut aggressively." It's timing. Every cut above happened before the feature was built, not after it shipped and failed to get used. A cut made in a scoping session costs an afternoon of disagreement. The same cut made six weeks into a build costs six weeks, plus the maintenance tax on code nobody asked for. We wrote the general version of this rule in the three-question test we run on every feature before it ships — these four builds are what happens when you actually run it.
None of these features were wrong ideas. ONETAPP's publisher API and mobile app are both real roadmap items, just not week-one ones. That's the whole discipline: not "no," but "not yet, and here's the evidence we're waiting on."
Written 2026-08-20 by Naman Barkiya.