A guide, in three parts
What working with us actually looks like.
Most people have only bought software the old way: a committee writes a specification, a tender goes out, a vendor appears, and something arrives many months later. We work differently. This guide covers what you decide before we start, what we ask of you during the build, and what happens after it ships.
Each part is its own page and takes three or four minutes.
Fig. 1 — Same problem, two calendars
- Old route: specification, tender, approval, build, user acceptance testing — roughly six months before a real user touches the software.
- Our route: a working system is deployed and used in week one, an MVP by week three, and the application is live in production at about three months.
Part one
Before you engage us
What changed in software procurement, how to pick the first problem, whether it needs AI at all, and how to write the brief.
6 sections →
Part two
While we are building
What each of the three weeks looks like, who tests and how, how to report a problem, and what we still do slowly.
5 sections →
Part three
After the build
The three exits, what hosting covers, what you get if you take it in-house, the glossary and the questions procurement asks.
9 sections →