
Our process
Build fast. Keep the capability.
A working app is the beginning, not the prize. Here is the whole route — from a short form, through a private proof of concept and a proper consultation, to built, tested software that handles familiar work, uses AI deliberately and leaves room for your next improvement.
Your idea stays yours. We just do the part that makes it work.
Powerful software. Lasting benefit.
Six stages. One continuous line.
Nothing here is a phase that quietly disappears when the invoice arrives. Each stage has something to show you, and a decision attached to it. You can stop at any of them.
- 01 Describe
- 02 Concept
- 03 Consult
- 04 Build
- 05 Test
- 06 Live
Who owns what
Your idea stays yours.
The idea came from someone who knows the job. We are the means of making it work — and that arrangement holds from the first sentence you type, not the point at which you pay for it.
The idea
It came from you, in your words. The brief it becomes is yours, and nothing in the way we work is designed to make it hard to walk away with.
The rules
The thresholds, checks and written logic come out of your experience and are documented as we go, so the reasoning travels with the software instead of staying with us.
The finished thing
The data, the application and the address it runs on are yours to keep, move or copy — under our management, in a cloud account you own, or on equipment in your own building.
What we do take is the general lesson: what we learn about building a scheduler or a stock board properly carries into the next build. Your customer data, your rules and your branding do not — they are not pooled, not reused elsewhere, and not shown to anyone unless you tick the box saying it is fine to feature it. If you would rather we learned nothing at all, say so and we will keep it that way.
- 01
Form entry
Tell us the problem, in your words
It starts with a short form on the Start a project page. One question: what is going wrong, or what do you wish you had? A paragraph of plain English is enough. No specification, no jargon, no IT project plan.
- You can attach up to three files — a sample spreadsheet, a form, a photo of a whiteboard — as long as the data in them is sample or fictional.
- Not sure of the shape? Use an example, or browse the gallery of concepts we have already built for other businesses.
- Nothing is sent until you click Create my concept. Before it runs we ask for your email address, so the concept can be saved and handed back to you. It is used for that and nothing else.
What you get: A brief we can work from, and a private place it is stored.
Yours: the words you wrote, and the brief they became
- 02
Proof of concept
A working concept before the conversation
From your brief we generate a one-page working concept — screens, fields and behaviour shaped around what you described. It runs in an isolated sandbox that cannot reach your systems or anything else on the internet. It is a shape to react to, not a finished product.
- You get a private link to your concept, and can download it if you would rather look at it somewhere else.
- Only you and we can see it, unless you tick the box saying it is fine to feature it.
- If it misses the mark, say so plainly. The next version starts from your correction, not from scratch.
What you get: Something to poke at and argue with, rather than something to imagine.
Yours: the concept, its private link and the download
- 03
Consultation
Where the real expertise goes in
This is the stage that decides whether a build is worth doing at all. We go through the concept line by line and find out what is actually broken: which checks happen the same way every time, which are genuine judgement calls, and which decisions need a named person's signature.
- Rules, thresholds and calculations get written down properly, with the evidence behind them.
- Compliance, retention and data-location requirements are established here, because they shape the design — not the invoice at the end.
- We agree what success looks like and which running costs to measure, AI spend included.
- If the problem turns out to be smaller than the software, we tell you at this point.
What you get: An agreed scope, a written set of rules, and a price before anything is built.
Yours: the written rules, the thresholds and the reasons behind them
- 04
Build
Proven software first. AI at the edges.
Known work runs as ordinary tested software: calculations, checks, thresholds, workflows that behave the same way every time. AI is used where the rules run out — unfamiliar documents, ambiguous input, and to build the application itself faster. AI used to develop the app stays separate from the AI calls needed while it runs.
- It goes up on your own private web address, so the people doing the work can see it as it grows.
- Access roles, audit records and retention are part of the build from the start, not added when someone finally asks.
- Data, rules and structure are documented as we go, so the application can leave if you ever want it to.
What you get: A working application on your own address, with the exit already written down.
Yours: the application and the address it runs on
- 05
Testing & refining
Try to break it, using your examples
We test against real cases, the awkward ones included. Where AI resolves an unfamiliar situation, we capture what it did and put it in front of a human for review. Only patterns that prove reliable across the relevant examples become permanent tested rules. Nothing learns by itself.
- Repeatable checks become reliable software. Genuinely ambiguous cases stay with AI and a person.
- Changes are versioned and reversible, so you can see what the system did on a given day.
- Where the evidence has not changed and an earlier result still stands, we reuse it instead of paying AI to work it out again.
What you get: Software that behaves on Tuesday the way it did in testing.
Yours: the test cases, the corrections and the record of every change
- 06
Live & improving
The concept becomes the product
Your proof of concept becomes the finished application in the same place, on the same address — no migration, no rebuild for the sake of it. From there we keep looking for AI calls that are no longer needed and remove them, checking that quality holds and that total cost actually improves.
- Budget no longer spent repeating solved work can fund your next feature instead.
- Support, security fixes and monitoring stay part of the service.
- Portability stays open: run it under our management, in a cloud account you own, or on equipment in your own building.
What you get: Capability that gets stronger as it gets cheaper to run — and that you can take home.
Yours: the data, the rules and the running application
See it happen
Fifty seconds, start to finish: a fictional workshop owner fills in the form, watches the concept take shape, and asks for a meeting. The names are invented; the screens are the real ones.
The mechanism underneath
Yesterday's exception. Tomorrow's tested rule.
This is how a system gets cheaper to run as it gets better, without anyone hoping the model behaves. It is also why we can tell you what the software did, and why.
01
AI meets something new
An unfamiliar document format, a supplier's odd invoice, a case the rules do not cover. AI resolves it once and we record exactly what it did.
02
A human reviews it
The answer is checked against the evidence and the person accountable for that area signs it off. Nothing becomes a rule quietly, and nothing learns without supervision.
03
It becomes a tested rule, or stays an exception
If it proves reliable across the relevant examples, it is written as a permanent, tested rule and the AI call for that case stops. If it does not, it stays an exception handled by AI and a person — not an automatic software change.
Where the evidence has not changed and a previous result is still valid, we reuse it. Changed information, or a changed rule, triggers the checks that need reassessing. We measure total cost — including review, testing and maintenance — rather than promise you a saving before we have evidence for it.
What this asks of you
Less than you might expect, and nothing in the shape of a traditional software project. The honest version, including the times we would tell you not to bother.
What we need from you
- One person who owns the process, who can say yes and no.
- Three or four real examples, including the ones that cause trouble.
- A decision-maker for the cases that need judgement.
- A short check-in while it is being built, so we do not drift.
What you do not need ready
- A written specification. Describe the problem; the specification is our job.
- An IT project plan, or a committee.
- AI accounts for your staff — this is not what we are selling.
- A cloud-or-in-house decision before we have worked out what the work needs.
When we would say do not build it
- A rule and a spreadsheet will genuinely do the job.
- The underlying data cannot be trusted, so the software would only automate the mistake.
- Nobody will own the thing once it is handed over.
- We would rather say that at the start than bill you for a rebuild later.
People retain responsibility
Rules should show the evidence and logic behind a result. AI-assisted findings are clearly distinguished, and consequential decisions stay with the responsible person. Local or cloud processing is chosen to suit the work, security needs and cost — not by default.
Built to be moved, not kept
Portability is agreed at the start rather than negotiated at the end: exportable data, a documented structure, written and tested rules, and an AI layer treated as a replaceable component. The application can run under our management, in a cloud account you own, or on hardware in your own building.
Where a suitable language model can meet the task, the AI work can also run on equipment you control, reducing reliance on external token services. That is an option to assess, not a promise that every application should move locally.
Data control can support compliance requirements; it does not make compliance automatic. Access controls, audit records, retention, model quality and human oversight still need validation. Hardware, energy, maintenance and support belong in the cost comparison too.
Shared foundation, bespoke finish
Tested core features and applicable security improvements can be reused across similar businesses. Your specific rules and branding remain yours; customer data is not pooled to make that possible.
