From idea to production in 12 weeks
The discovery week, the written spec, the eight-week build, and the handover — what a custom build with us actually looks like.
A founder we'd known for years walked into our Hyderabad office in early February with a napkin sketch of a B2B field-force tracking product for the FMCG distribution market. Twelve weeks later, on the second Tuesday of May, the product was running in production across two distributors, processing 3,400 visits a day. Custom builds at this pace are not magic. They're the result of treating the schedule as a constraint, not an estimate. Here is the shape we use.
Week 0 — Discovery
One week. Not two, not "a discovery phase." Five working days with a maximum of two people from each side: a founder/PM and a technical lead from theirs, a senior engineer and a delivery lead from ours. The deliverable at the end of week 0 is a written spec, between 8 and 20 pages, that contains:
- The user roles and the day-in-the-life flow for each.
- The data model at logical level (entities, relationships, key fields).
- The integrations needed (payment, SMS, WhatsApp, GST, third-party APIs).
- A list of things explicitly out of scope. This list is usually longer than the in- scope list and is the most argued-over part of the document.
- A weekly milestone calendar across the eight build weeks.
If we can't write that document in five days, the project isn't ready to build, and we say so. Twice in the last year we've extended discovery by an additional week because the founder hadn't actually decided what they wanted. Both projects shipped on time after that, because the spec was right.
Weeks 1–8 — The build
Eight weeks of engineering, structured as eight one-week iterations. Each week:
- Monday — sprint planning, scoped to that week only. Stories that don't fit get dropped or deferred, never compressed.
- Tuesday–Thursday — implementation.
- Friday — demo to the client. Live software, not slides. The client uses what we built that week on real-or-realistic data.
- Friday afternoon — feedback captured as written change items. Items get assigned to the next week's plan or to a "post-launch" backlog.
The Friday demo is the disciplining mechanism. It is structurally impossible to fall three weeks behind without the client noticing on Friday week one. That visibility removes the single largest failure mode of fixed-price custom development — the silent drift that culminates in a panicked confession in week ten.
A weekly demo that the client actually uses on Friday is worth more than a hundred pages of status reporting. Demos cannot lie.
A typical week-by-week breakdown for the FMCG product:
- Auth, tenants, role model, baseline UI shell.
- Distributor and beat data model, route assignment.
- Field-force mobile app v1: visit logging, GPS, photo capture.
- Order capture flow inside a visit.
- Server-side dispatch and order acknowledgement to the distributor's ERP.
- Reporting and dashboards.
- Notifications (WhatsApp templates, SMS fallback) and edge cases.
- Hardening, load testing, production prep.
Each week shipped to a staging environment the client's team had access to. By week 5, the client's salespeople were using the staging app on their own phones, finding bugs we hadn't caught.
Weeks 9–10 — User acceptance and pilot
The product moves from staging to a production environment, but with a single pilot distributor and a controlled user set. Real money, real visits, real exception cases. Two weeks of running this in parallel with the legacy process surfaces every operational issue the spec didn't predict. We fix forward; we don't re-plan.
Weeks 11–12 — Rollout and handover
Week 11 expands the rollout — second and third pilot accounts, training material finalised, support runbook written. Week 12 is the handover. By Friday of week 12, the client team can:
- Deploy the product themselves (we set up the CI/CD they use afterwards).
- Read the architecture document and understand every service.
- Run the standard operational tasks (DB backups, log inspection, on-call rotation contact list).
- Invoke us under a defined support agreement that decouples our engineering team from their day-to-day operations.
The handover is a real document, not a vibe. We've had projects where the handover package was the largest single artifact of the engagement. That's fine. Custom-built software the client can't operate after the engagement is software they will eventually be hostage to.
What the 12-week pace requires
It is not for everyone. The pace requires:
- A founder who can make decisions on the spot. Slow decision cycles destroy the schedule.
- An in-scope/out-of-scope discipline that holds for twelve weeks. Scope creep is what turns 12-week projects into six-month projects.
- A willingness to ship the simpler version. Polish in week eleven; correctness in week one.
- A team on our side that's worked together long enough to skip the forming-storming phase. We don't put unfamiliar pairs on 12-week jobs.
The output is software the client owns. Not a co-development arrangement, not a licence — code, repositories, infrastructure, full access on day one of week 13.
If you have a problem that fits this shape, the conversation starts at admin@airanexus.in. For the off-the-shelf products, see /campus, /labs and /creator.