// engagement_protocol
How a Build Works
One protocol. Scoped on entry, applied as the system reveals itself. Every engagement runs through the same lifecycle, priced phase by phase.
// lifecycle
The Lifecycle
Discovery & Risk Mapping
Define the product, users, critical workflows, data, permissions, irreversible actions, and failure boundaries.
Prototype & Architecture
Create the core UX, system model, database shape, API boundaries, and deployment plan.
Build & Verify
Implement the application in small auditable slices. Test permissions, data persistence, edge cases, mobile UX, and failure states.
Launch & Harden
Deploy to production, configure monitoring, document recovery paths, and tighten security boundaries.
Iterate
Improve based on real usage, bug reports, operational friction, and new requirements.
// modes_of_work
Modes of Work
These are not standalone services. They are applied within the lifecycle.
Scope is not selected on entry. It is determined during Discovery & Risk Mapping.
Most builds touch all three. The work determines what is required.
build --product
Web applications, software platforms, internal tools, and mobile apps. Built in small auditable slices, with permissions, data persistence, and failure states tested as we go.
Constraint: Scope is defined before we build. Changes are explicit, not absorbed silently.
integrate --systems
Backend APIs, third-party integrations, webhooks, auth flows, and automation. Designed for retries, idempotency, and partial outages rather than the happy path.
Constraint: Third-party systems change and fail. We design for that, not around it.
harden --policy fail-closed
Threat modeling, permission boundaries, audit trails, monitoring, and failure-mode testing. The security-first angle that runs through every build, not a separate phase.
Constraint: Security is built in from the first slice. It cannot be bolted on at the end.
// cadence
Cadence
Small auditable slices
Work ships in pieces you can review and revert, not one undifferentiated push at the end.
Working software every week
Progress is a deployed slice you can click through, not a status report.
Changes are explicit
Scope changes are written down, priced, and agreed before they enter the build. Nothing is absorbed silently.
A direct line to the builder
One-person lab. No account managers, no relay. The engineer building your system answers the messages.
// first_engagement
Week One
The first engagement starts with Discovery, not with code. By the end of week one you have four things in hand.
Discovery call
Walk the system: users, critical workflows, data, integrations, and the actions that cannot be undone.
Risk map
What can fail, what must never happen, and where the failure boundaries sit. Written down, not implied.
Written scope
Deliverables and failure boundaries for the first phase, in writing. What is in, what is out, what is deferred.
Fixed price for the phase
The phase is priced before it starts. No open meter. You approve the next phase only when this one is accepted.
// faq
Questions
How much does a build cost?
How long does a build take?
Fixed scope or retainer?
What do you not take on?
Do we own the code?
What happens if we stop after one phase?
Who does the work?
If the lifecycle fits your system, the next step is Discovery.