Products built to be handed over, not to be depended on us for
A working product in your repository, with the decisions written down, so your team can take it from here.
Book a build review
Five parts of a first version — and the schema is the one that bites
A first version is a workflow, a data model and an interface someone opens daily. The data model decides whether year two is an extension or a rebuild.
- Zero-to-one product builds
- The first real version of a product — the core workflow, the data model underneath it, and an interface someone will actually use daily.
- Web applications
- Typed front ends and the services behind them, deployed on infrastructure you own and can read.
- Data models that survive
- The schema is where a rushed MVP usually goes wrong. We design it for the second year, because migrating it later is the expensive part.
- Native mobile builds
- iOS and Android where the product genuinely needs the device — offline capture, camera, background location. We say when a web app would do instead.
- Design and interface work
- Interfaces designed and built by the same people, so nothing is lost in a handoff between a design file and an implementation.
Why first versions get rebuilt within a year
None of these is a technology problem. Each one is a decision taken early and never written down.
- The data model was shaped by the first screen, and every screen after it fights that decision.
- Nobody wrote down why anything was done, so the next team re-litigates every choice.
- It was built to demo, not to run, so the first real user load exposes work nobody scoped.
- The agency holds the deployment, the domain and the knowledge, so leaving them means starting over.
Four commitments you can check, rather than four values
Each one shows up in something you receive or something written down, not in how we describe ourselves.
Your repository from day one
Code lands in your GitHub organisation from the first commit. There is no moment where we hand something over, because you already had it.
Decisions written down
Short notes recording why the schema looks like that and what we ruled out, so the next engineer inherits reasoning rather than archaeology.
You talk to the builder
No account manager between the question and the person who knows the answer.
Scoped, not open-ended
Scope agreed in writing before we start, and a written note when something we find changes it.
The builds behind this line — and how far each one opens
4 builds, delivered for clients under NDA. What you can open is our own reference build of each, with sample data in place of the client’s: 4 run end to end.
Four steps, and you are running software by the third
Every step ends in something you can look at rather than a status update.
- 01
Build review
Thirty minutes on what you are building and what is actually hard about it, followed by a written note.
- 02
Scope and schema
The data model and the core flows on paper before code, because this is the decision that is expensive to reverse.
- 03
Build in your repo
Working software you can pull and run each week, not a demo at the end.
- 04
Handover
Deployment, environment setup, the decision notes, and a walkthrough with whoever takes it on.
The same four terms hold whatever we build
Scope in writing, code in your repository as it is written, support in business hours IST Monday to Friday, and the builder on the call.
- Scope agreed in writing before we start and a written note the moment something we find changes it.
- Code in your repository as we write it so there is no handover event at the end — you already had everything.
- Support in business hours, Monday to Friday IST with the response window for anything critical agreed in writing. We do not advertise a blanket SLA a team this size could not hold.
- You talk to the person building it with no account manager between the question and the answer.
The five questions that actually decide it
Asked on almost every call, answered plainly. Where the honest answer is “sometimes not”, it says so.
Who owns the code?
You do, and it sits in your repository from the first commit rather than arriving at the end. Where we reuse a component we have built before, we tell you which parts those are and on what terms, so there is no ambiguity about what you can take with you.
What happens after launch?
Support runs during business hours, Monday to Friday IST, and covers defects, monitoring and updates. We agree the response window for anything critical in writing before launch rather than advertising a blanket SLA a small team could not hold. What is not covered is written down too.
How long does a first version take?
Most first versions land in four to six weeks, and more involved systems in eight to twelve. Those are scope estimates agreed before we start, not fixed promises — we confirm dates in writing once the scope is settled, and tell you early if something we find moves them.
Can our own engineers work alongside you?
Yes, and it usually makes the handover better. Everything is in your repository under normal review, so your team can pick up parts of the build as they go rather than inheriting it cold.
What if we want to stop partway?
You keep everything built to that point, in your repository, in a state you can run. We would rather end an engagement cleanly than hold work hostage to keep it going.
Tell us what you’re building.
Thirty minutes on the problem and what is actually hard about it, then a written note back. No obligation either way.
Book a build review