HOW IT WORKS
01 · 09

The process map is the contract.

We do not start with software. We start with how the company actually runs. We write it down, we validate it, then we decide together whether bespoke software is the right answer at all.

Book a fit call Walk the five steps

This page is the engagement methodology. If you want named, fixed-scope engagements with starting-from prices, go to the services. If you want the public version of the discipline behind the engagement, read the method.

02
THE FIVE-STEP PROCESS

Five steps from first conversation to a system that grows with the business.

A high-level view of the engagement. Each step is allowed to end the engagement honestly. If the answer is do not build, we say so before the proposal.

  1. 01

    Discovery

    Week 1 to 2

    A cross-functional working session. We hear the pain you brought, walk the process with the people who actually do the work, and select the one use case that will earn the map. The founder or COO is in the room, not a delegate. We are looking for evidence that this is a process problem, not a tooling problem.

    Output

    A written fit assessment: pain heard, signals that matter, reasons to proceed, reasons not to. If we proceed, a fixed proposal for the map.

  2. 02

    Design and POC

    Week 3

    Co-design sessions against the validated process. We draft low-fidelity wireframes that exist to test understanding, not to look like a product. By the end of the week we have a functional slice built against your real data, not vendor sample data.

    Output

    A working POC and a draft scope view. Wireframes are a question, not an answer.

  3. 03

    Demo

    Week 4

    We prove value on your data, not ours. The team walks your stakeholders through the outcome in the language of the process they own, then through the platform vision: how this slice extends into a system the company can operate against.

    Output

    Validated scope, explicit non-scope, milestone candidates, and the manual bridges that hold the line until software replaces them.

  4. 04

    Proposal

    Week 5

    A 12-month engagement plan. Phased pricing tied to milestones, not to months. ROI projections against the business metric you named in Discovery. The recommendation may be build, partially build, defer, use SaaS, or investigate further. All five are real outcomes.

    Output

    A fixed proposal for the first milestone, plus a directional plan for the rest of the year.

  5. 05

    Pilot and Expand

    Month 2 to 12

    Design and engineering ship the first usable surface inside the first month. From there we work in milestones that map to business outcomes, not to engineering buckets. When the first process is operating against the system, the next process earns its own fit conversation. The map is alive; the software follows the map.

    Output

    Working software on a milestone cadence, plus a system that expands from one use case to many as the business is ready.

03
THE ENGAGEMENT, STAGE BY STAGE

Zoomed out, those five steps follow a framework: Fit, Map, Build, Expand.

Each part is allowed to end the engagement honestly. Expand keeps the map alive. If the answer is do not build, we say so.

  1. 01

    Fit

    Deliverable

    Qualified pain, written assessment

    Time

    1 conversation

    In the room

    Founder or COO + process lead

  2. 02

    Map

    Deliverable

    Five-day workshop, output package, recommendation

    Time

    5 working days

    In the room

    Process users, owners, operator pair

  3. 03

    Build

    Deliverable

    Design + engineering in parallel, milestones tied to outcomes

    Time

    First surface < 30 days

    In the room

    Delivery engineer, design lead, your team

  4. 04

    Expand

    Deliverable

    In-scope change live the same day. New processes return to Fit.

    Time

    Hours to days

    In the room

    Same team, alongside yours

Inset · Stage 02

The five days of the map.

  1. Day 1

    Walk the process

  2. Day 2

    Process the evidence

  3. Day 3

    Validate via wireframes

  4. Day 4

    Shape scope + offer

  5. Day 5

    Recommendation review

04
STAGE BY STAGE · IN DETAIL

STAGE 01

Fit

We qualify the pain before we sell the work.

A short conversation about the process you think is broken, the tools you tried, the cost of getting it wrong, and the constraint that nobody on the outside understands. We are looking for evidence that this is genuinely a process problem, not a tooling problem we can solve by replacing one SaaS with another.

Most companies should still be on SaaS. We will tell you if that is you.

Deliverable

A written fit assessment: the pain we heard, the signals that matter, the reasons to proceed, and the reasons not to. If we proceed, a fixed proposal for the map.

Who is in the room

You. Process lead on our side. The founder or COO, not a delegate.

Time

One conversation. A written reply within the week.

STAGE 02

Map

Five days to a written, validated picture of how the work really happens.

The map is a five-day workshop format. It is the part of the engagement we have run most often and trust the most. The output is the contract everything downstream is judged against.

The Map engagement is sold as Domain-Driven Process Modeling: fixed scope, fixed price, starts from EUR 8k. This page is the methodology behind it; the service page is where you buy it.

  1. Day 1

    Current process walkthrough with the people who actually do the work. Process users, owners, system owners. We capture actors, steps, decisions, tools, files, workarounds, pain, cost, integrations, and open questions.

  2. Day 2

    We process the evidence. Internal day, no client time. We verify the process list, extract the screens it implies, and draft low-fidelity wireframes that exist to validate understanding, not to look like a product.

  3. Day 3

    Validation through wireframes. Together we test happy paths, edge cases, permissions, data needs, and the places we have probably misunderstood. Wireframes are a question, not an answer.

  4. Day 4

    Internal scope and offer shaping. We turn the validated map into a scope review artifact, milestone candidates, draft roadmap, risks, dependencies, and the assumptions behind effort, timeline, and price.

  5. Day 5

    Scope and recommendation review. We walk you through what is must-have, what is later, what stays manual, and what should not be built. If the alignment is strong enough, we discuss the offer.

Deliverable

A reviewed Process Mapping output package: executive summary and recommendation, current and future-state process maps, explicit scope and non-scope, milestone breakdown, rough wireframes, integrations and dependencies, risks and unresolved assumptions, and a commercial proposal sized to the result.

Who is in the room

Process users, owners, system or data owners. Founder or COO present for Days 1, 3, and 5. Our process lead, engineering lead, and operator pair.

Time

Five working days, plus a short preparation week.

STAGE 03

Build

Design and engineering start together, against the same map.

There is no separate discovery phase, no design package handed over a wall, no sprint zero spent on preparation. Within the first one to two weeks, design produces the first usable process slice and the engineering team ships the first real implementation against it.

From there we work in milestones that map to business outcomes, not to engineering buckets. Each milestone is demoed in the language of the process it supports.

You own the result. Codebase, data, runtime configuration, decision records, all of it.

Deliverable

Working software, shipped on a milestone cadence, against the scope agreed in the map. Demos in the language of the process, not the language of the framework.

Who is in the room

Product delivery engineer, design lead, operator pair, AI in the loop on the boring work. Your team in the demos and the milestone reviews.

Time

First useful surface inside the first month. Milestone cadence from there.

STAGE 04

Expand

When the business changes, the software changes with it. When another process is ready, we map that one too.

Most enterprise software cannot change fast because of how it was built. Process Native Software is built so that a change you understood on Monday is live by Tuesday. The map is alive. The software follows the map.

Expansion into another process always starts back at Stage 1. We do not assume that because one process justified custom software, the next one will.

The discipline behind this stage is published on the method page: the blueprint, the practitioner workbook, and the templates. The runtime that operationalizes it is Process Native Software.

Deliverable

A live system that evolves on the cadence of the business. New process candidates evaluated honestly, one at a time.

Time

Hours to days for in-scope change. New processes follow the full stage sequence.

05
WHO IS IN THE ROOM

The owner is in the room.

Building the operating system of a company is the founder's job. Not the vendor's, not the consultant's, not the committee's.

Vendor selection is a delegable problem. Encoding how you run your business is not. If the decision-maker cannot make the time for the fit call and Days 1, 3, and 5 of the map, the timing is wrong. Come back when it is.

Roles on our side

  • 01

    Process lead

    Runs the map. Lives in the evidence.

  • 02

    Engineering lead

    Owns the runtime and the build.

  • 03

    Operator pair

    Sits with your team through the map and the early build.

  • 04

    Product delivery engineer

    Leads milestone implementation, quality, release rhythm, and risk.

  • 05

    AI in the loop

    At every stage, doing the boring work and watching the patterns. AI output is a working input, never service evidence, until our team has reviewed it.

06 / 07
THE DISCIPLINE IS THE PRODUCT

06 · What we commit to

The discipline is the product.

  • Evidence is stronger than polish.

    We bring transcripts, maps, and decision records, not pitch decks.

  • Sessions are recorded and transcribed.

    Unless you explicitly disallow it.

  • Explicit non-scope is part of every output.

    What we will not build is as important as what we will.

  • Custom software is one possible recommendation.

    SaaS, partial automation, manual bridges, and do not build are all real outcomes.

  • Milestones map to user or process outcomes.

    Not engineering buckets.

  • Internal assumptions and trade-offs stay visible.

    In writing, throughout the engagement.

07 · What we do not do

We do not do discovery theatre.

  • No seventy-slide discovery deck.

    The map is the deliverable.

  • No best-practice templates.

    The map is yours.

  • No vendor selection consulting.

    We assume you already tried that.

  • No staff augmentation.

    Either we engage on the operating system or we do not engage.

  • No soft qualification.

    If your process is not the constraint, we say so on the fit call.

08
PRICING POSTURE

Engagements are priced to the system, not to the hour.

The fit call is free and ends in a written assessment. If we proceed, you get a fixed proposal for the map. The map produces a fixed proposal for the build, sized to the milestones it identifies. The post-launch stage is a retainer, sized to the actual rate of change in your business.

We do not bill timesheets. We bill outcomes against the map.

  1. Fit

    Free

    Written assessment

  2. Map

    Fixed

    Sized to the workshop

  3. Build

    Fixed per milestone

    Sized to the result

  4. Expand

    Retainer

    Sized to the rate of change

09
THE FIRST STEP

The first step is the fit call.

A fit call is the right way to find out whether the map makes sense for your business. We will be honest about it, even when the honest answer is no.

Book a fit call See who this is for, and who it is not

See the three engagements