Process

No black box, stage by stage.

Q: How is pricing structured?

Fixed scope, fixed price, agreed in writing after the discovery call. If scope changes mid-project, the change is priced and approved before we build it. No surprise invoices.

Q: Who owns the code and the IP?

You do. Repositories and accounts are transferred to you at launch, not licensed back to you.

Q: How do we communicate during the build?

A weekly demo on a live URL, plus an async channel for day-to-day questions. No status-report theatre. You see the actual product every sprint.

Q: What happens after launch?

30 days of support are included with every full build. After that, a maintenance retainer is optional. Nothing is forced.

Q: How quickly can you start?

Discovery usually starts within a week or two of the call. Build slots are booked in sequence, so the exact start date is confirmed in writing with the scope.

Q: What do you need from us during the build?

About two hours a week: one demo, plus decisions when a question is genuinely yours to answer. Everything else is our job.

Four stages, each with a fixed duration and a clear answer to "what do I get, and what do I need to do."

Discover

1 week

One call, one written scope. You leave knowing price and timeline.

You do: Share what you have and what's not working.

Design

2 weeks

Flows and screens you approve before a line of product code is written.

You do: Review and sign off on flows, screens, and the token system.

Build

4–10 weeks

Weekly demo on a live URL. You test what exists, not a status report.

You do: Use the live build every week and flag what's off.

Launch & support

30 days

Deploy, hand over the code and the accounts, then 30 days of support.

You do: Go live, hand your team the keys, raise anything that breaks.

What a discovery week actually produces

"Discovery" is the word agencies use for the week you pay for and can't inspect. Here is the full list of what lands on your side of the table at the end of ours, whether or not you continue with us.

A written scope

The sequence we're building, what is explicitly not in it, and the assumptions behind both, so nothing important is carried only in someone's memory.

A price and a date

Fixed, in writing, with the mechanism for changing them spelled out before anyone needs it.

A baseline measurement

Where the current numbers actually sit, covering load times, drop-off and whatever the project is meant to move, recorded before we touch anything.

A risk list

What could make this late or expensive, ranked, with the mitigation for each. The uncomfortable ones go at the top.

An honest recommendation

Including "you don't need us yet" or "this is the wrong first project" when that is what the week actually showed.

Baseline first, ship second, prove third

We measure before we build

Most agency work cannot be proved to have worked, because nobody wrote down what "before" looked like. We take the baseline in discovery, load times, drop-off points, how long the manual process actually takes, and record it in the scope.

That order matters commercially. It means the launch conversation is about measured movement rather than impressions, and it means we can be told we were wrong. An agency that never baselines can never be held to a number, which is convenient for the agency and expensive for you.

Baseline. Instrument the current state and agree which numbers this project is meant to move.
Ship. Build in two-week sprints, each ending on a live URL.
Prove. Re-measure the same numbers after launch and publish the comparison, including where it fell short.

Budgets we commit to

These are thresholds, not aspirations: a build does not ship below them without a written note explaining why, agreed with you.

Metric	Commitment	How it's held
Lighthouse performance (mobile)	≥ 90	Measured on the launch build, on the real domain
Lighthouse accessibility	≥ 95	Plus a keyboard-only pass and an axe run with zero serious violations
WCAG conformance	2.1 AA	Treated as a bug class, not a nice-to-have
Largest contentful paint	< 2.5s	On a mid-tier device over 4G
Cumulative layout shift	< 0.1	No content jumping as the page settles

We hold this site to the same numbers, see our current measurements and our accessibility statement.

What a monthly report contains

One page, same shape every month, sent whether or not the month went well.

IncludedWhat shipped, with the live URL to check it against
IncludedWhat slipped, why, and the revised date
IncludedBudget burned against budget planned
IncludedThe numbers we baselined at discovery, re-measured
IncludedWhat we need from you next month, with dates
IncludedRisks that changed status since last month

Frequently asked

Fixed scope, fixed price, agreed in writing after the discovery call. If scope changes mid-project, the change is priced and approved before we build it. No surprise invoices.

You do. Repositories and accounts are transferred to you at launch, not licensed back to you.

A weekly demo on a live URL, plus an async channel for day-to-day questions. No status-report theatre. You see the actual product every sprint.

30 days of support are included with every full build. After that, a maintenance retainer is optional. Nothing is forced.

Discovery usually starts within a week or two of the call. Build slots are booked in sequence, so the exact start date is confirmed in writing with the scope.

About two hours a week: one demo, plus decisions when a question is genuinely yours to answer. Everything else is our job.

Ready to see it run on your project?

Thirty minutes, and you leave with a written scope, a price, and a date.

Book a free discovery call