How we work

Six stages. Each one ends with evidence.

A rebuild should never ask you to take the result on trust. Every stage below produces something you can inspect, run or reconcile before you approve the next one. You can stop after any stage and keep everything delivered so far.

  1. Assess

    We read the code, the database schema and the data, interview the people who use and support the system, and find out which features are actually used. You get a written assessment: what the system does, what is risky, what we would keep, drop or improve, the migration approach and a fixed price for the rebuild.

    You get a written assessment and a fixed-price proposalTypical length 1 to 2 weeks
  2. Pilot

    We rebuild one meaningful slice of the system end to end, with its tests, running on your data in a test environment. It shows you the quality of the work, the pace and how we communicate, before you commit to the whole rebuild.

    You get a working slice, its tests and an updated planTypical length 3 to 4 weeks
  3. Rebuild with tests

    The full rebuild, in short cycles. AI writes much of the code; an engineer directs each change, reviews it and answers for it. Unit tests and browser tests are written alongside the code and must pass before any change moves on. You see progress in a test environment you can use at any time.

    You get the new system, its source code and the full test suiteTypical length 6 to 12 weeks
  4. Parallel run

    Old and new systems run side by side on real work. Your people compare results, and an independent validation scores the new system against written test cases. Problems are fixed and re-checked, each with a regression test so it cannot quietly return.

    You get a validation report with every finding and how it was resolved
  5. Rehearse the migration

    We load a full copy of your production data into the new system, reconcile every count (records, files, balances, whatever matters to you) and time it. We repeat the rehearsal until it runs cleanly and the timing fits your cut-over window.

    You get a reconciliation report and a timed, written cut-over runbook
  6. Cut over

    A planned switchover in an agreed window, following the rehearsed runbook, with a tested rollback. Afterwards we stay close while your people settle in and fix anything found during the support period.

    You get the live system, handover documentation and post-launch supportSupport period 90 days, included

What stays true throughout

You own everything

The source code, tests and documentation become yours as each invoice is paid, and your data is always yours. They live in repositories and accounts you control. We keep only our general tools and know-how.

Fixed prices

Each stage is quoted as a fixed price before it starts. If the scope changes, we agree the change in writing first.

No surprises at go-live

The cut-over is the stage you have already rehearsed. Nothing about go-live day should be the first time it has happened.

Start with the assessment

It is a fixed fee, and the report is yours to use whoever you choose for the rebuild.