How we build software in four steps

The work that a standard package does not fit often sits in Excel, in mailboxes and in the heads of a few people. Anyone who wants software for it has to hand that knowledge to a builder first. So we start with what your people know. The short overview is on our approach. Here we walk through the four steps.

Working sessions capture how the work goes

We sit down with the people who do the work. How does it go in practice, which exceptions are there, who decides what, where does it pinch? Every session is recorded and transcribed. Everything we build afterwards traces back to what was said in those sessions.

An ontology captures concepts and rules

From the sessions we make one description of your concepts and rules (an ontology). A small example: an installation has parts, and a part has a maintenance plan. People maintain the ontology. The agents only flag where new evidence differs from what is already known, and people approve every change.

A blueprint and agents build

Next to your own work we add a blueprint: a working design from earlier projects in the sector, so we do not start from zero. AI agents build, product engineers steer. What we learn about a design in one project we can reuse. Your data, drawings, customers and prices stay yours.

Tests first, then the code

We start with a specification, written from the working sessions and real examples. You review it. Then come the tests (unit, integration, regression and end-to-end), which set the expected result before any code exists. After that the agents write code until the tests pass, and an engineer reviews every change before it goes live. The usual path starts building early and loses time in implementation, because requirements change along the way. We put the work into design and tests up front, so the building stays short.

We deliver the tests, runbooks and documentation with it, so you can always read back what was agreed and whether the software still does it.