Skip to content
How we work

The whole process, published

Working software on staging inside the first two weeks, then a new increment every two weeks until launch. Almost nobody in this industry publishes the rest of it. We do, in detail, because the fastest way to earn a serious buyer's confidence is to remove the uncertainty they're actually worried about: what happens after they sign.

  1. 0030 minutes

    First call

    Establish whether there is a real fit, quickly, in both directions.

    Decision gate

    You decide whether to proceed to a scoped discovery. No proposal ambush, no pressure.

    What happens

    • You describe the problem; we ask about the process behind it.
    • We give an initial view on approach, rough range and timeline.
    • We say plainly if we're the wrong firm for it.

    You receive

    • A written summary of what we understood
    • An indicative budget range and timeline
    • A referral elsewhere if we aren't the right fit

    We need from you

    • Someone who understands the current process
    • A sense of budget range and deadline pressure
  2. 011–3 weeks · fixed price

    Discovery

    Convert an ambiguous problem into a scope, an architecture and a number you can rely on.

    Decision gate

    You own the discovery output whether or not you continue with us. It's specific enough for another vendor to quote from, and that's deliberate.

    What happens

    • Interviews with the people who actually do the work today
    • Review of existing systems, data and integrations
    • Mapping the current workflow and locating the real constraint
    • Technical approach and architecture decisions, with alternatives
    • Breakdown into releases, each independently valuable
    • Risk register with mitigation for each item

    You receive

    • Scope document in plain language, with explicit exclusions
    • Architecture and technology decisions with reasoning
    • Release plan with estimates per release
    • Fixed price or a rate-and-cap structure for the build
    • Risk register

    We need from you

    • Access to the people who run the process, roughly 4–6 hours total
    • Read access to relevant systems and data
    • A decision-maker who can resolve conflicting requirements
  3. 02Weeks 1–2 of the build

    Foundation

    Stand up everything needed to ship safely, before feature work starts.

    Decision gate

    Infrastructure is real and observable before there is anything to observe.

    What happens

    • Repositories, environments and CI/CD in your accounts
    • Staging environment reachable by your team from week one
    • Authentication, permissions and the core data model
    • Monitoring, error tracking and automated backups
    • Agreement on definition of done and review standards

    You receive

    • A staging URL you can open
    • Automated deployment pipeline
    • Monitoring and alerting configured
    • Verified backups, tested by performing an actual restore

    We need from you

    • Cloud and repository access, or approval for us to create them
    • A named point of contact for weekly review
  4. 03Shippable increment every 2 weeks · typically 6–16 weeks total

    Build

    Ship working software continuously, with no surprises about status.

    Decision gate

    Each release is deployable. If you needed to stop the engagement mid-project, you'd have working software rather than a half-built system.

    What happens

    • Two-week increments, each ending in something demonstrable
    • Weekly 30-minute demo on staging: software, not slides
    • Code review on every change, internally before it reaches you
    • Automated tests on the paths where failure costs you money
    • A written change order for anything outside the agreed scope

    You receive

    • Working software on staging, updated continuously
    • Weekly written progress note: shipped, next, blocked
    • Current burn against budget every week
    • Change orders priced before work begins

    We need from you

    • 30 minutes a week for the demo
    • Timely answers on decisions we flag as blocking
    • Feedback while a release is in progress rather than after
  5. 041–2 weeks

    Launch

    Go live without drama, with a tested way back.

    Decision gate

    The system is live, your team knows how to operate it, and rollback has been proven to work.

    What happens

    • Load testing against your expected peak, not average
    • Security review and dependency audit
    • Data migration rehearsed against a production-scale copy
    • Rollback plan written and tested
    • Training sessions with your team, recorded
    • Elevated monitoring for the first two weeks

    You receive

    • Production deployment
    • Runbooks for the operations your team will perform
    • Recorded training and written documentation
    • Post-launch support window with direct escalation

    We need from you

    • An agreed launch window
    • Staff availability for training
    • A named internal owner for the system going forward
  6. 05Ongoing · monthly

    Run

    Keep it healthy and keep improving it, or hand it over cleanly.

    Decision gate

    There is no lock-in. If you want to bring it in-house, we document, train and hand over, and we'll help you hire for it.

    What happens

    • Monitoring, patching and dependency updates
    • Defined response times by severity
    • Monthly review of usage, cost and performance
    • Continued development against your roadmap
    • Or: complete handover to your in-house team

    You receive

    • Monthly health and cost report
    • Security patches applied on a schedule
    • A named engineer who knows your system

    We need from you

    • A monthly conversation about priorities
How we operate

Six things you can hold us to, in writing

Not values on a wall. Each of these is a specific, checkable behaviour that goes in the contract, and the last one costs us work regularly.

  • 01

    You always know the number

    Budget consumed and budget remaining, in writing, every week. Nobody should learn about an overrun when the invoice arrives.

  • 02

    Bad news travels immediately

    If an estimate was wrong or an approach isn't working, you hear it that week. Problems surfaced early are cheap; problems surfaced late are the reason software projects fail.

  • 03

    You talk to the engineers

    No account manager relaying technical questions. The people writing your software are in the room and answer for their own work.

  • 04

    Everything lives in your accounts

    Your repositories, your cloud, your domains, your credentials. We operate inside your perimeter, and revoking our access is a switch you control.

  • 05

    We build to be replaceable

    Standard conventions, documented decisions, no proprietary framework of ours in the middle of your system. A vendor who is difficult to replace has the wrong incentives.

  • 06

    We say no

    To work we're not right for, to features that won't move your metric, and to technology chosen for novelty. A vendor who never disagrees with you isn't providing expertise.

What we don't do

Things you won't get from us

Stated plainly, because mismatched expectations are the most common reason engagements go badly.

  • Fixed-price quotes on vague requirements. We'll quote after discovery, not before.
  • A team assembled after you sign. You meet and approve the actual engineers first.
  • Silent scope absorption. Changes get written down and priced, every time.
  • Timeline estimates we know are optimistic to win the work.
  • Lock-in through undocumented, unconventional code that only we can maintain.
  • Agreement with everything you propose. You're hiring judgement, not compliance.

Start at step zero

A 30-minute call with an engineer. You'll leave with a written summary of what we understood, an indicative range, and an honest answer on fit.