{bs}
Book a build review
// the method

Reference-First Engineering

The way we build, written down in full. Not a trademark, not a framework we sell — the working document we hold ourselves to, published so you can read it before you talk to us.

v1.0Last revised
// the short version

The whole method in five lines

If you read nothing else on this page, read these. Every line links to the section that argues it in full, and every line includes what it costs you.

  1. Nothing is quoted until you can click it. A bounded reference build comes first, and the written scope describes the thing you already used.

  2. The engineers who scope it are the engineers who write it. No account layer and no junior bench, which caps how many builds we can run at once.

  3. Every week ends with a deployed build and a written note. Including the weeks where the note says we lost time, and why.

  4. You own what we write for you, from the first commit. The scaffolding we reuse stays ours and ships to you under a licence, listed by name at handover.

  5. Handover is a checklist; support is business hours IST, Monday to Friday. No on-call rota and no contractual SLA. If you need round-the-clock cover, we will help you plan it rather than pretend to be it.

// why this page exists

Most studios name a method, put a trademark on it, and keep the detail behind a sales call. We publish ours instead. Read it before you talk to us, argue with the parts you disagree with, and hold us to the rest.

What the method is, in two sentences

Reference-First Engineering means nothing gets scoped, quoted or promised until there is something you can click.

We build a navigable reference of the system first, agree the written scope against that reference, then build it in weekly deployable increments with the same senior engineers who scoped it.

// changelog

Version 1.0, and no invented history before it

This was an internal document until , so there is exactly one entry below and we will not backdate the versions that never existed publicly. When the way we work changes, the version moves and the change gets written down here — including the changes that came out of something going badly.

  1. v1.0

    First public version

    The first version of the method published anywhere. Until now it was an internal working document, and putting it on the site is the point: it lets you disagree with how we work before signing rather than discover it in week three.

    The two changes folded into this version

    Two changes that had already been made internally are folded in — the reference build is now a bounded stage you can stop after rather than something inside a larger contract, and any feature with a model in the loop starts with a test set and an agreed pass bar instead of an evaluation written after the feature already worked. From here, every change to how we work gets its own dated entry above this one.

// pillars

Five commitments you could catch us breaking

A reference build before any estimate. The same senior engineers from the first call to handover. A deployed build every week. Decisions written down next to the code. A test set agreed before any model-backed feature is built. If we stop doing one of these on your project, this page is the thing to point at.

  1. A reference build comes before the estimate

    We do not quote a system we have not built a version of.

    Before scope is fixed we build a navigable reference: real screens, real data shapes, the main flows clickable, no live backend behind them. You click through it and tell us where it is wrong, which is a far better conversation than reviewing a requirements document nobody reads carefully. If we cannot produce a coherent reference in a short bounded stage, we do not understand the problem well enough to quote it, and we say so.

  2. The people who scope it write it

    No account layer, no handoff from the people who sold the work.

    The engineers in your first call are the engineers in the repository. There is no account manager translating between you and a delivery team, and no junior bench the work quietly moves to once the contract is signed. The cost of that is real: we deliberately run few builds at a time so each one gets senior attention, and we will tell you the calendar does not fit rather than staffing around it.

  3. Every week ends with something deployed

    Progress is a URL you can open, not a percentage on a slide.

    Each week we push to a staging environment you have access to, and send a short written note: what changed, what is next, what is blocked and what we need from you. Nothing is reported as done until it is running somewhere you can reach. If a week produces nothing deployable, that is the note we send, with the reason.

  4. Decisions are written down next to the code

    Every non-obvious choice leaves a paper trail in your repository.

    Architecture, model choice, schema shape, the third-party service we picked and the two we rejected — each gets a short dated note committed alongside the code, including what would make us revisit it. This is the part most teams skip and then regret at handover, when the only person who knew why has moved on. It also means the engineer who inherits this from us can read the reasoning rather than reverse-engineer it.

  5. Model-backed features start with the test set

    We agree how a feature will be judged before we build it.

    For anything with a model in the loop, the first artefact is a set of real examples from your data with the expected output for each, and a pass bar we both sign off on. Features ship against that harness, not against a demo that worked once in a meeting. When the model or the prompt changes later, the same harness tells you within minutes whether anything regressed.

// the difference

Eight dimensions, and our cost written into every row

Our advantage is directness, senior attention and the absence of an account-management layer — not scale, and not coverage. Where our way of working has a cost, it is in the row rather than left out: capped capacity, nobody covering the channel outside business hours, and no account layer to absorb the questions we cannot get to.

Who you actually talk to

The usual agency engagement

An account or delivery manager relays your questions to engineers you never meet. Answers arrive a day later, slightly reworded.

How we work

You talk to the engineers writing the code, in a shared channel. The trade-off is honest: there is nobody covering the channel outside working hours, so replies land Monday to Friday, business hours IST.

How scope gets agreed

The usual agency engagement

A long requirements document is written and signed before anyone builds anything, then interpreted differently by both sides in week four.

How we work

You click through a reference build first. The written scope describes the thing you already saw, which removes most of the interpretation gap before it costs anyone a month.

What you get each week

The usual agency engagement

A status deck, a burndown chart, and a percentage complete that only moves upward.

How we work

A deployed build on a staging URL, plus a short written note of what changed, what is next, and what is blocked. Including the weeks where the honest answer is that we lost time.

When scope changes mid-build

The usual agency engagement

A change request enters a commercial process. Weeks of estimates and negotiation while the build waits, or the change is absorbed silently and something else slips.

How we work

We re-cut the sequence in the open so you can see what gets pushed back to make room. We tell you within days, in writing, whether something is absorbed or needs re-scoping — and we would rather cut something than quietly extend.

Who owns the code

The usual agency engagement

Ownership transfers on final payment, defined in an annex, sometimes as a licence rather than an assignment. You often cannot see the repository until the end.

How we work

Work lands in a repository you own from the first commit, so you can read every change as it happens. Custom code written for you transfers to you outright.

How the team scales

The usual agency engagement

More people are added to go faster. Who you get varies, and the people who impressed you in the pitch move to the next pitch.

How we work

It does not scale that way. The same senior people stay on the build start to finish, which caps how much we can run at once. If your timeline needs more hands than we have, we will say so at the build review rather than after signing.

Documentation

The usual agency engagement

A handover document written at the end, often by someone who did not build the system, describing what it was supposed to do.

How we work

Dated decision records committed as the choices are made, plus a runbook that has actually been used to deploy the system from scratch at least once.

What happens after launch

The usual agency engagement

A support retainer with tiers and response-time commitments, priced separately and renewed by default.

How we work

A defined handover, then an agreed support window at business hours IST, Monday to Friday. No 24/7 pager and no SLA — if you need round-the-clock cover, that is a staffed function and we will help you plan it rather than pretend to be it.

// ip and reuse

You own what we write for you, from the first commit

Custom code, schemas, prompts and evaluation sets are yours and land in your repository as they are written. The scaffolding we reuse stays ours and ships to you under a licence, listed by name at handover. We do not train anything on your data, and nothing about your project is published without written permission.

  • Who owns the code you write for us?

    You do — in a repository you own from the first commit, not a zip at the end.

    The exact assignment wording lives in the contract and is the version that counts.

    What that covers, and where it lands

    You do. Application code, database schemas, prompts, evaluation sets and infrastructure configuration written specifically for your project are yours, and they land in a repository you own from the first commit rather than being handed over in a zip at the end.

  • What do you bring that was not written for us?

    Reusable scaffolding. It stays ours, ships to you under a licence, and is listed by name.

    The licence terms need final legal wording before they are stated precisely here.

    Which components are reused, and how they ship to you

    Internal scaffolding we reuse across builds: project setup, authentication wiring, deployment pipelines, the evaluation harness, and a set of interface primitives. That scaffolding stays ours, and it ships to you under a licence to use, modify and distribute it as part of your product for as long as you want. Every such component is listed by name in the handover, so nothing about what you own is ambiguous.

  • Do you reuse what you learn on our project elsewhere?

    Not your logic, your data or your interface. Generic engineering technique, yes.

    What can and cannot carry to another build

    Not your domain logic, your data, your workflows or your interface. What can carry over is generic engineering technique — the way a queue is structured, the shape of an evaluation harness — which is the same thing any engineer carries between jobs. If a piece of the build is genuinely your competitive edge, name it early and we will keep it out of anything shared.

  • Can we get exclusivity?

    Default on your build. Negotiable on the shared scaffolding, with real consequences.

    Any exclusivity or sector restriction has to be drafted case by case.

    What carving out exclusivity actually costs

    On work written for you, exclusivity is the default: we do not resell your build. On the shared scaffolding, exclusivity is negotiable but has consequences — carving it out means rebuilding those parts for you, which costs time. Ask before signing rather than after, and we will tell you plainly what it changes.

  • Do you use our data to train anything?

    No. Your data builds and evaluates your system, and nothing else.

    A signed data processing agreement covers this properly and can be requested during scoping.

    Provider settings, and how each one is named for you

    No. Client data is used to build and evaluate your system and for nothing else. Where a third-party model provider is involved we use the configuration that excludes your data from provider training where the provider offers one, and we name every provider in the architecture note so you can check the terms yourself.

  • Will you show our project publicly?

    Only with written permission. Most client work is under NDA and stays anonymous.

    What we publish instead of client work

    Only with written permission. Client work delivered under NDA stays anonymous, and that is most of it. What we publish instead is our own reference build of the same kind of system, built separately on our own time.

Contracts are signed by our parent company, Vruoom. The registered entity details and the standard terms are sent with the first scope document, before anything is signed. The executed contract is the version that governs, not this page.

// ways to work

Three shapes of engagement, each with a stated minimum

A scoped build, an ongoing partnership, or advisory. Each one names the smallest thing we will start and the way it ends, both agreed before anything begins. Scope is settled privately once we understand the problem, so there are no figures on this page.

A scoped build

One system, a recognisable finish line, a handover at the end.

What it suits
A product or internal system with a clear outcome — replacing a manual process, shipping a first version, rebuilding something that has stopped holding up. Best when someone on your side can make decisions without going through a committee.
Minimum commitment
The reference build stage. That is the smallest thing we will start, because starting a full build without one is how projects go wrong.
How it ends
A handover: repository, environments and runbook, decision records, the evaluation harness, a recorded walkthrough, and an agreed support window afterwards.
How this one gets scoped

Build review first, then the reference build as its own bounded stage. The written scope is agreed against that reference: what is in, what is explicitly out, what we are assuming, and the sequence we will build it in.

An ongoing partnership

A standing allocation of senior time against a roadmap that keeps moving.

What it suits
Teams with a product already live and more ahead of them than one build covers. It suits you if priorities genuinely shift month to month and a fixed scope would be out of date before it was signed.
Minimum commitment
One full cycle. We do not take partnership work in fragments, because the ramp-in cost lands on you.
How it ends
At a cycle boundary, with notice agreed up front by both sides. You get the same handover artefacts as a scoped build. There is no version of this where leaving is made difficult.
How this one gets scoped

Scoped per cycle rather than per project. At the start of each cycle we agree what the allocation goes to and in what order; at the end you get the same deployable-and-note rhythm, plus a short review of what actually landed against what was planned.

Advisory

Senior review for teams who have their own engineers.

What it suits
You have a team and you want a second opinion that has shipped this before: architecture review, model and vendor choice, evaluation strategy, what to build versus buy, how to structure the hiring. Also useful before committing to a large build with someone else.
Minimum commitment
A short block of sessions rather than a single call. One conversation rarely produces anything your team can act on.
How it ends
On a fixed end date. Renewal is a deliberate decision rather than a default: if the sessions have stopped being useful, we will say so first.
How this one gets scoped

A fixed cadence of working sessions plus written reviews after each one, so there is a record your team can act on. We do not write production code under advisory; if a prototype is needed to settle an argument, we scope that separately.

// disqualifiers

Four cases where we are the wrong team

A launch date announced before the scope exists, a decision that comes down to lowest bid, a need for round-the-clock cover from day one, or a shop that takes the ticket list and types. If one of these describes you, you will save weeks by reading it now.

  • You need a delivery date you can announce before the scope exists

    We will not commit to a date before the reference build, because any date given at that point is a guess dressed up as a commitment. If the date is already public and immovable, a team that tells you what you want to hear will make you feel better for about six weeks.

  • You are picking on lowest bid

    We put senior people on a small number of builds at a time, and we do not compete on rate with staffing shops or offshore bodyshops. If the decision is going to come down to the cheapest proposal in the pile, we will lose it, and it is faster for everyone if we skip that round.

  • You need 24/7 cover or a contractual SLA from day one

    Support is business hours, Monday to Friday, IST. Round-the-clock response is a staffed on-call function with a rota behind it, not something a small team can honestly promise. If your system needs that on launch day, plan for it properly — we will help you scope it, but we are not it.

  • You want an execution-only vendor

    We push back on scope, question features we think are dead weight, and say when we think an idea will not survive contact with users. If what you need is a shop that takes the ticket list and types, that is a legitimate thing to want and we will slow you down.

// after launch

Handover is a checklist, and support has an end date you agree in writing

You get the repository, the environments, a runbook that has actually been used, dated decision records, the evaluation harness and a recorded walkthrough. Support then runs Monday to Friday, business hours IST, for a window agreed before handover. There is no on-call rota and no contractual SLA.

The handover artefacts

The repository and its history, the environments plus a runbook that has actually been used, dated decision records, the evaluation harness, a recorded walkthrough, every account and credential transferred into your name, and a written note on what we would build next.

All 7 artefacts, itemised
  • The repository, with full commit history and the branch and release conventions we used.
  • Environment and infrastructure configuration, plus a runbook that has been used at least once to deploy the system from scratch.
  • Dated decision records for every non-obvious architectural, model and vendor choice, including what would make us revisit them.
  • The evaluation set and harness for anything model-backed, so your team can keep grading changes after we are gone.
  • A recorded walkthrough of the system, including its known weak points and the failure modes we designed around.
  • An inventory of accounts, credentials and third-party services, transferred into your ownership rather than left on ours.
  • A short written note on what we would build next and what we would watch in the first month.

How defects are handled

A defect is behaviour that contradicts the agreed scope. Inside the support window we fix defects at no further charge.

Worst impact on your users goes first, and we tell you the same working day whether we consider something a defect or a change. If we disagree with you about which it is, we say so directly rather than quietly billing it as one or the other.

How changes are handled

Anything that is not a defect is a change, and a change gets scoped rather than absorbed quietly.

On a partnership, small changes are folded into the next cycle and re-planned in the open. Larger changes are scoped like new work and go through the same reference-first step, because a change big enough to argue about is big enough to see before it is built.

How support works

  • Support runs during business hours, Monday to Friday, IST, over the same shared channel we used during the build. The same engineers answer it.
  • The length of the support window is agreed in writing before handover, so nobody is guessing about when it ends.
  • You keep access to the repository and the decision records permanently. Support ending does not remove anything you own.

What support does not cover

  • Round-the-clock response, an on-call rota, or a contractual response-time guarantee.
  • Uptime guarantees for infrastructure we do not operate, or outages at third-party providers.
  • New features, or changes to how the system is supposed to behave. Those are scope, not support.
  • Systems we did not build, including anything a different team modifies in the same repository afterwards.
  • Model or vendor pricing changes and API deprecations after the support window closes, though we will flag the ones we can see coming at handover.
// starting

Four stages, and you can stop after either of the first two

The build review gives you a written read of your system whether or not we work together. The reference build is a bounded stage that ends with something clickable, and it is yours if you stop there. Only after those two does anything get scoped or signed.

The four stages of a Reference-First Engineering engagement, in orderA left-to-right flow of four stages. Stage 01, the build review, leads to stage 02, the reference build; these two are bounded stages, and you can stop after either one and keep what it produced. Stage 02 leads to stage 03, scope in writing, which leads to stage 04, build in the open. Stages 03 and 04 are the build itself, run in weekly deployable increments.Bounded — stop after either, keep what it producedThe build itself01The build reviewYou keep the write-up either way02The reference buildClickable, and yours if you stop03Scope in writingWritten against what you clicked04Build in the openWeekly deploys, then handover
The first two stages are separately bounded on purpose: they are where the disagreements happen, and that is the cheapest place for them to happen.

  1. The build review

    Send us what exists — a running product, a repository, a half-finished build, or just the spec and the constraints. We spend time with it and write back a plain read: what is solid, what will break under load or under change, what we would cut, and what we would need to know before quoting anything. You keep that write-up whether or not we work together.

  2. The reference build

    A bounded stage that produces a navigable version of the system: the main flows clickable, the data shapes real, no live backend behind it. This is where the disagreements happen, which is the cheapest possible place for them to happen. If you stop here, you keep it.

  3. Scope in writing

    The scope document describes the reference you have already clicked through, plus the build sequence, the assumptions we are making, the things that are explicitly out, and what we need from your side and when. Nothing in it should be a surprise by this point.

  4. Build in the open

    Weekly deployable builds on a staging URL, a written note every week, decision records committed as we go, and a direct channel to the engineers. Then handover, on the terms set out above.

Start with the build review

Send us the system, the repository or the spec. You get back a written read of what is solid, what will break, and what we would do first — yours to keep either way.

Request a build reviewOr just ask a question