Phil / Tobi meeting

What this is: a proposal for getting my projects to Ready and handing them to engineering with clear ownership, plus three short points.

What your answer decides: whether we trial it on my next project. My pick: trial it, then adjust after its retro. How to answer: "OK to trial", or the one thing you'd change.

The process

Goal: devs spend as little time as possible on my projects, with quality and ownership intact, and less with every project.

1 · me

Shape

ClickUp: Discovery → Shaping

Scoping and proof of concept
Design, then a working prototype in Kittl
Design sign-off

Time: depends on the project
Dev time: none

2 · me + tech lead

Kickoff

ClickUp: Shaping

Build mode: production handover or prototype as spec
Architecture the tech lead agrees to
Ease estimate and receiving dev

Time: one session
Dev time: max ½ day, usually much less

3 · me

Build to ready

ClickUp: Shaping → Ready

I build on a branch behind a flag and iterate until it's ready
One sense check with the receiving dev. Big gaps: it stays in Shaping
Handover package (below)

Time: usually about 1 day
Dev time: about 1 hour for the sense check

4 · dev

Development and QA

ClickUp: In Development → In Dogfooding

The receiving dev owns the code. I stay the Driver for scope and product calls
QA starts here
My small PRs only in the agreed lane, dev tagged, CI green
Short async retro

Time: measured per project
Dev time: the part we shrink

After that the roadmap continues as usual: In Product Sign-off → In XP → Released.

What changes: I build before Ready, but only after the kickoff, on a branch behind a flag, and in the build mode the tech lead agreed.

The handover package · what "Ready" means for my projects

Design and prototype link PRD with acceptance criteria Architecture agreed at kickoff Ease estimate Impact and metric Branch behind a flag Tracking Gap list, resolved or accepted Rollout

How we measure the goal

Dev effort: days the receiving dev reports per project
Cycle time: Ready → In Product Sign-off on the ClickUp card
QA bounces per project
Rework and its cause, from the retro

Question: is that the right measure, or what would you track?

Open: dev rules for people who prototype

More and more of us prototype with AI (Olek, Nicolas, me), with different levels of technical understanding, and that will grow as the models get smarter. The dev rules need to adapt to that. My process is one step in that direction. How do you see it?

What does everyone have to do before a dev looks at their work: self-review, a review by a second model, tests, green CI?
What can we merge ourselves, and what always needs a dev?
How much review time from devs is fair, and who gives it?

Clearing up: QA on Mockups logged-out

In the design sign-off thread, QA asked whether to start testing the preview, and I said yes without thinking. We had no rule for it. With the process above, QA starts once the project is In Development.

Observation: admin still runs through Phil

Since mid-September, people pointed me to Phil for each of these:

System	What waited	When
GitHub org	Adding people to the org	16 Sep, 2 Oct
Cloudflare	Email rules for the app review test accounts	24 Sep
AI credits	Credits for Workers AI	1 Oct
Login codes	Verification emails that only reach Phil and Jonny	15 Sep
1Password	Admin help while the admins were off	24 Sep

Question: should some of this sit with someone else, so less of it waits on Phil?

Align: Sapiens in production

The custom mockup prototype runs on Sapiens, Meta's model for human figures. The version we use has a non-commercial licence.

Sapiens 2 (April 2026) has its own licence. Our licence check found it may allow commercial use, but one clause needs a legal read. The current plan uses DINOv3 for anything that ships.

Question: can we use Sapiens in production, and if so, which version?