01/BUILD A NEW PRODUCT
You need to build something, and it needs to actually run.
You have a product in mind — sometimes a full specification, sometimes a clear problem and a rough shape for the answer.
What you do not have is an engineering team, and hiring one is a six-month project of its own before a line of code gets written.
The version that worries you is the one where an agency builds the application, hands over a repository, and you discover that nobody thought about how it gets deployed, what it costs to run, or who gets called when it stops.
You want the thing built and you want it running, and you would prefer those to be the same conversation.
01/Why it happens
It is nearly always one of these three.
The build and the run are usually sold separately
Application work and infrastructure work come from different vendors with different incentives. The architecture gets chosen by whoever cannot see the bill.
Cost is discovered rather than designed
Nobody prices the architecture while it is still cheap to change. The first serious invoice arrives after the decisions have hardened into a running system.
Scope grows in the gap before anything ships
The longer a project runs without something working in front of real users, the more features get added on the strength of opinion rather than evidence.
02/What we do about it
The engagement, phase by phase.
Shape and scope
one to two weeks
We work out what the first version has to do, what it explicitly will not do, and the shape it runs on. You get the running cost estimated here, while changing it is still free.
Produces
A written scope, an architecture outline and an estimated running cost
Foundations
one to two weeks
Before feature work starts there is a repository, a pipeline that deploys on merge, and an environment on AWS. Everything after this point is continuously deployable.
Produces
A repository, a deploy pipeline and a live staging environment
Build in slices
the bulk of the project
Vertical slices through the whole stack, each one usable. You see progress in the running application every week rather than in a status document.
Produces
A widening application, deployed to staging continuously
Harden and launch
one to two weeks
Load behaviour, authentication review, backups restored as a test rather than assumed, alerts wired up, then the production cutover.
Produces
The product in production, with alerting, backups and a runbook
Run it
ongoing, and optional
Your team takes it with a runbook and a recorded walkthrough, or we keep running it. The build is not conditional on choosing the second option.
Produces
Either a clean handover or an ongoing support arrangement
03/What done looks like
How you will know it worked.
- The product is live, on your own domain, serving real users
- A merged pull request reaches production without anyone performing a ritual
- The monthly infrastructure cost is a number you knew before launch, not after
- Backups exist and have been restored from at least once
- Alerts fire on conditions your users would notice, and reach a named person
- Your team can read the architecture document and explain the system to someone else
04/Honest caveats
Where this gets harder.
Every engagement has failure modes. Here are this one’s, before you commit to anything rather than after.
- A fixed scope and a fixed date cannot both survive a discovery that changes the problem. When one has to move, we will tell you early and let you choose which.
- If the product's core assumption turns out to be wrong, building faster does not help. We will raise it rather than quietly building the thing anyway.
- Estimates given before the shaping phase are guesses. We will give you one if you need a rough figure, and it should be treated as exactly that.
- Integrating with a third-party system we cannot access until the project starts is the most common cause of a slipped date, and it is largely outside our control.
05/Questions
Build a new product, asked about.
01Can you start from just an idea?
Yes. The shaping phase exists for exactly that. It is faster if you have designs or a written spec, but a clear description of the problem and who has it is enough to begin.
02How much does a first version cost?
It depends on scope, and any figure offered before the shaping phase is a guess dressed as a quote. Tell us what you have in mind and we will give you a range with the assumptions behind it stated plainly.
03What if we want to take it in-house later?
That is a normal outcome and the handover is built for it — your repository, documented architecture, infrastructure as code and a recorded walkthrough. Nothing in the stack requires us to stay involved.
Sound familiar?
Describe your version of it. You will get a reply from an engineer within one business day, including if we think you do not need us.