How we work
No black box.
Just clear progress.
Prototype first, then hand-coded from scratch, then audited before launch and again during the included support year. You watch the build take shape, and you hear about it when something changes.
00Free prototype
Before anything is scoped, we send real screenshots.
You send a short brief. We reply with free prototype screenshots of the direction we would take. Nothing to sign up for, nothing to pay, no obligation. If the direction fits we move to scope. If it does not, we iterate once more for free, or we shake hands and part.
03How the work runs
From a rough brief to a working build.
Inside our process →01 · Phase
Find the signal
We read the brief, ask what is genuinely hard about it, and write the problem down in a sentence you can agree with.
02 · Phase
Build the system
Structure first, then interface. You approve the shape of the thing before anyone writes application code.
03 · Phase
Make it move
We deploy, watch what real visitors do, and fix what the evidence says is broken. Support runs for a year.
SSecurity by design
Threats modelled first. Audit before launch. Re-audit on a schedule.
Security work runs on a timer, not a hunch. Threats are modelled before coding starts, dependencies are pinned and patched as part of the build, and the finished release is audited before launch. The audit repeats at agreed intervals through the support year.
PProgress & reporting
Nothing goes quiet for a fortnight.
Updates land at the close of each build and again at each milestone, written in prose rather than a dashboard. If a decision needs your input, we ask before we take it. Nothing happens off-screen and nothing is kept back for a demo.
What to expect
A focused brief, a free prototype, an agreed scope, a hand-coded build, a security audit, launch, and a year of included support. The pace is set with you before the first invoice.
Built for the real world
Accessibility, responsive behaviour, performance and maintainability are part of the build, not a final pass. We talk about the trade-offs early, so the result fits your goals and the team who will live with it.
Performance, measured not promised
The export is static, so there is no routing runtime to block the main thread and no interactivity for Google to time as INP. Low latency and a fast first paint come from shipping less, not from tuning more. We check Core Web Vitals before launch rather than after the complaints.
Start where you are
Have a rough idea?
That is enough to start.
Email [email protected]. We read every message and answer it ourselves.