Our Process: Brief to Deployment
Three stages: scope, build, ship. Each one is faster than you expect, and each one has specific things we need from you to keep it moving. Here is exactly what happens at each stage.
The homepage shows three steps. This article goes deeper on what actually happens inside each one. If you are considering working with us and want to know what to expect, this is the detailed version.
Stage 1: Scope (Day 1)
The scope stage is a single working session, usually 2 to 4 hours. It results in a written specification and a fixed-price quote.
What we need from you: a clear description of what you want to build, who it is for, and what success looks like. This can be rough. A voice note, a brief document, or a 20-minute call works fine. We will ask clarifying questions and structure it.
What we produce: a specification document that describes exactly what will be built, the data model, the user flows, and the success criteria. Plus a fixed price and timeline.
You review the spec and either approve it or request changes. We do not start building until the spec is approved. This is where disagreements are cheap to resolve. After the build starts, changes cost time.
What happens if the spec is not approachable
Sometimes a brief arrives that is underspecified in ways that matter: the problem is clear but the audience is vague, or the feature set is defined but the success criteria are not. In those cases, we push back and ask for more before writing the spec.
This is not gatekeeping. It is the thing that prevents a build from going in the wrong direction. A spec written from an underspecified brief will produce software that solves the wrong problem.
Stage 2: Build (Days 2 to N)
The build stage runs from spec approval to a working deployment in a staging environment. For a simple site, this is Day 2. For a full SaaS product, this might be Day 5 to 7.
What we need from you during the build: availability for questions. Typically 2 to 4 brief exchanges over the course of the build. These are usually about visual judgment calls or clarifications on behavior that the spec did not fully specify.
What you will see: we send a staging URL at the end of each day. You can review what was built, flag anything that does not match your expectations, and provide direction. We incorporate feedback into the next session.
The feedback loop
We prefer concentrated feedback over drip corrections. Seeing the staging site at end of day and sending one consolidated list is better than sending five individual notes throughout the day. It keeps the build momentum and reduces context switching.
We will flag anything we think needs your input before you send feedback. If there is an open question about how something should work, we ask rather than guess.
Stage 3: Ship
Shipping is the last stage and usually the fastest. It involves: final review against the spec, deployment to production, domain configuration, and a handoff document covering what was built and how to maintain it.
What we need from you: access to your domain DNS, and sign-off on the staging build. If you need specific hosting accounts set up, we will walk you through the setup or handle it with your access.
What you receive: a live product at your domain, source code in a repository you control, and documentation covering the architecture, how to deploy changes, and any integrations that need ongoing credentials.
Typical timelines
Static marketing site (5 to 10 pages): 1 to 2 days. Simple web application (auth, CRUD, one core workflow): 3 to 5 days. Full MVP with multiple features and integrations: 1 to 2 weeks.
These are delivery timelines, not billing timelines. The fixed price is agreed at the end of the scope stage and does not change if the build takes longer than expected on our end.
After delivery
We offer ongoing support contracts for clients who want a continuing relationship: feature additions, bug fixes, and infrastructure management. These are scoped separately.
We also offer a retainer model for teams that want a consistent build capacity without committing to specific projects upfront. If you have a pipeline of features coming, a monthly retainer is usually more efficient than individual project scoping.