How we take a product from spec to production.
The same five phases we used to build ScopeCrafters and ContentVo, adapted for client work. It's written down, it's predictable, and it starts by deciding what not to build.
Why the process looks like this.
Most software projects don't fail on engineering. They fail on scope that keeps growing, on feedback that arrives too late, and on launches where nobody can tell whether it worked. Our process is designed against those three failures.
The written spec with an explicit out-of-scope list deals with scope. Preview deployments from the first week mean feedback arrives early. Analytics and a success measure agreed before launch mean you can tell whether it worked.
It's also the process our own products went through. ScopeCrafters' spec listed fifteen things we would not build at launch, from voice input to CRM features. That list is the reason billing, four trades and a referral system shipped within four days of the first commit.
Five phases, each with a deliverable.
- 01
Spec and cutDays 1–3
We turn your problem into a written spec: who the product is for, the one workflow they'll pay for, the user flow step by step, the data model, the API surface, and an explicit out-of-scope list. It also states how we'll know the launch worked. You sign off before any code is written, and it's the document every later request is checked against.
- 02
FoundationWeek 1
The repository is created in your GitHub organization and deployed to your Vercel and Supabase accounts. We build authentication, the database schema with row-level security on every table, and billing wired to webhooks. A preview URL goes live in this first week and stays current for the rest of the project.
- 03
Core workflow, in slicesWeeks 2–4
The paid workflow is built end to end in thin, working slices rather than layer by layer, so there's always something you can click and react to. For AI features, this is where prompts and schemas are tested against your real inputs, with output validation and quality checks.
- 04
LaunchFinal week
Production deployment on your domain, transactional email, analytics and error monitoring, plus the technical SEO foundation: server-rendered pages, unique metadata, sitemap, robots, structured data and llms.txt. We work through a written launch checklist together.
- 05
After launchAgreed in writing
Post-launch work is never implied. It's either a defined iteration with its own scope, or a monthly retainer for ongoing improvements, chosen based on what the launch data shows.
Timelines vary by service. See the specific schedules for SaaS MVP development, AI product development and LangGraph agent development.
How you'll hear from us.
- 01
A preview you can always click
Every change deploys to a preview URL. You never have to wait for a demo to see where things are.
- 02
A written update every week
What shipped, what's next, and any decision we need from you, in writing so there's a record.
- 03
One shared channel
Questions go in one place, and decisions get copied back into the spec so it stays the single source of truth.
- 04
Scope changes are explicit
If something new comes up, we write down what it costs in time or money and what it displaces. You decide.
What we need to move fast.
- One decision-maker who can sign off on the spec and answer questions within a day or two.
- Access to real examples: customer conversations, documents, sample inputs. AI features especially are only as good as the data we test them on.
- Accounts in your name for GitHub, Vercel, Supabase and your billing provider, or permission for us to create them for you.
- Your brand assets, or a decision to launch with a clean, neutral design and brand it later.
- A rough idea of who the first ten customers are. It shapes every scope decision.
See it applied.
The case studies show this process on real products, including what each spec left out and why. ContentVo's spec ruled out direct social publishing entirely, which removed the most fragile part of the category. ScopeCrafters' spec ruled out every CRM feature, even ones customers are likely to ask for.
Start with a spec.
Tell us what you're building. The first step is always the same: a written scope you can hold us to.
SSttaarrtt aa pprroojjeecctt