How to build software that fits your business instead of fighting it.
Start with the way your company actually works. Map the process, choose what belongs in software, then build a system your team owns and can change in hours. This page explains how to run the method.
Read the frameworkAllow about thirty minutes. These are the five stages and working rules we use with clients.
Written for the person who feels it first.
You run technology for a company of 50 to 500 people. Three to five processes hold the business together, but each sits in a different system built for someone else's way of working. A change you can describe in one sentence takes weeks to ship. Data is split between tools that do not talk to each other. You feel the cost before most of the company does.
You may have tried SaaS that did not fit or hired consultants who could not fix the underlying process. Here is the method we would hand you to work through the problem 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.
Custom software often fails because it encodes a process nobody mapped. Requirements are written before anyone understands how the work happens, and the software preserves that misunderstanding. When the business changes, the system falls further behind.
We begin with a model of how your company operates. Once the model is clear, software can follow it and remain cheap to change. The model is your intellectual property. Your company owns it independently of any vendor or source-code custodian.
We call this Process Native Software: software shaped by the real process, focused on the parts with the greatest measurable return, and owned by the company that relies on it. Most companies should still buy SaaS for most needs. Bespoke software earns its place when the process model shows an advantage that an off-the-shelf product cannot provide.
Five stages, one graduation path.
Each stage answers one practical question. Any stage can end with a decision to stop, including "do not build." Run all five yourself, or stop once you have enough evidence to decide.
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 questions stay in order, but the work is iterative. Design and engineering overlap, while both can expose gaps in the map. Confirm that the process is understood before deciding how the product should feel. Confirm that it is worth building before writing production code.
Find out whether the problem is worth solving.
Discovery qualifies the problem. Find out what the problem costs, how it relates to your process, and whether an existing product can solve it. Many ideas should stop here. Rejecting a weak case now costs far less than learning the same lesson after a build.
- A process specific to your company that generic software handles poorly.
- A change loop measured in weeks or months that should be measured in hours.
- A measurable cost, such as wasted time, late decisions, or quality loss during growth.
- Related data split across systems when the team needs one source of truth.
Talk to the people who do the work as well as the budget owners. Measure the cost in time and money, then look for reasons to reject the case. Check whether SaaS can cover the process. If it can, say so and stop.
Evidence for proceeding, or a documented decision to stop.
Map the process and the domain until you actually understand them.
Process Mapping creates a shared model of the work in your company's language. We use Domain-Driven Design and EventStorming to map business events, participants, decisions, and boundaries. Every later stage depends on the result, so an error here will carry into the product.
We run this as a focused five-day workshop. You can use the same sequence in a smaller workshop of your own.
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.
Check the model through use, then shape the product.
Design gives the process model a usable product structure. Doing that exposes gaps that the map missed. If the interface cannot express the process clearly, return to the model before writing production code.
This stage also establishes the design system for Engineering. Put the working structure in front of process users early and use their feedback to correct the model.
- A first usable product structure for the scoped process slices.
- A design-system foundation that Engineering can reuse.
- A business model corrected by feedback from process users.
Turn the model into working software you own, fast.
Engineering turns the process map and product structure into working software. Releases follow milestones tied to business outcomes rather than technical work categories. Our AI-assisted development lifecycle (AI-SDLC) feeds the model and design into the build. The model and design stay attached to the build, so the team can deliver in small, shippable increments.
The runtime handles governance, compliance, security, and execution consistently across the application. Engineers can change the application without rebuilding those controls by hand. That stable runtime is what makes hour-scale changes safe.
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 lean enough for one full-stack engineer to own delivery. Automated checks cover every change, while specialist quality support joins when the risk warrants it.
- Work in small, shippable increments. Every change uses a short-lived branch and one pull request. Keep it small enough to understand, test, and reverse on its own. Release incrementally behind flags.
- The pull request is the quality gate. A change can merge after continuous integration passes, the relevant tests succeed, and someone exercises it on a live preview. The same automated gate applies to everyone.
- Previews replace UAT. Each change deploys to its own preview instead of a separate acceptance environment that can drift from production. Process owners review larger slices there with seeded data and sign them off when needed.
- Feature flags decouple shipping from releasing. Code reaches production continuously, while a flag controls when users see it. If a release misbehaves, turn the flag off first and investigate without a rushed rollback.
Automation runs on every change. Human testing focuses on the areas where failure would carry real risk.
- Formatting, linting, and type checks block the merge automatically.
- Tests sit beside the business rules they protect, including state transitions, calculations, permissions, and mappings between systems. Integration tests cover persistence and cross-module behavior. Contract tests cover schemas and external integrations. A small, stable end-to-end suite covers critical user journeys.
- Dedicated QA joins when a change affects authentication, roles, calculations, reports, files, external integrations, data migrations, or a release candidate. The review covers the affected flows.
- Software delivered in small, reversible increments tied to process outcomes.
- A quality model suited to the system, with tests concentrated where defects would cost the most.
- Traceability from each production change to its merge, preview evidence, pull request, ticket, and requirement.
- Software your company owns and can modify.
Decide which process is worth doing next.
Once the company runs one process on software it owns, delivery evidence can point to the next candidate. Send that process through Stage 1 and proceed only when its cost justifies another build. Apply the same checks used for the first process.
- A ranked set of expansion candidates, backed by evidence from live delivery.
- A clear decision about which process, if any, enters Discovery next.
Ten rules for keeping the work honest.
We read these rules before every workshop. They prevent fast, AI-assisted work from outrunning the evidence.
Label intermediate AI artifacts as drafts and review them before sharing.
Verify every AI-generated name, role, feature, and integration.
State uncertainty and mark assumptions clearly.
Leave weak understanding visible until the evidence improves.
Require human review before a transcript informs the roadmap.
Treat wireframes as tests of the process model, not proof of it.
Challenge the current process before digitizing it.
Validate business value with evidence beyond stakeholder enthusiasm.
End every workshop with explicit non-scope.
Recommend custom software only when the evidence supports it.
Apply all ten rules to each process and recommendation.
Keep these six commitments when the process changes.
Adjust the workshop to suit the work, but preserve these commitments.
Prefer evidence to polish. Bring source transcripts, process maps, and decision records.
Record and transcribe workshops, unless the client explicitly disallows it.
Explicit non-scope is required. Record excluded work beside the agreed scope.
Consider custom software as one option. A valid recommendation may be SaaS, partial automation, a manual bridge, or no build.
Tie milestones to user or process outcomes, not engineering buckets.
Keep assumptions visible, along with risks and trade-offs, in writing.
What the method changes.
The process map shows how the company works in enough detail to name hidden constraints and familiar workarounds.
Changes that once took weeks can ship in hours because the runtime already handles common controls and delivery work.
Each engagement sets a measurable capacity target, such as handling more operations with the same team or cutting the time new colleagues need to learn the process.
Apply the method to one difficult process.
The full framework is here for you to inspect and use. Take its five stages, discipline rules, and commitments, then apply them to a process that resists your current software.
You can also run it with us. We map the process and hand back software your company owns, while the model remains your intellectual property. The method stays available whether you hire us or work through it alone.
Talk to us about running this on your process.