Five phases. Every one of them has an exit.
You can stop after any phase, having paid only for what is finished, and walk away with the code, the designs and the documentation. We would rather lose a project in week three than drag an unhappy client through six months.
What happens, how long it takes, and what you get.
These durations are what we actually observe across 500 projects, not the ones that win pitches. A 20-week build quoted at 8 weeks is not a faster project — it is a later one with a worse relationship attached.
-
01
Discovery
2 weeks — fixed priceWe run workshops with your team, interview the people who will actually use the thing, and audit whatever system you already have. We map the workflow as it really happens, not as the org chart says it does. Half of a first-draft scope usually does not survive this, and that is the point. Deliverables: a scoped and prioritised backlog, a technical architecture and data model, a risk register, a clickable prototype of the core flow, and a fixed-price estimate for the build we can both defend. You own all of it, and you can take it to another studio.
-
02
Design
3-5 weeksInformation architecture, then flows, then interface. We test the prototype with five real users before we commit to production code, because a usability problem found here costs an afternoon and the same problem found in month four costs a sprint. Deliverables: a full component library and design system in Figma, high-fidelity screens for every state including the empty, error and loading ones everybody forgets, an accessibility spec against WCAG 2.2 AA, and a tested prototype.
-
03
Build
8-20 weeksTwo-week sprints. A demo of working software every Friday, a written note on what shipped, what slipped and what is blocked, and read access to the repository and the board from day one. Code review on every pull request, automated tests on the domain core, and CI running from the first commit. Deliverables: production code in your repository, a staging environment you can click through at any hour, a test suite, and an architecture document that stays current because it is reviewed each sprint.
-
04
Launch
2 weeksLoad testing at several multiples of your expected peak, an OWASP-aligned security review, a staged rollout, and a rollback we have rehearsed rather than assumed. We agree the go/no-go criteria in writing beforehand so that nobody is making a judgement call at midnight. Deliverables: a load test report with the numbers, a security review with remediations closed, monitoring dashboards and alerts, runbooks for every operational task, and tested backups with a restore we have actually performed.
-
05
Scale
Ongoing — or not at allEvery build carries a 60-day warranty: if it does not do what the spec said, we fix it at no charge. After that you can take a support retainer — monitoring, dependency and security patching, an SLA, and a pool of engineering hours for what the first six months of real users teach you. Or you can take the keys and run it yourself. We hand over an architecture doc, the runbooks, a codebase walkthrough with your engineers, and a transition period on call. Both are good outcomes and we do not push you toward the one that pays us more.
Us, versus the quote that is half our price.
| PRS India | The typical agency | |
|---|---|---|
| Paid discovery before an estimate | Yes — two weeks, fixed price, yours to keep | A quote off a phone call and a wishlist |
| Who writes your code | The engineers you met in the pitch | Juniors, after the seniors sold it |
| Architecture reviewed by a principal engineer | Yes | No |
| Automated tests on the domain core | Yes | No |
| Load tested before launch | Yes — at several multiples of peak | You find out on launch day |
| Security review | OWASP-aligned, in scope, not an upsell | Quoted separately, if at all |
| Repository and cloud accounts in your name | From week one | At handover, if you push |
| Demo of working software every week | Yes | A status deck once a month |
| Scope changes priced before the work starts | Yes — sized in 48 hours, approved by you | Absorbed silently, then blamed for the delay |
| Handover with runbooks and an architecture doc | Yes — handover is a phase | A zip file and good luck |
| Post-launch warranty | 60 days, no charge | A change request form |
| Exit at the end of every phase | Yes | A twelve-month contract |
The things that are in every engagement, whatever the size.
None of these is a line item. They are what we mean by the word "done", and pricing them separately would be a way of admitting they are optional. They are not.
-
An architecture reviewed before it is built
A principal engineer signs off on the data model and the load profile before production code exists.
-
Repository and cloud accounts in your name
From week one. Not at handover, not after the final invoice.
-
A demo of working software every Friday
Plus a written note on what shipped, what slipped and what is blocked.
-
Tests on the parts that would hurt to break
We do not chase a coverage number. We cover the domain core and the money paths.
-
A load test with the numbers published
Run before launch, at several multiples of your expected peak.
-
A security review aligned to OWASP
Dependency scanning, least-privilege access, and remediations closed before go-live.
-
Monitoring, alerts and runbooks
Alerts that fire on symptoms your users actually feel, not on CPU graphs.
-
A 60-day warranty after launch
If it does not do what the spec said, we fix it at no cost.
What clients ask about how we run a project.
Scope creep, sprint zero, working with your in-house team, and what happens when it goes wrong.
Still have a question?Start with two weeks, not two years.
Discovery is fixed price, it is yours to keep, and at the end of it you can walk. Most clients do not — but the fact that they could is why the number at the bottom of our estimate is one we can defend.