How we build
How we build software that lasts
Full stack, from the database to the screen: a written scope before any code, working software you can click through early, tests with every change, and a handover you own.
- 1
Discovery
- 2
Specification
- 3
Build
- 4
Review
- 5
Handover
Methodology
How the work is planned
Plans that survive contact with the real project: written down, cut small, and revised in the open.
Scope before code
Nothing is built until what it will do is written down and agreed — including what it will not do.
Short cycles, working software
Work is cut into pieces that each end with something you can open and use, not a status report.
Decisions recorded where you can find them
What was agreed, and why, is written down — so nobody relies on memory six months later.
Change is planned for
Priorities can be reordered between cycles. The scope says what moves, so a change is a decision, not a surprise.
Before the first line of code
Every project starts with a document you can correct, not with a quote.
- The problem, in your words
- What the system will do
- What it will not do
- An estimate built on that scope
How a project runs
Five stages. Each one ends with something you receive and can check, not something we report.
Discovery
A written statement of the problem, in your words, that you can correct before anything is built.
Specification
Scope, priorities, and an explicit list of what is not included. This is what the estimate is built on.
Build
Working software at the end of each cycle — not a status report.
Review
You use it against real work and say what is wrong, while changing it is still cheap.
Handover
A running system, the source code, and a document that explains how it works.
What it is built with
The whole stack in one place, grouped by what each part does — what we build with, and what you can hire us for.
Backend
Frontend
Delivery
Stacks are chosen per project, not per fashion.
How a change is verified
Every system ships with automated tests, so a fix today does not quietly break something that worked yesterday.
Written with the code
A feature arrives with the tests that prove it works — not added later, if there is time.
Run before every release
The whole suite runs before anything reaches production. A failing test stops the release.
A bug becomes a test
When something breaks, the fix comes with a test that fails without it, so the same bug cannot come back unnoticed.
Written with Pest
AI in the work
AI that works inside your systems.
AI added to what you already run, answers from your own documents, agents that do one job — and more, all on one page.
See what you could get with AIAI in your existing system
Add AI to the software you already run — a new answer, a new button, a new screen — without replacing it.
Knowledge base over your documents
Ask your manuals, policies and contracts a question, and get the answer with the passage it came from.
An agent for one job
An agent that does one job on your systems — reviewing, following up, preparing a report — and hands the decision to a person.
Want to know how your system would be built?
The stack above is what we build with, and the process above is how the work actually runs. If you want to see what that looks like applied to your situation, the draft takes a few minutes and gives you something you can read.