Four steps from first call to launch. An agreed scope, a working prototype early, amendments folded in as we go, and nothing live until you have confirmed it.
No account managers
·Agreed scope
·You own everything
01
Call
One focused call to understand what you need, who it is for, and what success looks like. You leave with a clear, written scope and a proposal.
The first call is not a sales pitch. We want to understand the actual job: who uses this, what they are trying to get done, what happens today instead, and what would count as it having worked.
We will ask what you have already tried and what your constraints are. Being open about those early is not a negotiating tactic, it is how we work out whether we can do something genuinely useful for you or whether we should tell you to look elsewhere.
You leave with a written scope and a proposal. If we do not think we are the right people for it, you leave with that instead, and usually a suggestion of who is.
What you get
A written scope and a proposal
Your part
One call, and openness about your constraints
02
Prototype
You are clicking through a working prototype with most of the core features live, early in the project. Real screens in the browser, not static mockups.
We build the real thing early and rough. You get a link you can open, click through, and show to someone else. The main flow works. It is not finished and it is not pretending to be.
This exists because written specifications are a bad medium for interfaces. Everyone reads the same paragraph and pictures something different, and the disagreement only surfaces when the build is done and expensive to change.
Your job at this stage is to be difficult. Tell us what is wrong, what is missing, and what you did not realise you needed until you saw it. This is the cheapest moment in the whole project to change your mind.
What you get
A clickable working prototype at a private URL
Your part
Use it properly and tell us what is wrong
03
Refine
We shape the prototype into the finished product, folding in every amendment you ask for. Nothing ships until you have confirmed the final build.
The prototype becomes the product. Edge cases, empty states, error handling, loading behaviour, responsive layouts, accessibility, and the hundred small things that separate something that demos well from something that works.
Amendments are folded in as we go rather than saved for a review at the end. You see progress continuously at the same link, so there is never a moment where you are waiting in silence wondering what is happening.
Nothing goes live until you have looked at the finished build and confirmed it.
What you get
The finished, tested product, confirmed by you
Your part
Review as it goes, and sign off at the end
04
Deploy
We take it live on the hosting provider and domain of your choosing, fully wired up, and stay close after launch to keep it running smoothly.
We deploy on your domain, either into your own hosting account or onto infrastructure we manage for you. Analytics, monitoring, backups, and email delivery are configured as part of going live rather than left as homework.
You get the code, the repository, and written documentation. If you take the project in-house or to another team in a year, everything you need is already yours.
Then we stay close. Launch is when you find out what you actually built, and the first few weeks usually surface something. We are around for it.
What you get
Live on your infrastructure, with full handover
Your part
Tell people about it
The principle underneath
Prototypes beat specifications
Written requirements are a bad medium for interfaces. Everyone reads the same paragraph and pictures something different, and nobody finds out until the build is finished.
So we build the real thing early and rough, and ask you to try to break it. The cost of a change rises steeply with how much has been built on top of it: a flow changed in week two touches a handful of files, and the same flow changed in week nine touches the six screens built assuming it. Prototyping front-loads every disagreement to the cheapest week of the project.
Thirty to forty-five minutes working out what the actual job is: who uses it, what they are trying to get done, what happens today instead, and what would count as success. We ask about budget early because it determines whether we can do something genuinely useful for you. You leave with a written scope, a timeline, and a fixed price.
How soon do I see something working?
Within the first week or two you have a link to a working prototype with the core flow running in a browser. It is rough on purpose. It exists so disagreements surface while they are still cheap to fix.
How often will I hear from you?
Continuously, at the same link. Progress is visible rather than reported, so there is never a stretch where you are waiting in silence wondering what is happening. You talk directly to the people building it, not to an account manager.
What if I want to change something halfway through?
Expected, and included. Prototyping early exists precisely so you can change your mind while it is cheap. Something genuinely outside the agreed scope gets priced separately and you decide whether to add it. Nothing appears on your invoice that you did not agree to.
What do you need from me?
About an hour for the first call, honest feedback on the prototype, and whatever content you already have. The most common cause of a late project is waiting for copy, images, or access to an existing system, so the earlier those arrive the better the schedule holds.
What happens after launch?
Post-launch support is included: two weeks on a focused build and thirty days on product and mobile builds. Monitoring is configured as part of going live, so we often know about a problem before you do. After that you can move to a monthly arrangement or just come back when you need something.
Next step
Start with a call
No obligation, and you leave with a written scope and a proposal whether or not you go ahead.