How We Work

Most software problems are not coding problems. They are “we built the wrong thing” problems. This is how we avoid that.

1. Requirements first

We start by working out what to build and, just as important, what not to build. On a recent rebuild we audited more than 200 existing features against real production access logs before writing a line of new code, so the scope was set by evidence, not opinion.

2. Specs and acceptance criteria

Each requirement becomes a user story with explicit acceptance criteria: the conditions that have to be true for it to count as done. That is the contract the build and the tests are held to.

3. Build, AI-augmented

AI lets a small senior team produce agency-scale output. It is a multiplier, not the driver: a human owns every decision. Test-first is enforced by tooling, not willpower. Implementation is blocked until a failing test exists.

4. We prove the tests test something

We run our own test-quality tool, Kiso. It reads the user stories and acceptance criteria, matches them against the test suite, and reports which requirements have a real verifying test and which are gaps. It reads the code, it never edits it. Coverage percentage is vanity; a verifying test for every requirement is the point.

5. Ship and hand over

Every project ships to staging and production. You own the code and the infrastructure from day one. No lock-in.

6. Maintain and evolve

Most of a product’s life happens after launch. We keep systems running, secure, and billing-accurate, including a platform over fifteen years old, and modernise without a risky rewrite.

Our vision

AI has made building software fast and cheap. That is exactly why discipline matters more now, not less. The winners will not be whoever ships fastest, but whoever ships fast and keeps it correct, secure, and alive for years. We pair AI’s speed with a Japanese engineering ethic, kaizen, monozukuri, shokunin, so what we build is something you can run a business on, not a demo that rots.