Skip to content
PRS India
How we work

Five phases. Every one of them has an exit.

You can stop after any phase. You pay only for what is finished, and you keep the code, the designs and the papers. We would rather lose a project in week three than keep an unhappy client for six months.

The phases

What happens, how long it takes, and what you get.

These times are what we really see across 500 projects, not the ones that win pitches. A 20-week build quoted at 8 weeks is not faster. It just finishes later, and the relationship gets worse.

  1. 01

    Discovery

    2 weeks — fixed price

    We hold workshops with your team. We talk to the people who will really use the product. We check any system you already have. We map the daily work as it really happens, not as the company chart says it does. Half of a first-draft scope usually does not survive this, and that is the point. What you get: a list of the work, in order of importance, the technical plan and data design, a list of risks, a clickable demo of the main steps, and a fixed-price estimate for the build that both of us can stand behind. You own all of it, and you can take it to another company.

  2. 02

    Design

    3-5 weeks

    First the structure, then the steps users take, then the screens. We test the demo with five real users before we write the real code. A problem found here costs an afternoon. The same problem found in month four costs a whole sprint. What you get: a full set of parts and a design system in Figma, detailed screens for every state, including the empty, error and loading ones everybody forgets, an accessibility plan to the WCAG 2.2 AA standard, and a tested demo.

  3. 03

    Build

    8-20 weeks

    Two-week sprints. Every Friday you see a demo of working software. You also get a written note on what was done, what is late and what is stuck. You can read the code and the task board from day one. Every code change is reviewed by another engineer. The core logic has automatic tests, and CI (automatic checks) runs from the first commit. What you get: the real code in your repository, a test site you can click through at any hour, a set of tests, and a design document that stays up to date because we review it each sprint.

  4. 04

    Launch

    2 weeks

    We test with several times your expected busiest load. We do a security review that follows OWASP. We roll out in steps, and we have practised how to go back, not just assumed it will work. We agree the go or no-go rules in writing beforehand, so nobody has to make a guess at midnight. What you get: a load test report with the numbers, a security review with all fixes done, screens and alerts to watch the system, written steps for every routine task, and tested backups that we have really restored.

  5. 05

    Scale

    Ongoing — or not at all

    Every build has a 60-day warranty: if it does not do what the spec said, we fix it at no charge. After that you can choose a support plan. It covers watching the system, security and software updates, a service promise (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 the design document, the written steps, a walk through the code with your engineers, and a period when we are on call. Both are good outcomes, and we do not push you toward the one that pays us more.

The honest comparison

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 from a phone call and a wish list
Who writes your code The engineers you met in the pitch Junior staff, after the senior staff made the sale
Architecture reviewed by a principal engineer Yes No
Automated tests on the domain core Yes No
Load tested before launch Yes — at several times your busiest load You find out on launch day
Security review Follows OWASP, included, not an extra charge Quoted separately, if at all
Repository and cloud accounts in your name From week one At handover, if you ask
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 Taken on quietly, 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 form to ask for a change
Exit at the end of every phase Yes A twelve-month contract
What you get, always

The things that are in every engagement, whatever the size.

None of these is a separate charge. They are what we mean by the word "done". Pricing them separately would be a way of saying they are optional. They are not.

  • An architecture reviewed before it is built

    A principal engineer approves the data design and the expected load before any real code is written.

  • 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 test score. We test the core logic and the parts that handle money.

  • A load test with the numbers published

    Done before launch, at several times your expected busiest load.

  • A security review aligned to OWASP

    We scan the software we depend on, give each person only the access they need, and fix all problems before going live.

  • Monitoring, alerts and runbooks

    Alerts that go off for problems your users really feel, not for CPU graphs.

  • A 60-day warranty after launch

    If it does not do what the spec said, we fix it at no cost.

Process questions

What clients ask about how we run a project.

Growing scope, the first setup sprint, working with your own team, and what happens when it goes wrong.

Still have a question?

You can stop. The planning stage and the first build sprint are set up so you can leave after either one. At the end of each, you have paid only for what is finished. You own everything we made. You can take the code, the designs and the documents to another team. We would rather lose a project in week three than keep an unhappy client for six months.

We assume it. Every scope changes. That is a sign you are learning, not a failure of planning. What we do not do is take it on quietly and miss the deadline. We size every new request within 48 hours. Then it goes one of three ways. We swap it for something of equal size, we move it to the next phase, or we add it as a priced change that you approve before we start. You always see the trade before we make it.

Every Friday you get a demo of working software. Every week you get a written note on what is done, what is late and what is stuck. You also get a shared Slack or Teams channel where our engineers answer you directly. From week one you can also read the code and the project board. No empty status shows. You do not wait for a monthly meeting to hear about a problem.

Often, and it is usually the best result. Our engineers work side by side with yours. We work in your repository and follow your rules, and we check each other's code. The goal is that your team can look after the code after we leave. So we plan the handover from the first week, not the last.

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 away. Most clients do not. But the fact that they could is why we can stand behind the number at the bottom of our estimate.

Last updated