Service
Zero to shipped, with the architecture decisions made once.
A fixed scope, a fixed date, and three senior engineers who will still be on the project in month four. Not a discovery phase that bills for six weeks and produces a slide deck.
The problem
What this actually looks like
You have the product clear in your head and a deadline that came from somewhere real — a raise, a pilot customer, a conference. What you do not have is the eight weeks it takes to hire, or the tolerance for a team that needs three of them to learn your domain.
The agencies you have spoken to want a paid discovery phase before they will quote. The freelancers are cheaper and available, but you have done that before and inherited the codebase to prove it.
What you actually need is for the boring decisions — auth, data model, deploys, who gets paged — to be made once, correctly, by someone who has made them before.
Deliverables
What you get
Concrete artifacts, not activities. Everything below is something you can point at and say you received it.
- A working product in your repo and your cloud account, from the first commit
- Fixed scope, fixed price, fixed date, agreed before we start
- Weekly shipped increments you can click, not status reports
- Auth, payments, deploys and monitoring set up properly, not deferred
- Handover documentation written for the engineer who joins after us
- A defined support window after launch, with response times in writing
Timeline
How it works
Ranges, not best cases. The dates below are what it usually takes, including the week something goes wrong.
- 01Week 0
Scope and fix the price
One or two sessions. We write down what is in, what is explicitly out, and what the change-order process is. Then the number does not move.
- 02Week 1
Skeleton in production
Auth, database, CI and a deployed environment on day three, before any feature work. Deploying is not a phase at the end.
- 03Weeks 2–8
Weekly shipped increments
Every week ends with something on a real URL. You use it, we adjust. Nothing accumulates unseen for a month.
- 04Final two weeks
Load, edge cases, handover
The parts that get cut when a project is late, which is exactly why they are scheduled rather than hoped for.
Approach
How we think about this
We build the deployment path before the features. A product that cannot be deployed on day three cannot be deployed on day ninety either, and every team that defers this pays for it during launch week.
We choose unremarkable technology on purpose. Next.js, Postgres, a queue, a boring cloud account. The interesting part of your product should be your product, not the infrastructure holding it.
What we refuse to do
- We will not start a build without a written scope, because that is how a fixed price becomes an argument.
- We will not add a microservice you do not need. Most products at this stage need one deployable and a good schema.
- We will not do pure UI design from scratch. We will build against a design, or build a clean functional interface, but we are not your brand studio.
Work
Work in this area
Engagement
How this is usually bought
Shape
Fixed scope, fixed price
From
$18K – $70K
demo figure
The range is real: a focused internal tool and a customer-facing product with payments and roles are genuinely different jobs.
Full pricingFAQ
Questions people actually ask
What happens if we change our mind halfway through?
Small changes we absorb. Anything that moves the scope gets a written change order with a price and a date impact before we do the work, so you are never surprised by an invoice. Most projects have one or two; that is normal, not a failure.
What if it takes longer than you estimated?
On fixed-scope work, an overrun that is our estimating error is ours to absorb. An overrun caused by scope that was added is a change order. The distinction is written down before we start, which is the only time it can be discussed calmly.
Do we own the code?
Entirely, from the first commit. It lands in your GitHub organisation and your cloud account, with IP assignment signed before any code is written. There are no licence-back clauses.
Can you work with our existing designer?
Yes, and we prefer it. Give us Figma and we will build to it, flagging anything that will be expensive to implement before it becomes expensive.
What happens after launch?
A defined support window is included, with response times in writing. After that, either you take it in-house with the handover documentation, or we move to a retainer. Both are normal; we do not make leaving difficult.
Three people is not many. What if someone is ill?
Every project has two of the three across it, and everything is in your repo with documentation as we go. The honest limit is capacity, not resilience: we can only run a small number of builds at once, which is why the availability line on the homepage is real.