Skip to content
Start a projecthello@promptabide.com
How we work

Five steps. No surprises in step four.

Every step below produces something you can read, click or run. If a phase ends and you have nothing concrete in your hands, the phase wasn't finished.

  1. Step 01

    Discover

    We map what you actually need — users, scale, constraints — before touching a keyboard.

    Most expensive mistakes are made in the first week, by building the thing that was asked for instead of the thing that was needed. We start by pulling apart the problem: who uses this, how many of them, what happens when it breaks, and what is genuinely out of scope.

    You end up with

    Scope documentSuccess criteriaRisk list
  2. Step 02

    Architect

    System design first: monolith or microservices, data model, cloud footprint.

    The unglamorous part that avoids the expensive rewrite. We decide the service boundaries, the data model and the cloud footprint up front, and we write it down so the decision is reviewable rather than folklore.

    You end up with

    Architecture diagramData modelInfrastructure plan
  3. Step 03

    Build

    Sprints with visible progress. Staging environments from day one, not week six.

    You get a working URL early and it keeps working. Each sprint ends with something you can click, on an environment that mirrors production, so feedback arrives while it's still cheap to act on.

    You end up with

    Staging environmentSprint demosReviewed pull requests
  4. Step 04

    Ship

    Containerised deploys and zero-downtime releases as the default, not the upsell.

    Release day should be uneventful. Deploys are containerised and automated, rollbacks are a single command, and the pipeline that ships to production is the same one that has been shipping to staging for weeks.

    You end up with

    CI/CD pipelineRollback pathLaunch checklist
  5. Step 05

    Support

    Monitoring and on-call from a team that already knows your system.

    The people who architected it are the people who answer when an alert fires. Monitoring, logs and alerting are in place before launch, and you get the runbook whether or not you keep us on.

    You end up with

    Monitoring & alertsRunbookHandover or retainer
What this rules out

The failure modes we're deliberately designing against.

Avoided

The week-six reveal

You see it on a staging URL in week one, not at a demo after the budget is spent.

Avoided

The architecture nobody wrote down

Decisions live in a document, not in one engineer's head. Including the ones we'd make differently now.

Avoided

The scary deploy

The pipeline that ships to production has already shipped to staging a hundred times.

Avoided

The hostage handover

You get the runbook, the infrastructure code and the credentials. Staying with us should be a choice.

step 01

Ready to start at discover?

The first conversation is the discovery conversation. Tell us what you're building and we'll start mapping it.