§ method // how engagements work

HOW_I_WORK.md

A repeatable process built around one goal: shipping the right thing, not just the requested thing.

~ $ cat engagement-process.sh |

defined steps

1–2wk

scoping phase

$600

minimum engagement

async

default comms

§ 01 // the process

steps 1–6

Understanding the problem

free

Before any quote or spec, I need to understand the business context: what the system needs to do, who uses it, what data exists, what "working" looks like, and what's been tried.

Short async exchange or a single focused call — not to produce documents, but to make sure I'm solving the right problem.

Fit assessment

free · no commitment

Once I understand the problem I'll tell you honestly: whether it's a good fit, what I'd build, what I'd challenge, and if AI is actually the right tool.

→ Is it a good fit?

→ What I'd build

→ What I'd challenge

→ Is AI the right tool?

Scoping

paid

If we're aligned, scoping is the next step. It produces a written spec that both parties sign off on before a single line of code is written. This document becomes the contract for everything that follows.

spec.md — deliverables

· success criteria

· architecture sketch

· stack decisions

· milestone map

· explicit out-of-scope

· risk register

· data model overview

· integration dependencies

duration

1–2 weeks

depends on complexity

cost

credited

applied to project total

output

signed spec

yours to keep regardless

what happens during scoping

Deep-dive async session to map all system requirements and constraints

Draft spec shared for review — you push back, I revise

Final spec signed off — this becomes the binding reference for all delivery decisions

No spec, no code. This is non-negotiable.

Skipping this step is the single biggest cause of failed projects. The spec fee is the cheapest insurance you can buy.

Delivery phases

paid

Every project follows the same arc. No shortcuts, no skipped phases.

P1 Discovery 1–2 wks

Produce a scoped SOW and technical roadmap.

· Scope document

· Success metrics

· Data inventory

· Risk register

P2 Architecture & Design 1–3 wks

Decide stack, data model, and deployment pattern.

· Architecture diagram

· API contract

· Security checklist

· Cost estimate

P3 Development & Iteration ongoing

Build incrementally with frequent demos.

· Codebase + CI/CD

· Tests

· Staging deployment

· Demo notes

P4 Evaluation & Launch milestone

Validate success metrics and release to production.

· Performance report

· Runbook

· Handoff documents

· Training session

P5 Maintenance & Growth recurring

Monitor, iterate, and add features from metrics.

· Monthly health report

· Backlog grooming

· Roadmap updates

Communication

Async by default. Weekly written update. Calls are reserved for specific, high-value moments only.

kickoff call ✓

milestone demos call ✓

scope changes call ✓

blockers call ✓

everything else no call ✗

Handoff

Client owns everything. Built to run without me.

Full repo ownership transferred

API specs documented

On-call runbooks included

Architecture Decision Records

No dependency created

§ 02 // commercial terms & requirements

steps 7–8

COMMERCIAL_TERMS.md

non-negotiable structure

payment_schedule

40%

on signing

upfront

50%

on threshold milestone

mid-project

10%

on acceptance

final

$600 minimum

No engagement below this threshold. This covers scoping overhead and ensures the problem is worth solving.

Changes require a written order

No scope changes without a written change order first. This protects both parties from scope drift and invoice surprises.

WHAT_I_NEED_FROM_YOU.md

The quality of the conversation at step 1 directly determines the quality of what gets built. These four things make that conversation possible.

Real problem, not a strict solution

Describe what's broken or slow or propose a possible solution, not what you think the code should do.

Access to real data

Sample data, schemas, or exports. Anonymised is fine. Nothing is fine.

A decision-maker in the room

I need someone who can say yes. Chains of approval kill momentum.

Realistic timeline expectations

Good work takes time. I don't do rush jobs that produce brittle systems.

§ 03 // not a fit

step 9

When I'll decline

Not every engagement is right. I'd rather say no early than deliver something that doesn't work.

No clear problem owner

If nobody can define success, nobody will agree when it's reached.

Spec-free engagements

Jumping straight to code without alignment produces expensive rework.

Unrealistic timelines

If you need it in two days, I'm not the right person for this.

AI for AI's sake

If the goal is to have AI in the pitch deck, not to solve a real problem.

Ongoing retainers without scope

Retainers only work when there's a defined backlog and clear priorities.

Below minimum budget

Engagements under $600 don't allow for proper scoping or delivery.

§ ready to start

Start with step 01.
It's free.

Send a short brief — what the system needs to do and what's broken. I'll respond within 48 hours with honest feedback.

send a brief back to process

synaptech // method v2.1 // last updated May 2026

available for engagements