How to build software that fits your business instead of fighting it.
An opinionated framework for building software around your actual operating process: map it, decide what is worth encoding, and build a system you own and can change in hours. Written so you can run it yourself.
Read the frameworkRoughly a thirty minute read. The same five stages and the same discipline we use on client work. Nothing is held back.
Written for the person who feels it first.
You run technology for a company between 50 and 500 people. Three to five processes hold the business together, and each one lives in a different system that was never designed for how you actually work. A change you could describe in one sentence takes weeks to ship. Your data is scattered across tools that do not talk to each other. The software that was supposed to be an enabler has quietly become a limiter, and you are the one who feels it first.
You have probably already paid for SaaS that did not fit, and for consultants who could not fix it. This page is not a pitch. It is the method we would hand you if you wanted to solve this yourself.
Software should be built around your business process, not the other way around. When the tool starts dictating how you work, the tool is the problem.
The process is the asset. The software is downstream.
Most custom software fails for the same reason most SaaS fails: it encodes a process nobody mapped. Requirements get written before anyone understands how the work really happens, so the software calcifies a misunderstanding. Then the business changes, the software does not, and you are back where you started.
We start from the opposite assumption. The thing worth getting right is the model of how your company actually operates. Once that model is clear, the software is a projection of it, and a projection is cheap to change. The model is the intellectual property. It belongs to you, not to a vendor, and not to whoever holds the source code.
This is what we mean by Process Native Software: software shaped by the real process, scoped to the highest-leverage parts of it, and owned by the company that runs on it. It is not for every case. In most situations, SaaS is still the right answer. This framework is for the cases where understanding the real process shows that bespoke software would create leverage you cannot buy off the shelf.
Five stages, one graduation path.
The framework moves from "this hurts" to a system the company runs on. Each stage answers one question and is allowed to end the engagement honestly. If the answer at any stage is "do not build," that is a real outcome, not a failure. You can run the whole sequence yourself, or stop at the stage that answers your question.
Problem Discovery
Is this problem worth solving with software at all?
Process Mapping
Do we actually understand the process and the domain?
Design
Did we understand the business, and what will it feel like to use?
Engineering
Can we turn the model into working, owned software, fast?
Expansion
Which process is worth doing next?
The stages are sequential but the framework is not waterfall. Design and engineering overlap; mapping keeps correcting itself as design and code expose what the room missed. What stays fixed is the order of the questions. You do not get to "what should it look like" before "we understand this," and you do not get to "build it" before "is it worth building."
Find out whether the problem is worth solving.
Discovery is a qualification stage, not a sales stage. The job is to decide whether the pain is real, expensive, and specific to your process, or whether a tool you can buy would solve it just as well. Most ideas should die here, and that is the point. Killing a weak case early is cheaper than discovering it after you have built something.
- A process that is genuinely yours, that generic software does not respect.
- A change loop measured in weeks or months that should be measured in hours.
- Cost you can name: time, quality that drops as you scale, decisions made too late.
- Data scattered across systems that should be one source of truth.
Talk to the people who live inside the process, not only the people who own the budget. Quantify the pain in time and money. Then try to disqualify it. Ask what would have to be true for SaaS to be enough. If SaaS is enough, stop here and say so.
A qualified problem with evidence behind it, or a clean decision not to proceed. Both are wins.
Map the process and the domain until you actually understand them.
This is the core of the framework. The goal is a shared, accurate model of how the work really happens, expressed in the language of your business rather than the language of software. We use Domain-Driven Design and EventStorming to get there: you map the events, the actors, the decisions, and the boundaries, and the model that emerges is the thing every later stage depends on. Get this wrong and everything downstream inherits the mistake.
Mapping is run as a focused five-day workshop. The structure below is how we run it; you can run a lighter version of the same shape yourself.
Current process
Client-facingCurrent-state process maps, a prioritized process list, a pain catalog, a workaround inventory, and an open-questions list.
Internal synthesis
Internal synthesisA reviewed process list, an updated domain and current-state model, a screen catalog, and Day 3 validation wireframes.
Validation through wireframes
Client-facingCorrected flows and wireframes, scope candidates, priority signals, edge cases, and the risks worth naming.
Scope and roadmap shaping
Internal synthesisA scope review artifact, a draft roadmap, milestone candidates, and effort, timeline, and cost assumptions.
Scope and recommendation review
Client-facingA shared scope position, decision owners, unresolved assumptions, and the next step.
Double-check that you understood the business, and decide what it feels like to use.
Design has two jobs in this framework, and the first one matters more than the second. Before it makes anything beautiful, design is a second pass at understanding. By turning the model into the first usable product structure, you find the gaps the map missed. If the design cannot express the process cleanly, the process was not understood, and that is a finding worth having before a line of production code is written.
The second job is to build the design-system foundation that engineering will use in Stage 4. Modern tooling makes this fast: you can put a working structure in front of real users early and let their reactions correct the model again.
- A first usable product structure for the scoped process slices.
- A design-system foundation reused directly in engineering.
- A confirmed, or corrected, understanding of the business.
Turn the model into working software you own, fast.
Engineering takes the process mapped in Stage 2 and the structure aligned in Stage 3 and turns them into working software, released in milestones that map to business outcomes rather than engineering buckets. We build with an AI-assisted development lifecycle (AI-SDLC): the model and the design feed the build directly, so the distance between "we understand this" and "this is running" collapses from quarters to weeks.
Speed here is not the engineers typing faster. It comes from the floor underneath the application. Governance, compliance, security, and execution live in the runtime, so the people building inside it do not handle them by hand. The application can change every week; the floor does not. That is what makes hour-scale change safe instead of reckless.
The build runs on a Describe, Review, Validate, Ship loop, documented on the runtime page . The map is the source of truth; the code is downstream of it. When the business changes, you change the map, and the software follows.
The lifecycle is deliberately lean. It is built to keep throughput high without silently losing quality, security, or auditability, and it is small enough that one full-stack engineer can own delivery end to end, with quality support pulled in only where the risk is real.
- Work in small, shippable increments. Every change is a short-lived branch and a single pull request, sized so it can be understood, tested, and reversed on its own. Big-bang releases are the anti-pattern; incremental ones behind flags are the default.
- The pull request is the quality gate. Not a meeting, not a sign-off document. A change merges only when continuous integration is green, the relevant tests pass, and the change has been exercised at least once on a live preview. The gate is automated and the same for everyone.
- Previews replace UAT. There is no separate acceptance environment that drifts from production. Each change deploys to its own preview, and that preview is where the work is reviewed and, for larger slices, signed off by the people who own the process. Acceptance happens on the real thing, with seeded data, not on a description of it.
- Feature flags decouple shipping from releasing. Code reaches production continuously; exposure to real users is a separate decision controlled by a flag. That is what lets a change ship the same afternoon and stay safe: if it misbehaves, the first response is to turn the flag off, not to scramble a rollback.
Automation runs first and always; human testing is targeted and triggered, not a phase the whole build waits on.
- Formatting, linting, and type checks block the merge automatically.
- Tests are written where the business rules live: state transitions, calculations, permissions, and the mappings that move data between systems. Persistence and cross-module behavior get integration tests; schemas and external integrations get contract tests; a small, stable set of end-to-end tests covers the critical journeys.
- Dedicated QA is pulled in on demand, triggered by the risk a change carries: anything touching authentication and roles, anything that changes a calculation or a report, file handling, an external integration, a data migration, or a release candidate. It is time-boxed to the impacted flows, not a sweep of the whole product.
- Milestone-based software tied to process outcomes, delivered as a continuous stream of small, reversible increments rather than a single launch.
- A quality model deliberately fit to the system: reliability, observability, maintainability, with tests concentrated where a defect would cost the most.
- A traceability chain that holds: every change in production traces back through a merge, a preview and its test evidence, a pull request, a ticket, and the requirement it serves.
- Software you own and can modify, not a black box you rent.
Decide which process is worth doing next.
Once one process runs on software the company owns, the delivery evidence tells you where the next leverage is. Expansion is not "build more." It is sending the next candidate process back through Stage 1 and only proceeding when the pain signal is strong enough to justify it. The discipline that protected the first build protects every build after it.
- A ranked set of expansion candidates, backed by evidence from live delivery.
- A clear decision about which process, if any, enters Discovery next.
What we refuse to do, and why it matters.
The method is as much about what it refuses as what it ships. These are the rules that keep AI-accelerated work honest. They are the same rules we read before every workshop, and they are the part of the method most worth copying.
Do not share intermediate AI artifacts as if they were finished work.
Do not use AI-generated names, roles, features, or integrations unless they are verified.
Do not hide uncertainty. Mark assumptions as assumptions.
Do not polish weak understanding into confident prose.
Do not turn a transcript into a roadmap without human review.
Do not let wireframes become proof that the process is understood.
Do not digitize the current process without challenging it.
Do not treat stakeholder enthusiasm as validation of business value.
Do not let a workshop end without explicit non-scope.
Do not recommend custom software when the case for it is weak.
These apply to every run, every process, every recommendation.
Six commitments stronger than any single step.
If reality forces you to adapt the process, keep these. They are the load-bearing parts.
Evidence is stronger than polish. Bring transcripts, maps, and decision records, not pitch decks.
Recording and transcript coverage is required for workshop evidence, unless explicitly disallowed.
Explicit non-scope is required. What you will not build matters as much as what you will.
Custom software is one recommendation among several. SaaS, partial automation, manual bridges, and "do not build" are all real outcomes.
Milestones map to user or process outcomes, not engineering buckets.
Assumptions, risks, and trade-offs stay visible, in writing, throughout.
What it delivers, in the order it delivers it.
Your team sees the company at full resolution, often for the first time. The map exposes the constraints everyone worked around but nobody named.
Hour-scale change. When the business changes, the software changes the same afternoon. Not because the engineers got faster, but because the runtime carries the parts that used to slow them down.
Twice the operations with the same team. Onboarding measured in hours, not quarters. Decisions that come from the model, not from the meeting.
You have the method. Decide what to do with it.
This framework is published in full because we believe it is how software should be built, and because a method you cannot inspect is not a method, it is a sales script. Run it yourself. Take the five stages, the discipline list, and the commitments, and apply them to your hardest process.
If you would rather run it with the people who wrote it, that is the service we sell. We will map your process and hand back a system you own, with the model as your intellectual property, not ours. Either way, the method is yours to use.
Talk to us about running this on your process.