service dossier / 03
find the fracture before the outage.
An application that is hard to change, a brittle integration, a slow critical path, or an operation nobody can explain. Begin with evidence, then make a focused plan.
open the inspection ↓break the happy path / select a condition
the question
A rewrite is a decision. Evidence comes first.
Conceptual engineering exercise. No live system is being tested or altered.
01 / the working boundary
make it hold.
You have a working system and a concrete limitation, failure pattern, or operational concern.
Start with one meaningful workflow and its failure cases. Agree the acceptance criteria, access requirements, delivery sequence, and ownership before implementation.
02 / inspectable outputs
- System and dependency map
- Prioritized findings tied to observed behavior
- Targeted architecture and implementation changes
- Verification, monitoring, and recovery guidance
Scope these outputs around your critical workflow and the acceptance criteria you agree.
03 / questions a useful system survives
01Which failure is hurting a real user today?
02What evidence would disprove the suspected cause?
03Who can roll back, and how would they know to do it?
fit before features.
A reproducible failure, an important constraint, and access to the relevant code or operational evidence make diagnosis possible. A full rewrite is not the default recommendation.
before you commit
Existing tools can be retained when they serve the job. Timing and fees depend on the agreed scope; this site does not generate estimates. Source ownership, hosting access, support, and release responsibility belong in the engagement discussion.
inspect the working method ↗trace a system reference ↗next / bring your version of the problem
make the weak point
a starting point.
Your track travels into a private, reviewable brief. You choose whether to share it.
scope this work ↗questions before starting ↗