Process
Four phases. No surprises.
I borrowed this from how regulated banks structure delivery, then stripped the parts that don’t belong in a startup. You get the rigour, not the bureaucracy. Every phase has named deliverables, named owners, and a fixed end date.
Why this exists
Most consulting engagements fail at the brief
The pattern I see most often is this. The founder describes the problem in 20 minutes, the agency writes a 40-page proposal, both parties sign, and three months later they’re arguing about scope. The discovery never happened, it just got compressed into a sales conversation.
I separate discovery from build. You pay for a week of my time to actually understand what we’re building, then we decide together whether to continue. About a third of the teams I scope decide not to hire me, and that’s a good outcome. They saved a hundred grand on a project that wouldn’t have worked.
The remaining two-thirds get an engagement that runs on rails because the brief is real, the architecture is documented, and the trade-offs are explicit. That’s the whole game.
Phases
From idea to production, end to end
Total elapsed time is typically 8 to 16 weeks for a meaningful build, plus optional ongoing work.
Discovery
Week 1, paid
I read your code, talk to your team, and write a brief that says what we’re building, what we’re explicitly not building, and why.
What I’m doing
- 30-minute calls with every key stakeholder
- Read-only access to your repo, infra, ticket history
- User and ops journey mapping where it matters
- Failure-mode interview, what hurts now, what scares you
- Success metrics defined in numbers, not adjectives
What you walk away with
- Discovery brief, 4 to 8 pages
- Technical risk register
- Scope statement, with the things we’re cutting
- Phase 2 estimate, fixed if scope holds
Architecture
1 to 2 weeks
Diagrams, ADRs, schemas, infra plan. The doc survives me leaving the project. No black boxes.
What I’m doing
- System diagram on Excalidraw, then Mermaid in the repo
- Architecture Decision Records for every major choice
- Database schema and migration plan
- API contract review with your engineers
- Threat model, secrets, audit trail, PII strategy
What you walk away with
- Architecture document committed to your repo
- ADRs for every irreversible call
- Database schema and seed data
- OpenAPI specs for new endpoints
Implementation
4 to 12 weeks
Weekly demos on Fridays. Production deploys from week two. You see the thing running, not slides about the thing.
What I’m doing
- Daily commits to a branch you can read
- Friday demo, 30 minutes, recorded
- Pull requests reviewed by your engineers when possible
- Test pyramid, integration heavy on money flows
- Observability built in, traces and dashboards from day one
What you walk away with
- Working production deploys, weekly
- Integration tests, run in CI on every PR
- Dashboards in your monitoring tool of choice
- Updated ADRs as decisions change
Launch
Final 1 to 2 weeks
Production cutover with rollback rehearsed, runbooks written, and your engineers shadowing the on-call rotation.
What I’m doing
- Load testing against realistic traffic shapes
- Failure injection, kill the database, kill the queue
- Runbook walkthrough with the team that’ll run it
- Phased rollout, feature flag or traffic split
- Post-launch retro, written, in the repo
What you walk away with
- Production deploy with rollback plan
- Runbook for the top 10 incident types
- Recorded handover walkthrough
- 30 days of bug-fix support included
After
Optional
Most teams own it from here. A few keep me on a fractional retainer for ongoing architecture. Either is fine.
What I’m doing
- Quarterly architecture review, half-day
- Hiring help, technical interviews for senior roles
- Incident review on call, when the bad thing happens
- Roadmap planning, twice a year
What you walk away with
- Written quarterly review
- Updated roadmap aligned to business goals
- Interview scorecards for hires
Operating principles
Four rules I won’t bend on
These aren’t aspirations. They’re how every engagement actually runs.
Transparency
Every decision lives in the repo as a Markdown ADR. You can read why we chose Postgres over DynamoDB six months from now without my help.
Boring tech
Postgres, Spring Boot, Next.js, AWS. The novelty lives in the architecture, not the dependency tree. Your maintenance future-self will thank me.
Ship weekly
Friday demos from week one. If we go four weeks without something running in production, we’re working on the wrong thing.
Document the ugly bits
The interesting part of any system is what fails. I write the failure modes down explicitly so the next engineer doesn’t learn them at 3am.
Common questions
What teams ask before they sign
If yours isn’t here, just email and ask.
Process is just the rails. Want to talk about your project?
Tell me what you’re building. I’ll tell you whether discovery is the right next step, and if not, what is.
Or read the pricing page first to see if the numbers fit.