What You Are Buying Is a Long Run of Decisions
Nobody purchases code by the line. You are buying several hundred choices about what the software does, who it does it for and what it will refuse to do — most of which get made in the first fortnight and quietly set the cost of everything afterwards.
Decisions Get More Expensive the Longer They Stay Implicit
Whether a job sheet can be edited after it has been signed. Whether a branch manager can see another branch’s figures. Whether a failed Direct Debit chases itself or lands on somebody’s desk. None of these sound like technical questions and every one of them changes the shape of the software.
Left implicit, they get decided anyway — by whichever developer reaches that screen first, at half past four on a Thursday, without asking. Discovering that in month three costs multiples of what it cost to ask in week one. So the process below is not a delivery ritual. It is a mechanism for dragging the consequential decisions forward while they are still reversible, and for making it obvious when one has been made.
How the engagement models differHow Cheap a Change Is Depends Entirely on When You Ask
The same request costs four different amounts depending on which of these bands you are in when you make it. Nothing is ever locked forever; it is locked until you decide the move is worth paying for.
On a call, before anything is written
Free. Change the product entirely if you want to. This is the stage people rush through fastest and should not.
In the prototype, before production code
Cheap. Moving a screen, adding a field, changing who can see what — hours of design work rather than days of engineering and retesting.
Mid-build, between sprints
Priced. It becomes a written change request with an estimate in hours and pounds, and a note on whether the launch date moves.
After launch, with live data in it
Expensive. Now there is a migration, a release, a regression risk and real users who learned the old behaviour.
This is why we push so hard on the prototype stage. It is the last point at which you can change your mind about something structural for the price of an afternoon.
From the First Half Hour to the Support Window
Timings describe a typical first version. A larger product stretches the middle of this; it does not change the shape.
Stage one — the estimate call
Thirty to forty-five minutes, no charge, no obligation and no deck. The purpose is to establish whether what you want can be built for the money you have, and to say so if it cannot.
The questions that actually move the number
- How many distinct kinds of user are there, and can they see each other’s data?
- Does money move through it, and does anyone need a refund or a credit note?
- Whose systems must it talk to, and do you control the credentials for them?
- What personal data does it hold, and does a regulator or a public sector buyer have views?
- Between the budget and the date, which one is genuinely fixed?
What arrives afterwards
Within two working days: the features we heard written back to you, a sterling range excluding VAT with the assumptions it depends on, a timeline in weeks, and an explicit list of what we would leave out of version one and why. If we think you should not build this yet, that sentence is in the document as well. The scope is yours to take elsewhere.
Stage two — discovery, design and a prototype you can tap
Usually one to three weeks. Discovery converts the scope into settled decisions: the roles and what each one may see, the data model, the third-party services, the business rules that are invisible on a screen but govern everything behind it. Design turns those decisions into something you can look at and argue with.
You receive the full screen set plus a clickable prototype — a linked mock-up you open on your own phone or laptop and move through as though it worked. Put it in front of three people who resemble your real users before you approve anything. Nearly every project changes something here, which is precisely the point.
What sign-off fixes, and what it leaves open
Approving the prototype fixes four things for version one: the inventory of screens, the navigation between them, the set of user roles, and the list of external systems we integrate with. Those four are what make a fixed price possible, because we are pricing a defined thing rather than an intention. What stays open is everything inside a screen — wording, ordering, spacing, validation messages, the look of a state nobody thought about. Those keep changing throughout the build at no extra cost. Adding a fifth role or a sixth integration does not; that becomes a change request with a number attached.
Stage three — fortnightly sprints
Production work runs in two-week sprints. Each opens with a written goal you have agreed and closes with a build you can install and use yourself, on your own device, without a screen-share.
Sprint one looks nothing like sprint four
Sprint one is the least impressive fortnight of the project. Repositories and cloud accounts created in your company’s name, environments separated, the database schema, sign-in, the deployment pipeline, and one thin slice that runs end to end so we have proved the whole stack fits together before anything depends on it. On a UK build this is also where data residency gets settled, because moving a database between regions later is a migration rather than a setting.
By sprint four the foundations are behind us and visible product arrives quickly. Features land in the priority order you set, so if something has to fall out of version one it is what you already told us mattered least. Anything that depends on a third party — a payment provider, an accounting system, a supplier’s API — is pulled forward rather than left to the end, because that is where the unpleasant surprises live.
How quality assurance is handled
Testing is not a phase bolted onto the end. Every feature is checked against its acceptance criteria before the sprint closes, on real handsets and real browsers rather than a simulator alone. Automated tests go where being wrong would be costly: payments, permissions, tax and pricing calculations, anything touching personal data. You get a test account from sprint two and we would rather you tried to break it. Defects you raise go on the same board we use, with a severity and a named owner. Anything critical is fixed inside the current sprint instead of being queued behind new work.
How change requests work
Ask for anything whenever you like. Adjustments inside a screen we have already agreed are absorbed as ordinary work. Anything that adds a screen, a role, an integration or a new business rule comes back the same day or the next as a short note: what it touches, an estimate in hours and pounds excluding VAT, and whether it moves the launch date. You approve or decline in writing and only then does it enter a sprint. Nothing is ever done quietly and invoiced at the end, which is how fixed-price projects turn into disputes.
Stage four — launch, and the weeks after it
Release is a piece of work in its own right rather than an afternoon. For mobile we prepare the store listings, screenshots, privacy declarations and the Google Play data safety form, submit under your own developer accounts, and deal with review feedback until it is approved. First submissions are routinely rejected for reasons unconnected to code — a missing account deletion route, an unclear answer about data collection — so review time sits in the plan from the beginning.
The release checklist
- Production separated from staging, with backups running and a restore actually tested
- Error tracking, uptime monitoring and analytics wired up before the first real user arrives
- Live Stripe, GoCardless or Direct Debit keys proven with a genuine transaction, not a sandbox one
- Privacy notice, terms and cookie handling published, with your ICO registration details in place
- An accessibility check against WCAG 2.2 AA, and a statement drafted if you sell to the public sector
- A written rollback route if the first release goes badly, and handover credentials confirmed in your accounts
The post-launch support window
Every build carries a support window after release, typically thirty days and set out in the contract, during which defects in what we delivered are fixed at no charge. It covers faults, not fresh ideas: if real usage reveals something you now want built, that is quoted as new work rather than argued about. Most clients move onto a maintenance retainer as the window closes, because the month after launch is when an operating system updates and real users find the corners nobody tested.
Maintenance and supportFour Things Only You Can Supply
Projects very seldom slip on engineering. They slip waiting for an approval, a credential or a business rule that only one person in your company knows.
One person who can say yes
A named decision-maker with authority over designs, scope changes and the release date, who can turn an approval around inside two working days. Consultation is fine; an unscheduled board meeting in sprint three is not, because engineers cannot idle while a committee forms a view on a screen.
Access we cannot conjure
Credentials for anything we integrate with: your payment provider, accounting package, CRM, existing database, and the Apple and Google developer accounts. We create what does not exist in your company name, but we cannot invent access to a system a third party controls. Chasing a supplier for API keys in week six is the most common single cause of delay we see.
The rules that live in one head
How a discount is really calculated. Which customers are billed monthly and which on a purchase order with 30-day terms. Who is allowed to authorise a credit. What happens to a job when the engineer marks it complete but the customer disputes it. We can design around any answer; we cannot guess one.
Twenty minutes with every build
Install each fortnightly build and use it properly. Twenty minutes of genuine clicking is worth more than an hour of discussion. Say when something feels wrong even if you cannot articulate why — that instinct is usually correct and acting on it in sprint three is far cheaper than in launch week. Silence reads as approval.
Our Working Day Against Yours, Without the Sales Gloss
The delivery team works to Indian Standard Time. Rather than imply otherwise, here are the four commitments we can keep every single week, and the limit that comes with them.
9am–1pm
The overlap with your working day, UK time. Scheduled calls are booked inside it, so you are never asked to take one in the evening.
Daily
A written update at the close of every working day in your project channel: finished, blocked, next. A record you can scroll back through, not a meeting you must attend.
1 day
Anything you raise gets a substantive reply within one business day. Where an answer needs investigation you are told that, plus when the real answer will arrive.
2 weeks
A working build you can install at the close of every sprint. Progress you can hold in your hand is considerably harder to overstate than a status report.
The honest limit: something you send at 4pm UK time is answered the next morning, not that evening. We do not have a UK office, we do not claim round-the-clock cover, and we will not pretend a fifteen-hour support desk exists. A commitment we keep every week is worth more than one we meet in the first month and quietly drop in the third.
Where Our Responsibility Ends and Yours Begins
Ambiguity here is where most supplier relationships sour. Read it before you sign anything, with us or with anybody else.
Engineering and delivery
- Architecture, data model and the technology choices behind them
- Interface design, the clickable prototype and the build itself
- Testing on real devices, and automated tests where they earn their keep
- Accessibility to WCAG 2.2 AA as we build, rather than as a late correction
- Environments, deployment pipeline, monitoring and backups
- Store submission, review responses and written handover documentation
Decisions, access and content
- Approving designs, change requests and the release date
- Credentials for systems you or one of your suppliers controls
- Holding the Apple and Google developer accounts and paying their fees
- Final wording, logos, brand assets and your privacy notice and terms
- Deciding the business rules nobody outside your company can decide
- Being the data controller, and registering with the ICO where required
In scope if it is in the contract
- Migrating data out of an old system, which is usually its own workstream
- Drafting in-app wording where you would rather we made a first attempt
- Running your cloud infrastructure after launch instead of handing it over
- Evidence packs for a client security questionnaire or a funding due diligence
- Training your staff on an internal system we have built for them
Things we decline to pretend about
- Legal advice, or acting as your data protection officer
- Marketing, store optimisation or paid user acquisition
- Paying your cloud hosting, licence or third-party API charges
- Guaranteeing app store approval, which is nobody’s to promise
- Claiming a UK office, a UK-based team or cover outside the stated overlap
Situations This Process Is Designed to Survive
Every one of these has happened on real projects, ours and other people’s. A process that only works when nothing goes wrong is decoration.
How an Engagement Ends, Including Badly
Whether we part after a single first version or after three years, none of the handover should require negotiation. There is no transfer event for the code, because it was never held on our side.
Notice, on paper
A fixed-price project ends when the scope is delivered and the support window closes. A monthly engagement ends on one month’s written notice from either side, with no exit fee and no argument about the final invoice beyond work genuinely done.
The handover pack
An architecture summary a new engineer can read in an afternoon, environment and deployment notes, design files and prototype, test credentials, and an honest list of known issues and shortcuts — including the ones that are awkward for us to admit.
A walkthrough call
With whoever picks it up, whether that is your own hire, another agency or nobody yet. Recorded if you want it, so the person who joins in six months hears the same explanation as the person who joined today.
Access closed down
Any credentials we held are rotated and removed from our side, and we confirm in writing when that is complete. You already own the repositories, the cloud subscriptions, the domains and the store listings, so there is nothing for us to release.
Practical Questions About Running a Project With Us
Who is our day-to-day contact, and what happens when that person is on leave?
You have one named lead who runs the calls, writes the end-of-day update and owns the sprint plan. Cover is arranged in advance rather than improvised: before any planned absence you are told who is standing in, and that person is already on the project rather than reading themselves in on the day. Because every decision lives in the written update and on the shared board rather than in one head, a handover mid-project does not cost you a week of re-explaining.
Can you work inside our Jira, Teams or Slack rather than your own tools?
Yes, and we would prefer to where you already have something running. We will use your board, your channel and your ticket conventions, and we keep a mirror of the sprint plan on our side so nothing is lost if your licence lapses or access is withdrawn. What we will not do is run the project in two places with different content in each. If you have no tooling, we set up a board in your account, not ours.
What actually happens when a sprint goal is missed?
You hear about it in the daily update on the day it becomes likely, not at the review a week later. The sprint still closes on schedule with a working build containing whatever is genuinely finished, and the unfinished item moves to the top of the next sprint. If the cause was our estimate on a fixed-price project, the extra effort is ours to absorb. If the cause was a dependency on your side or a third party, we say so plainly and re-cut the plan with you rather than quietly consuming float and announcing a delay near the end.
Our IT supplier or in-house developer wants to work alongside you. Is that a problem?
It is common and usually helpful, particularly where they hold knowledge of an existing system we have to integrate with. We agree the boundary in writing at the start: which repositories and areas of the codebase each side owns, how code review works across the two teams, and who approves a release. The failure mode to avoid is two teams editing the same module in different directions, which costs more to untangle than either party saved. Where the other supplier is the incumbent being replaced, we would rather run a defined handover than an indefinite overlap.
What happens to our data and our users’ data during the build?
Development and staging run on synthetic or anonymised data wherever that is workable, because the safest copy of your customer records is the one we never hold. Where real data genuinely is needed, for example to test a migration, it is minimised, access is limited to the engineers on that task, and it is removed when the task is done. We sign a data processing agreement, we will tell you which region each environment runs in, and we help you keep the records of processing your own obligations under the Data Protection Act 2018 require. We are a supplier, not your data protection officer, and we will not pretend otherwise.
Book the Half Hour That Starts It
No charge, no obligation, and you leave with a written scope and a sterling range excluding VAT whether or not you go on to hire us.