Two efforts, one engagement.
A custom‑software project is two projects in one: building the tool, and changing how the team works. The second is almost always underestimated. The engagement is scoped, billed, and delivered as a software project — but quietly rests on a behavior change no one is leading. The result: a tool that demands work practices no one follows. People route around it. Spreadsheets and email chains multiply. Adoption stalls. The root problem is that the two efforts are conflated. We treat them as two distinct projects, separated in time.
Build the fit. Then steer.
We separate the two efforts in time. Software ships in two distinct phases, with a deliberate transition between them — and a clear test for when to make it.
- § 01Fit
Software that mirrors how work happens today.
The job is adoption, not transformation. We make the user's day easier, not different. We meet people where they are, and we stay there until the tool has earned a place in daily work.
IndispensabilityWould the user notice immediately if we took it away? - § 02Steer
Use the software as the lever for progressive change.
Smart defaults, AI suggestions, subtle interface adjustments, automation of well‑understood steps. Behavior changes without triggering resistance, because users already depend on the tool. We steer through the medium of the software itself.
Continuous improvementOne step at a time, without rushing anyone.
Asymmetric leverage.
Leverage is something you build before you spend. In a traditional rollout, the consultancy asks employees to change in week one — before the software has done anything for them. The same nudge that would be rejected as the consultants telling us how to do our jobs in month one becomes oh, the tool suggested it, sure in month twelve.
Most failed transformations are spending leverage they have not earned. We earn it first.
The cycle changed.
The two‑phase model is not new. What is new is that AI has finally made it economically practical. The diagnosis existed before, but the cure was out of reach for most organizations.
A custom build was a long investment, and once delivered, the cost of meaningful change was high. Most organizations had only one real shot. Encoding the optimal future state up front and forcing adoption was the rational thing to do — even when it failed at scale.
- A different button placement
- A tooltip
- A required field
Coding is no longer the bottleneck. The marginal cost of a feature has collapsed. We can now finally do what the methodology actually requires: build for current reality, observe, and improve continuously.
- Smart defaults
- Contextual prompts
- Learned suggestions
- Safe automations
Copilot before autopilot.
The two‑phase model is unusually well‑suited to applied AI. The industry‑wide debate between copilot and autopilot is the same insight in different vocabulary. AI that augments an existing workflow gets adopted. AI that tries to replace one gets ignored or sabotaged.
- § 01
Phase one is copilot.
We build AI that sits beside the worker, making their existing way of doing things faster and easier.
- § 02
Phase two responsibly automates.
Having watched how the copilot is actually used, we automate the parts that have proven safe and start steering toward better outcomes.
- § 03
A second‑order benefit, unique to AI.
The training data for phase two is generated by phase one. Real use, edge cases, corrections, workarounds — the substrate on which intelligent steering is built. Traditional consulting cannot offer this.
The transition trigger.
Everything plays out in the transition. Too early, we launch phase two before users really depend on the tool — and the change meets resistance. Too late, we postpone improvement indefinitely. We combine a small set of signals: one load‑bearing test, three confirming indicators, and one readiness criterion.
The withdrawal test
If the software disappeared for a day, would users be genuinely impaired — and would they complain to us, rather than shrug and go back to the old way? Real‑world incidents generate this data for free. A flood of this is blocking me messages from a minor bug means leverage is real. A half‑day outage that produces silence means it is not.
Telemetry rich enough to see where to steer
Phase‑two interventions only work if the data points to specific, shared improvement targets. Phase‑one software ships instrumented from day one — the trigger depends on it.
Coverage of actual work
The percentage of work‑of‑type‑X actually flowing through the system — a sharper measure than raw logins or session counts. Phase‑one discovery establishes the denominator through direct observation.
Collapse of shadow systems
The spreadsheets, group chats, secondary tools, paper notebooks. If these are atrophying, the work has actually moved. If they are stable or growing, it has not — no matter what the dashboard says.
Direction of feature requests
When ideas begin coming from end users rather than the project sponsor or management, a threshold has been crossed. The people doing the work are now invested in the tool.
From ambition to production.
Ambition is the destination. Production is the foothold — where you plant your feet first — and the journey between is what we are paid to manage. Getting a project approved internally often means framing it as a major transformation. We leave that ambition intact. We deliver it through a method that stays humble, that respects the people who will have to live inside the result.