Engagement record
From first query to a system you can run.
I write the boundary, prove the work in stages, and hand over a system with a documented operating path.
Send a queryStart with what is true.
You do not need a finished specification. Send the goal, the current setup, the constraints, and any links that help me see the problem.
- Goal
- What needs to change for the user or the business.
- Current setup
- The product, workflow, tools, data, and people already involved.
- Constraints
- Deadline, access, budget, policy, and dependencies that shape what is possible.
- Useful outcome
- The result we can inspect and call complete.
The work moves through three stages.
Write the boundary.
I inspect the current workflow, the available evidence, the systems involved, and the point where the work is failing or slowing down. I separate the immediate constraint from the wider wish list, then write down the scope, rate, and deadline.
What you receive
Written constraint, included scope, declared boundary, rate, and deadline.
You can stop here. Continuing into a build is a separate decision.
Prove the build in parts.
I deliver working increments that can be checked against the agreed scope. The check may be a completed user flow, an API response, a test, a migration result, a cited answer, or a production health check. The evidence should match the risk in the work.
What you receive
Working increments you can inspect, with the checks that support each one.
Leave it operable.
I deploy the agreed system, document the operating path, test recovery where recovery is part of the scope, and clarify who controls access, data, vendor accounts, monitoring, and the next change.
What you receive
A deployed system, practical documentation, and a clear record of ownership and any agreed recovery steps.
Ongoing maintenance is included only when we agree to it.
What I own, and what stays with you.
| Area | My side | Your side |
|---|---|---|
| Business reality | My sideI map roles, handoffs, data sources, dependencies, and failure points. | Your sideYou provide the operating context, edge cases, and access needed to see them. |
| Decisions | My sideI turn the evidence into a technical recommendation and written scope. | Your sideYou decide the priority, scope, and business tradeoffs. |
| Verification | My sideI show the working result and the checks behind it. | Your sideYou confirm that it solves the agreed business problem. |
| Handover | My sideI document the operating path, agreed recovery steps, and who controls accounts, data, and vendor access. | Your sideYou confirm the handover and name the people who should retain access. |
The relationship can stop at a clean boundary.
Diagnosis does not obligate you to continue. Build and ongoing operation are separate decisions.
Diagnosis only
Use the written boundary to decide whether, when, and with whom to build.
Build and handover
Continue through the agreed stages, then take control of the deployed and documented system.
Build and operation
Keep me responsible for an agreed operating scope after launch. Capacity, response expectations, and vendor costs are defined separately.
See capacity and boundariesEach next stage is agreed before work continues.
The work behind this method.
These systems differ in technology and business context. Both require scope control, verification, and an operating path after delivery.
Private Legal AI Platform
A current full-time engagement replacing a production Python answer service with a type-safe Rust workspace. Retrieval, verified citations, streaming delivery, and release control are treated as one system.
View Private Legal AI Platform
Custom Cap BD
The shared commerce and factory engine behind Custom Cap BD and connected wholesaler, supplier, and marketing operations, spanning artwork, orders, invoicing, and production tracking.
View Custom Cap BDSend the problem as it exists today.
Share the goal, current setup, constraints, and useful links. You do not need to choose the final service before writing.