De-risk your software investment before development begins.

We use AI to design software before AI is used to write the code. Working alongside IT and product teams, we take each initiative from problem definition to a prototype that behaves like the final product.

Key outcomes

An unambiguous specification, backed by a user-validated prototype that serves as the binding reference.

Whether a customer product or an internal system, software exists to solve a business problem

Define the problem

Identify who experiences it, at what point in their work and what it costs today, establishing a baseline against which every solution can be measured.

Select the solution

Among the available options, select the one that solves the problem with proportionate effort, and decide with equal rigour what is out of scope.

Specify the software

Translate the solution into rules, roles, screens and data, defined with enough precision to be built without reinterpretation.

Traditional approach

Traditional software design tends to be generic, approximate and incomplete

Generic

Project documents describe the problem and solution at a high level, and stakeholders sign off on text that leaves rules, exceptions and permissions undefined.

Approximate

In user-centred design, screens are drawn in Figma, but a design board remains an approximation of the software, without real data, rules or states.

Incomplete

A working prototype is slow and costly to build, so user testing is limited to mockup flows and gaps only surface at acceptance testing, as change requests.

We partner with IT and product teams to de-risk software before development

From users user-centred design

We begin with a clear definition of the problem, as experienced by the future users of the software
We map how it is solved today and identify the gaps to close
We work alongside the project team and transfer our methodology to them

To prototype working, with real data and role-based access

We deliver a complete application with realistic data and access for each role
We test it with real users and capture all feedback
We refine the specification and produce complete documentation

We use AI to design the software before AI is used to write the code

People

Capture the problem with stakeholders and map how it is solved today
Decide scope, priorities and trade-offs, feature by feature
Conduct testing with real users and approve every document

AI

Facilitates the discussion on each feature and sets out the options and their implications
Drafts PRDs and user stories and builds the application with realistic data
Derives shared rules and keeps documents and prototype aligned through every change

Our four-phase approach, from business need to prototype

01
Discovery
What to build, what to exclude and in what sequence
Client involvementKey stakeholders, in a kickoff session
02
Requirements and domain
One PRD per feature with its user stories, while shared rules form the domain model
Client involvementEach feature owner, one hour per feature
03
Screens
Screen inventory, navigation and data contract
Client involvementThe project team, in the inventory review
04
Prototype
Navigable application with test data
Client involvementEnd users, in a testing session

Our approach in detail

Phase 01 · Discovery

We define what to build, and what not to

We start from the problem, the intended users and existing assets, such as the process map, documentation and systems in use.
We identify the features to build, each delivering value to a defined user, independently testable and documented in its own PRD.
We establish an architecture decision record (ADR) that captures every decision and its rationale, starting with excluded features, so that no decision is reopened.
We sequence features by their dependencies, to determine what is built first and what can proceed in parallel.

Phase 02 · Requirements and domain

The domain model takes shape as PRDs are written

For each feature, AI facilitates a structured conversation with the feature owner, one question at a time.
We formalise decisions in the PRD and derive user stories with testable acceptance criteria.
We consolidate rules that recur across features, such as roles, permissions and states, in the domain model so they apply consistently throughout.
AI verifies that every new PRD complies with the domain model, keeping the software consistent as it scales.

Phase 03 · Screens

We specify the screens before designing them

We derive the required screens from the user stories, each designed around its user and the task it supports.
For each screen we specify content, actions and permissions, including empty and error states, so no behaviour is left open to interpretation.
We derive navigation from the features and document what is excluded, so the menu structure holds across releases.
We define the data structure of each screen once, so design and development work from the same contract.

Phase 04 · Prototype

We build a prototype that behaves like the final software

We build a complete web application with a working back end that stores data, enforces rules and manages access as the production software will.
We prepare multiple test data sets, from first access to full operation, so the prototype behaves as it would in production.
We set up access for each role, so permissions and user journeys can be verified in a few clicks.
Users test the prototype on real cases, and every finding is fed back into the relevant PRD or user story.

Iterations

Documentation and prototype remain aligned at all times

The prototype evolves iteratively, one feature at a time, with documentation and software realigned at every cycle.
Every change to the documentation is reflected in the prototype, so it always represents the latest decision.
Test findings are incorporated into the documentation, so the specification remains the single source of truth.
Automated checks verify consistency between documentation and prototype, so discrepancies surface before development.

Key deliverables and benefits

Deliverable

An unambiguous specification

We provide the development team with everything it needs to build the software without interpretation.

We document domain, PRDs, user stories, screens and data, each at the appropriate level, so every rule has a single location and a single definition.
We record every decision with its rationale and link it to the requirements and screens it governs, making the impact of any change transparent.
We include the user-validated prototype as the binding reference for behaviour and interface.

Benefit

Fewer change requests, through earlier decisions

We reduce change requests by resolving before development the issues that typically surface at acceptance testing.

PRDs settle the scope, exceptions and edge cases that traditional analysis leaves open.
Users validate, on working software, the journeys a mockup cannot test.
Acceptance criteria define when a feature is complete, so development and testing measure against the same standard.