// how we work
Predictable shape,
even when the details are not.
Most projects follow the same arc, and knowing it up front removes most of the anxiety. Here is what happens, in order, and what you get and what we need at each step.
Scoping
What the thing actually needs to do.
We talk through what it needs to do, who uses it, and what happens when it works. This is where the real decisions get made, and it is the step worth slowing down for.
The goal is to find the two or three choices that shape everything after them, before any code exists. You do not need a specification document or a wireframe to start. You need to be able to describe the problem, and we take it from there.
A shared understanding of the goal, a rough sense of scope and cost, and an honest read on whether we are the right fit.
The problem in your words, who it is for, and any hard constraints: deadlines, systems it has to talk to, and a budget range.
Spec
A written description of what will be built.
You get a written description of what will be built, what it will cost, and what is deliberately out of scope. The boundary gets drawn before work starts, because that is the only time drawing it is cheap.
Scope creep is rarely a discipline problem. It is usually an ambiguity problem, and the spec is how we remove the ambiguity. You should be able to read it and know exactly what you are buying, including the parts we agreed not to build.
A written spec covering scope, cost, and exclusions, so you can compare it against any other quote.
Your review and sign-off before the build starts. Nothing moves until the boundary is agreed.
Build
Reviewable pieces, not a black box.
We work in reviewable pieces rather than disappearing for three months and returning with a slideshow. You see progress on a real URL as it happens, on real devices, not in a mockup.
When something in the spec turns out to be wrong, and something usually does, we would rather find it in week two than at launch. Working in the open is what makes that possible, and it keeps the cost of a correction small.
A staging URL you can watch, working increments as they land, and a channel to give feedback while changes are still cheap.
Timely feedback on each increment, and one decision-maker on your side so we are not taking direction from two places at once.
Launch
Deployment, redirects, monitoring, and a walkthrough.
Launch covers the unglamorous parts that decide whether go-live is calm or chaotic: deployment, redirects so you do not lose the search traffic you already have, monitoring so problems surface before your customers report them, and a walkthrough so you know how to operate what you now own.
Launch is not the end of the project. It is the point where the thing starts meeting real users, which is when you find out what you got right. We stay close through that window rather than handing over a password and leaving.
The site live, redirects preserved, monitoring in place, and a walkthrough of how everything works and where it lives.
Access to your domain and DNS, though we set the accounts up under your name from the start, and your sign-off on the launch checklist.
After
Fixes and questions are part of the deal.
Fixes and questions are part of the deal. We do not vanish the day after go-live. Bugs get fixed, questions get answered, and the decisions we made are documented in the code.
When you want to grow the thing later, that documentation is what makes it a continuation rather than a rebuild. The next person who touches the work, whether that is us or someone you hire in five years, should be able to follow it.
Support after launch, documented decisions, and code you own outright, in accounts under your name.
Nothing but a way to reach you.
What we ask of you
These are the things that, when they slip, are the usual reason a project drags. None of them are complicated, and all of them are on your side of the line.
- One decision-maker on your side. We will happily talk to your whole team, but the call needs to land with one person.
- Feedback while it is still cheap. An increment reviewed in a day costs less to change than one reviewed in a month.
- Access to what we need, when we need it: domain, hosting, and any third-party accounts the project depends on.
- Honesty about budget and deadlines early, so we can scope to reality instead of guessing at it.
What we will not do
Limits are worth stating as plainly as promises. These are ours.
- We will not promise a search ranking or a timeline we cannot control. We will tell you what the work depends on.
- We will not hold your site hostage. Accounts and infrastructure live in your name, so leaving us is a choice you keep.
- We will not sell you a rebuild when a smaller fix would do, and we will say so if a template genuinely fits your needs.
- We will not disappear after launch, and we will not pretend a problem is not there to avoid an awkward conversation.