How we deliver

A clear path from idea to operation.

Six phases, each ending in something you can read, click, or run. The point of the structure is that you always know what has been decided, what is being built, and what is deliberately still open.

  1. 01

    You tell us what the job is

    A call, or just an email describing what someone on your team does over and over. You do not need a spec.

  2. 02

    We build a small version first

    Usually inside two weeks. Enough that you can click through it and tell us what we got wrong.

  3. 03

    You decide whether to carry on

    If it is not right, you have not paid for a full build. That is the point of doing it in this order.

  4. 04

    We finish it and hand it over

    Deployed on your own cloud account, with the code, the notes, and whatever monitoring it needs.

Most projects run 2 to 10 weeks depending on how many people and systems are involved.

  1. 01

    Discover

    Map the business problem, users, bottlenecks, and definition of success.

    We start with the work itself: who does it today, what they open, where it stalls, and what a good outcome looks like in numbers.

    We also map the systems already in play: spreadsheets, CRMs, accounting tools, inboxes. Whatever we build usually has to fit alongside them.

    You end up with: A written problem statement, user roles, and the measurable outcome for release one.

  2. 02

    Plan

    Define the product scope, architecture, milestones, and delivery priorities.

    We choose the smallest scope that delivers a real result, then decide the architecture, data model, and integrations that scope actually requires.

    Anything that is genuinely a later phase gets written down as a later phase rather than quietly built now.

    You end up with: A scoped plan with architecture, milestones, and an explicit list of what is out of scope.

  3. 03

    Design

    Prototype the core workflows so the product is clear before heavy development.

    We prototype the screens where the real work happens first: the queue, the editor, the approval step. Not the marketing pages around them.

    Seeing the core workflow early is the cheapest moment to change your mind about it.

    You end up with: Clickable prototypes of the primary workflows and the permission model behind them.

  4. 04

    Build

    Ship in focused iterations with visible progress and regular feedback.

    Work lands in short iterations against a running environment you can open at any time, so progress is something you check rather than something you are told about.

    Integrations, permissions, and error handling are built as part of each feature instead of being deferred to a hardening phase.

    You end up with: A working environment updated every iteration, with a demo and a written summary each time.

  5. 05

    Validate

    Test functionality, security, performance, accessibility, and real user flows.

    We test the flows your team will actually run, including the awkward ones: bad input, partial data, interrupted jobs, and the wrong person trying to act.

    Security, performance, and accessibility get checked here as pass-or-fail criteria rather than opinions.

    You end up with: Automated test coverage on core paths, plus a validation report covering security and performance.

  6. 06

    Launch & support

    Deploy, monitor, improve, and support the product as the business grows.

    We deploy to your own cloud account, set up monitoring and backups, and hand over the code with documentation your next developer can follow.

    After launch we stay available for fixes and the next round of improvements, support is an agreement, not a favour.

    You end up with: A production deployment on your infrastructure, monitoring, documentation, and a support window.

What we ask of you

  • One person who can make decisions about scope.
  • Access to whoever actually does the work today, not just the person describing it.
  • A response on demos within a few days, so iterations do not stall.
  • Honesty about constraints: budget, deadline, regulator, or an existing system we have to live with.

What we will tell you

  • If a cheaper off-the-shelf tool would solve the problem.
  • If part of the scope should be a later phase, and why.
  • If the data quality will not support the accuracy you are expecting.
  • If we are the wrong fit for the work.

Phase one

Start with discovery, not a contract.

Tell us the workflow that is slowing you down. The first conversation is about understanding it, not selling you a phase.