Approach
How the work actually gets done.
Most studios describe their process in adjectives. Here's ours in specifics - including the work we turn down.
The method
The four stages.
Scope
Week 0
Written problem summary
A free 30-minute call, no deck. We ask what's not working and what you've already tried. You get back a written summary of the problem as we understand it, which is also the first test of whether we understood it.
Architect
3–5 days
Architecture summary and fixed quote
We map the system, name the constraints and the risks, and decide what sits outside the scope. Then you get a fixed quote with milestones, so you know the price and the shape of the thing before anything is built.
Build
2–6 weeks typical
Working software, weekly
Weekly sprints, each ending in something you can click. You watch it come together, which means scope problems surface in week one instead of week five.
Operate
Ongoing
Handover pack and access inventory
A written architecture summary, a runbook, and an access inventory, handed over with the keys. Launch is the middle of the project rather than the end, so from there either you run it or we do.
Engineering standards
What we hold ourselves to.
Published so you can check them, and so we can't quietly drift. If one stops being true, this page changes.
Stack
Next.js and TypeScript on the front, Node and Postgres behind it, Supabase where it fits. We choose boring, well-supported technology on purpose. The interesting part of your project should be the problem, not the framework.
Testing
Critical paths are tested, and we tell you which ones and why. We don't quote a coverage percentage, because it is trivial to inflate and tells you almost nothing.
Accessibility
WCAG 2.1 AA is the target on everything public-facing: contrast, keyboard operation, focus order, and semantics. Checked before launch, not asserted.
Performance
Budgets set per project and measured before launch. For marketing sites that usually means LCP under 1.8s and CLS under 0.05 on a mid-range phone.
Security
Least-privilege access, secrets never in the repository, dependencies monitored, and your data stays in systems you own. Where something touches customer data we write down what it touches and why.
Documentation
Every project hands over with a written architecture summary, a runbook for the things that need running, and an access inventory listing every account and who owns it.
Ownership
Your repository, your hosting, your accounts, from day one rather than on final payment. If you want to take the project elsewhere in month three, nothing in our setup makes that hard.
Response
One business day by email during an active engagement. We don't offer 24/7 on-call, and we'd rather say so up front than promise it and miss.
How we use AI internally
We use AI. We’re specific about where.
It moves us faster through research, first drafts, and scaffolding. It does not make architecture decisions and it doesn’t ship unreviewed. The judgment is the part you’re paying for, and that stays human.
What we don't do
The work we turn down.
Not because it's bad work - because it isn't ours, and saying so saves us both a call.
SEO retainers and content-performance contracts
We ship SEO foundations as part of a build: structure, metadata, schema, performance. We don't sell ongoing ranking work, because we'd be bad at it and you'd be paying for hope.
Paid ads management
Different discipline, different feedback loop. We'll happily build the landing pages and attribution behind someone else's ad spend.
Logo-only or brand-only projects
We do visual work in service of a system we're building. Standalone identity work belongs with a studio that does only that.
Staff augmentation with no technical input
If we can't influence the architecture we can't be accountable for the result, and accountability is most of what you're paying for.
Have something that needs building?
Tell us what's not working. If we can help, we'll say how.