A guide, in five 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, what happens after it ships, and how it all reads to a public-sector buyer.

Each part is its own page and takes three or four minutes.

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 →

Part four

Public-sector procurement

Which sourcing tier a piece of work sits in, what counts as one requirement, and what makes hosting severable from a build.

8 sections →

Part five

Hosting and handover

What hosting actually covers, what we operate on your behalf, what a code download does not contain, where the data sits, and how PDPA responsibility splits.

8 sections →