Owning a project from start to finish: a case-by-case method

A reusable way to scope, build, and prove a project. For each new case, walk the same steps and fill in that case’s own facts — the steps stay the same, the facts change.

Governing principle: automate wherever it can be automated.

1. Define done first. Write down what “usable on day one” means in one sentence before building. If it takes a paragraph, the scope isn’t set.
2. Scope by sequencing. v1 is the one thing that makes it usable. Everything else — payments, verification, analytics, polish — is sequenced after launch, not abandoned. Name the exclusions explicitly.
3. Riskiest part first. Build the part most likely to fail before the parts that are merely work. If the risky part fails, there is nothing to show.
4. Write scope decisions down. What v1 includes, what it excludes, and why — so the scope is checkable, not remembered.
5. Architecture follows the seams. One service per concern, each owning exactly one surface; a gateway routes; a shared hard part (like search) gets a dedicated tool, not hand-rolled code.
6. Build for verifiability. A mock twin per service for local work; an end-to-end harness driving the real services; every claim backed by a number.
7. Ship in steps. Prelaunch environment first, then the cutover, then the launch checklist — never a big-bang deploy.
8. Report outcome in numbers, not adjectives. What shipped, how much, how fast — and what was deliberately left for later. Targets from a spec are not results; only shipped facts count.

Ownership is not solo work. Owning a line end to end and having collaborators are not in conflict — name who else was involved, and say plainly which line was yours.

9. Let an agent be scrum master on a small team. Jira-style coordination helps, but nobody likes writing tickets — the agent fills the seams between people (tickets, tracking, follow-ups), so coordination happens without anyone hating it.
10. Automate the release path until feedback is immediate. Start manual if you must, then build pipeline plus smoke tests, so the moment development is done the result is visible almost immediately.

Worked case: youteacher — public job search as v1, everything else sequenced after.

Team: a team effort — Pete and Annie Wilcox were both involved; the technical line, from scoping to launch, was mine end to end. Having collaborators and owning it are not in conflict. Problem: English teachers looking for work had to check six job boards one by one, and schools could not find teachers — neither side could discover the other. Scope: v1 was one thing — a public job search that works: jobs aggregated from multiple boards, searchable, viewable. Payments, escrow, and verification badges were left out of v1, sequenced for later.

Build: riskiest part first — eight board scrapers, normalization, a QA dashboard to get the job data flowing; then the scaffold — one service per concern, gateway routing by prefix, Meilisearch for search, Coolify push-to-deploy, a mock twin per service plus an end-to-end harness.

Ship: prelaunch environment, then DNS switch, then landing live. Outcome: about 1,962 aggregated jobs on display at launch. The talent, job, and content lines kept building on top after that. Automation, the governing principle in practice: an agent as scrum master fills the seams between people (tickets, tracking, follow-ups) that nobody likes writing; the release path went from manual to pipeline plus smoke tests, so the moment development is done the result is visible almost immediately.