Discovery first. Then slices, never layers.
The same six steps on every engagement, so you always know what week you are in and what happens next. The first one is free and sometimes ends with us telling you we are not the right people.
Book the first callSix steps, in this order
The ordering is the argument: nearly every failure mode we have been called in to fix comes from doing step four before step two.
First conversation
Thirty to sixty minutes, no charge and no deck. You describe the problem, we ask the questions that usually reveal whether it is the problem. If we are not the right people for it we say so on that call, and we usually say who is.
Discovery — paid, two to three weeks
We sit with the people who do the work, not only with the people who commissioned it. The output is a written model of your domain, a build order and a real number. All three are yours to keep, and to take elsewhere, whether or not you continue with us.
Shape
Screens and data model worked out together, because one always breaks the other. Design system first, screens second. This is where scope gets cut deliberately rather than discovered as a schedule problem later.
Build in slices
Each slice is a working, deployed, usable piece of the system rather than a horizontal layer of it. Two-week cadence, demoed against real data. If the budget stops, you stop with something that runs.
Harden
Load testing at realistic volumes, an access-control review, and the failure paths — what the system does when the payment gateway is down, not only when it is up. Monitoring and alerts wired before launch rather than after the first incident.
Handover
Documentation, a recorded walkthrough, and your team performing a deploy, a rollback and a restore themselves while we watch. If they can do all three unaided, the handover is complete.
Why discovery is paid, and why you keep it
A free discovery is a sales meeting. It has to be, because it is being paid for out of the hope that you will sign — which means it is optimised to produce a proposal rather than to produce the truth about your domain. Everyone in this industry knows this and most of us pretend otherwise.
A paid discovery has a different incentive. It is a piece of work with a deliverable, and the deliverable is yours: a written model of your domain, a build order, and a real number. You can take all three to another firm and ask them to quote against it. Some clients do exactly that, and it is a legitimate use of the engagement.
What we are actually doing in those two to three weeks is finding the rules nobody wrote down. The exception that exists because a customer is important. The field two people know to leave blank. The spreadsheet somebody maintains at night. Those rules decide the architecture, and no requirements document has ever contained them.
What discovery produces
- A written domain model — entities, states, transitions and the rules behind them
- The exceptions we found that were not in any process document
- A build order, sequenced by risk rather than by convenience
- A real estimate, with the assumptions it rests on written next to it
- A recommendation on stack, with the reasoning rather than the conclusion
- Duration
- Two to three weeks
- Cost
- Fixed, agreed before it starts
- You keep
- All of it, either way
Slices, not layers
The single decision that most changes how an engagement feels from your side.
- Build the whole database schema
- Build the whole API
- Build the whole interface
- Discover in month five that step one was wrong
Nothing works until everything works. You spend months reviewing artefacts you cannot use, and the first honest feedback arrives after the expensive decisions are already load-bearing.
- One narrow path, all the way through, deployed
- You use it. You tell us what is wrong
- The next slice, informed by that
- Stop whenever you like, with something that runs
Feedback arrives in week three rather than month five, and a change of direction costs the current slice rather than the whole plan.
What the week actually looks like
Written by default. Across four time zones a decision record is worth more than any number of calls — and it is what makes handover possible at all.
- Cadence
- Weekly written summary, fortnightly demo against real data
- Access
- Your repository, your tracker, your staging environment — from week one
- Escalation
- A named engineer and a phone number, not a shared inbox
- Change requests
- Costed and shown before they are absorbed, never after
- Overlap
- UK mornings, Australian afternoons, US calls by arrangement
What we need from you
- One person with authority to decide, roughly two hours a week
- Access to the people who do the work, not only those commissioning it
- Honest answers about what currently gets worked around, and why
Projects stall on the absence of the first item more often than on anything technical.
Six positions we will not trade away
Discovery is paid, and portable
A free "discovery" that produces a proposal is a sales meeting. A paid one produces a specification you own and can take to any other firm. We think that is the honest version, and it is why we charge for it.
Slices, not layers
Building the database, then the API, then the interface means nothing works until everything works. Building one narrow path all the way through means you can use it in week three and correct us in week four.
Your repository, from commit one
Code lives in your organisation account, not ours. There is no escrow, no licence-back and no per-seat fee on something you paid to have built. Leaving is a normal ending, not a penalty.
Written by default
Decisions get recorded, not just discussed. Across four time zones a written decision record is worth more than any number of calls, and it is what makes a handover possible at all.
Boring technology
We choose the option with the largest hiring pool and the longest support window, not the one that is interesting this quarter. You should be able to hire someone who can maintain this without us.
We say no
To work we would do badly, to a language model where a rule belongs, and to a timeline that can only be met by shipping something we would not run ourselves. Turning down work is the cheapest form of quality control.
Working together, answered
How do you communicate during a project?
A written weekly summary — what moved, what did not, what is blocked and what we need from you — and a fortnightly demo against real data rather than against a prototype. You have access to the repository, the issue tracker and the staging environment from week one, so you can see the state of things without asking. Written-first is deliberate: across four time zones a decision record is worth more than any number of calls, and it is what makes handover possible later.
What do you need from us?
One person with the authority to make decisions, available for roughly two hours a week. That is genuinely the most important input, and projects stall on its absence more often than on anything technical. We also need access to the people who do the work — not only the people commissioning the software — because the exceptions that decide the architecture live with them.
How do you handle scope changes?
They are expected, and building in slices exists to absorb them. Because each slice is a working piece of the system rather than a layer of it, changing direction costs the current slice rather than the whole plan. What we surface explicitly is any change that contradicts the domain model, because that is the expensive kind — you see what it costs before you decide, rather than us absorbing it quietly and running late.
Do you work with our existing development team?
Regularly, and it works best when the boundary is clear. Either we own a defined area end to end, or we join your process entirely — your repository, your review standards, your standup. What does not work is an ambiguous split where two teams both partly own the same code, because integration becomes everyone’s second priority and nobody is accountable for the seams.
What are your working hours, and does the time difference matter?
Monday to Saturday, 10:00 to 19:00 IST. That overlaps comfortably with UK mornings and Australian afternoons; US calls are scheduled early or late by arrangement. In practice the time zone matters much less than the working style — teams that write things down get far more out of a distributed arrangement than teams that rely on someone being tappable on the shoulder, which is why we push for written updates and decision records.
The first call is free and has no deck.
Thirty to sixty minutes. You describe the problem, we ask the questions that usually reveal whether it is the problem. If we are not right for it, we say so on the call.