Skip to content

Process

Five phases, and you can see into all of them

Custom software goes wrong in predictable places: scope defined by the wrong people, decisions deferred until they are expensive, and a long silent stretch before a reveal. The process below is built to remove each of those.
  1. 01

    Discovery & systems audit

    Fixed scope, before any commitment to a build

    We start by understanding how the business actually runs — not how the org chart says it does. Every tool, hand-off, and workaround gets documented, because the workarounds are usually where the real requirements are hiding.

    What happens

    • Interviews with the people doing the work, not only the people commissioning it
    • Inventory of every system, integration, and manual process in scope
    • Identification of the system of record for each type of data
    • Definition of what success looks like in numbers you already track

    What you get

    • Systems map with current-state data flows
    • Prioritized problem list with estimated impact
    • Recommended architecture and phasing
    • Scoped proposal with fixed pricing per phase
  2. 02

    Architecture & design

    Before the first production commit

    We resolve the hard structural decisions on paper, where changing your mind is cheap. Data model, integration contracts, and interface design all get settled before the build starts.

    What happens

    • Data modeling and schema design
    • Integration contracts and system-of-record decisions
    • Interface design against real content, never placeholder text
    • Component-level design system aligned to the codebase

    What you get

    • Technical architecture document
    • Database schema and API contracts
    • Interactive design prototype
    • Design system and component inventory
  3. 03

    Build

    Iterative, with a working environment from week one

    Development happens in short cycles against a staging environment you can open at any time. There is no phase where you wait in the dark and hope the result matches the deck.

    What happens

    • Iterative development with a persistent staging environment
    • Review checkpoints at the end of each cycle
    • Automated type checking and test coverage on critical paths
    • Continuous deployment to staging on every change

    What you get

    • Working staging environment from the first cycle
    • Cycle-by-cycle progress notes and demos
    • Production-ready application code in your repository
    • Test coverage across business-critical logic
  4. 04

    Migration & launch

    Coordinated cutover with a documented rollback

    The riskiest part of a platform project is the day it replaces the thing people rely on. We plan the cutover in detail, migrate with reconciliation, and keep a way back.

    What happens

    • Data migration with reconciliation against source systems
    • Redirect mapping to preserve existing search rankings
    • Team training on the systems they will operate daily
    • Phased or scheduled cutover with rollback procedure

    What you get

    • Migration reconciliation report
    • Redirect map and SEO continuity checklist
    • Recorded training sessions and written runbook
    • Monitoring, alerting, and error tracking in production
  5. 05

    Operate & evolve

    Ongoing, scoped to your roadmap

    Launch is the point where the platform starts producing information. We stay on to read it — what people use, what they avoid, where the next constraint is forming — and keep building against that.

    What happens

    • Performance and Core Web Vitals monitoring
    • Behavioral review against the success metrics set in discovery
    • Security patching and dependency maintenance
    • Roadmap planning for the next phase of capability

    What you get

    • Regular performance and usage reporting
    • Maintained dependencies and security posture
    • Prioritized enhancement backlog
    • Ongoing engineering capacity on a retainer or block basis

Operating principles

The commitments behind the phases

A process diagram is easy to draw. These are the parts we will hold to when a project gets difficult.

Discovery is a deliverable, not a sales call

You leave discovery with a systems map, an architecture recommendation, and a fixed-price proposal — useful artifacts even if you build with someone else.

Staging is open from week one

You can look at the real thing at any point. No black-box phases, no big reveal where the first honest feedback arrives too late to act on.

The stack has to survive us

Typed, documented, conventional code in your repository. If you hire an internal team next year, they should be able to read it without an archaeology project.

We recommend against building when that is the answer

Sometimes a well-configured off-the-shelf tool wins. Saying so early costs us a project and earns a reference — that trade has worked out consistently.

Phase one

Start with discovery

Buy the first phase on its own if you want. You leave with a systems map, an architecture recommendation, and a fixed-price plan — regardless of who ends up building it.