INTERACTIVE EXAMPLE
FROM PROBLEM TO SYSTEM.
Beyond
building.
Verify.
Let’s follow an illustrative request.
The same need runs through every stage: we define how this kind of request should be handled, from understanding the problem to operating the system.
DISCOVER EVOLVE
One request.One shared criterion.
01 / Discover
First, find the problem.
Before choosing a solution, we examine where responsibility is lost and what information is missing.
It’s unclear who should respond.
Give it a response and someone responsible.Activate the example to see the result.
02 / Define
The agreement has boundaries.
Resolve only with complete information; otherwise, keep it pending with an owner and a reason.
Responsibility · scope · criterion
One person responsible. An explicit scope.Activate the example to see the result.
03 / Design
Two conditions. One criterion.
We define what should happen in both cases.
Complete information
Required information is missingWith an owner and a recorded response.
Keeps an owner and shows what information is missing. The request stays open.
Activate the example to see the result.
04 / Build
Make the behavior visible.
This demonstrates the ordinary case, not readiness for every condition.
Request with complete information
Resolved, with an owner and a recorded response.Activate the example to see the result.
05 / Validate
Still pending. The criterion is met.
It wasn’t resolved without complete information: it keeps an owner and explains what’s missing.
Compare expected and observed behavior
2 of 2 illustrative conditions verifiedWith an owner and a recorded response.
Keeps an owner and shows what information is missing. The request stays open.
The decision requires information, someone responsible, and a reason.
Activate the example to see the result.
06 / Deploy
Verified behavior becomes the baseline.
The person in charge handles requests; responsibility for maintaining the system is agreed.
Verified scope
Required information, permissions, and verified behavior, configured in production according to scope.The record preserves the context.
Activate the example to see the result.
07 / Evolve
A change doesn’t erase the agreement.
We assess its necessity and effect on pending requests. It is incorporated only if justified, agreed, and validated.
The verified scope and its criterion remain in place.
Outside the current baseline. Not yet agreed or incorporated.Require an additional piece of information to resolve this kind of request.
NOT YET INCORPORATEDActivate the example to see the result.
One criterion.
Two outcomes.
REQUESTHandle a request.
ORDINARY CASERESOLVED / WITH A RESPONSE
EXCEPTIONAL CASEPENDING / WITH AN OWNER AND REASON
CRITERIONResolve only with complete information; otherwise, keep it pending with an owner and a reason.
EVOLUTIONOutside the current baseline. Not yet agreed or incorporated.
ILLUSTRATIVE WALKTHROUGH · 7 OF 7 STAGES
Still pending. The criterion is met.
The illustration demonstrates only the conditions shown.
VERIFIED
EXAMPLE S–01
Read the full process
Supporting reading
The example shows the logic. The depth of work depends on the problem and the agreed scope.
What do we need to understand and define?
Understand the problem before proposing a solution. We review: business context, users, the current process, existing tools, friction, available information, constraints, dependencies, the intended outcome.
The outcome isn’t yet “we’ll use this technology.”
Decide what’s worth building. We turn what we’ve learned into: scope, priorities, features, risks, dependencies, requirements, phases, success criteria.
We also identify what should NOT be built. That matters just as much.
How do we turn the agreement into something verifiable?
Design the system before developing it. Depending on the project, we may work on: user flows, process flows, architecture, information architecture, wireframes, interfaces, integrations, automation logic.
This is where the system starts taking shape.
Turn the design into a working solution. We develop and integrate incrementally. Wherever possible, this includes: a test environment, reviews, milestones, frequent validation.
We don’t wait until the end to show everything.
Test how it works under real conditions. We review: functionality, responsive behavior, edge cases, errors, integrations, data, permissions, accessibility where applicable, performance.
A project isn’t finished because it compiles. It’s finished when it meets the agreed criteria.
What does it take to operate and maintain it?
Bring the system into production. Depending on scope, this includes: deployment, DNS, environment configuration, migration, analytics, monitoring, final checks.
After launch, the business keeps changing. We can continue through: maintenance, support, improvements, new integrations, new features, optimization.
Not every project needs an ongoing relationship. But systems that keep evolving need a responsible way to do so.
Technical discovery is work, not a sales meeting.
For sufficiently complex projects, discovery can be a contracted phase before development.
It may include interviews, process mapping, technical analysis, tool review, scope definition, risks, recommended architecture, an initial estimate, and a work plan.
When we recommend technical discovery
- Legacy systems are involved.
- Several platforms need to integrate.
- We don’t yet know how to obtain certain data.
- There are external dependencies.
- The project involves physical equipment.
- The scope is still ambiguous.
- An architectural mistake could be costly.
We don’t present uncertainty as certainty.
How we work
- Transparency
- When a risk emerges, we communicate it.
- Iteration
- We prefer to validate early.
- Documentation
- What matters should be documented.
- Scope discipline
- Changes are managed.
- Technical honesty
- We don’t present uncertainty as certainty.
Project models
- Defined scope
- Suitable when the problem and scope are sufficiently clear.
- Discovery + build
- Recommended for complex projects.
- Iterative development
- For systems that evolve in phases.
- Maintenance / evolution
- For continuity after launch. Not everything needs a recurring contract.
Still unsure exactly what you need to build?
That’s precisely one of the problems discovery can solve.