Process

Rigor without ritual.

Five stages carry a product from first framing to production and beyond. Each one has a goal, decisions that have to be settled, and something you can hold at the end of it.

01 Frame Goals, users, constraints
02 Shape Flows, architecture, plan
03 Build Increments you can use
04 Launch Production, store, monitoring
05 Improve Real use, then better
Delivery track

Five stages. Four points where the work stops and we decide.

The sequence is fixed. What changes is how much weight each stage carries — so we describe the process by its decisions and its artifacts, never by a fixed schedule.

Delivery Ongoing Scope agreed Plan approved Build accepted In production 01 Frame 02 Shape 03 Build 04 Launch 05 Improve What we learn returns to Shape
Fig. 01 Delivery track. Squares mark stages, diamonds mark decisions, and the dashed return path carries what we learn back into Shape. Scroll the drawing sideways to follow it.
  1. Frame

    Agree what the product must do, who it is for, and how we will know it worked.

    Decisions made here

    • The problem the product solves, and the people it solves it for.
    • What ships in the first release, and what deliberately does not.
    • The platform: web on AWS, native iPhone and iPad, or both.

    What you receive

    • A written brief with goals and success criteria.
    • A scoped feature list for the first release.
    • An honest read on approach and effort.

    Scope agreed Nothing is designed until the brief is settled and written down.

  2. Shape

    Turn the brief into something concrete enough to build. Interface and system architecture are designed together, not in sequence.

    Decisions made here

    • The core user flows, and how the interface handles every state.
    • The system: data, services, authentication, and security boundaries.
    • The delivery plan, and the order features ship in.

    What you receive

    • Interface designs and an interactive prototype of the key flows.
    • An architecture outline covering data, services, and boundaries.
    • A delivery plan with named review points.

    Plan approved Flows, architecture, and sequence are agreed before engineering starts.

  3. Build

    Engineer the product in working increments. You use real software early, and every review is a chance to correct course before it gets expensive.

    Decisions made here

    • What each increment has to prove before the next one starts.
    • How errors, empty states, and slow connections behave.
    • When content, data, and integrations connect.

    What you receive

    • A working build at every review, not a reveal at the end.
    • Automated tests alongside the features they cover.
    • A codebase clean enough to hand over at any point.

    Build accepted The product does what the brief said, and you have used it yourself.

  4. Launch

    Move the product into production deliberately. Web products are released through staged AWS deployment. Apple apps go to TestFlight first, then into App Store review — we control how well the submission is prepared, not whether Apple approves it.

    Decisions made here

    • The readiness checklist: performance, accessibility, security, recovery.
    • The release path: staged rollout, TestFlight cohort, or direct launch.
    • What is monitored from day one, and who gets alerted.

    What you receive

    • A production deployment with monitoring and alerting in place.
    • App Store submission materials, where the product is a native app.
    • Documentation for operating what was built.

    In production The product is live, observable, and owned by someone named.

  5. Improve

    Learn from real use. Feedback, product behavior, and system performance feed a queue of improvements shipped with the same rigor as the original build.

    Decisions made here

    • What the first weeks of real use say about the original assumptions.
    • Which improvements matter most: features, performance, or polish.
    • Whether ongoing work stays with us or moves to your team.

    What you receive

    • A prioritized improvement backlog grounded in real usage.
    • Regular quality, performance, and cost reviews.
    • A clean handover whenever you want one.
No fixed timelines

Same stages. Different shape.

A native app headed for App Store review, a web application on AWS, and an AWS architecture review all move through these five stages — none of them with the same weight in each. The weighting is planned at the start, and we size the process to the work.

A native iPhone and iPad app
Weight sits in Shape and Launch — platform conventions first, then App Store review preparation.
A web application on AWS
Weight sits in Build and Launch — staged deployment, monitoring, and a clean operational handover.
An AWS architecture review
Weight sits in Frame and Shape — the finding and the plan are the deliverable.
Native app Web on AWS AWS review Frame Shape Build Launch Improve
Fig. 02 The same five stages, weighted three ways. Illustrative of shape, not of duration.

Have a product in mind?

Tell us what you want to build. We reply with an honest read on scope, approach, and whether we are the right fit.