Few projects and one owner are not a poetics. They are the only way we have found to answer for live without becoming a ticket factory. At Snowinch, if the model is hourly hands and nobody holding the product on, you look elsewhere.
The body shop has a clear promise: people, weeks, a rate. That can work if you need a piece and already have someone who answers in-house. On the live of a founder without an operating CTO, that promise is a hole. You close the sprint. The job dies on Saturday. There are three people in the chat, none of whom built the piece.
What breaks the hours model
Hours measure activity. Live measures whether someone can use the thing on Monday, with their data, without you. Those two units do not convert. You can have "burned" a month and still have no environment that stays on. You can have burned little and have a tight perimeter that holds.
Agency throughput (many accounts, many juniors, a PM who translates) breaks at the point where you need a no. Scope walks, the PM nods, the junior implements the "also". The founder talks to a new person every two weeks. The memory of why lives in a Notion nobody opens.
One owner, here, means: one face on the perimeter, until the product is on or until a written handoff. Not an account manager who forwards. The person who said yes to the scope is the person who hears the phone when it comes out crooked.
Few projects is the consequence, not the branding. If you take too many, the owner becomes a dispatcher. At that point you have rebuilt the agency, with a drier tone.
I would rather leave a call on the table than open a fifth live to hold at night. The cost is obvious: less visible revenue. I take that. The alternative is fake ownership and dumping Saturday on someone who did not sign the scope.
There is a case where hours stand: a closed task, inside a product that already has an owner on your side. A queue, an export, a patch. That is not "build us the platform". It is an intervention. You call it an intervention.
An aside: I still have a board with twelve "urgent" tickets and zero line on who restarts the worker. The hours were reported. The worker was not.
Through to live, then (maybe) leave
Ownership through to live is not "forever". It is until the thing is on and someone, on one of the two sides, knows what to do. If you bring it in-house, you detach. Repo, environments, how you see it is broken, who had the keys. Without that, "we leave you the product" is a zip folder.
Handoff makes sense when there is a team that can receive it, not when the founder is tired of the call. If the team is not there, staying is an option; vanishing is not. The same filter runs the other way: if you only want hands and already have someone who answers, we are not the fit. You would be buying an owner you do not need.
On services this is the shape: one interlocutor, one perimeter, production. Not a roster. The ICP we care about is a founder who decides, often not technical on the operating piece, with a signal already there. Not "everyone", not "we start wide and then see who talks to the junior".
We also wrote why an MVP that stays in staging is not a test. Same reason: without someone on live, you are protecting an object, not holding a product.
The limit of this page: it is not an org chart, nor a defence of the "small studio" as a virtue. Small and disorganised is worse. Few is a cap, not an aesthetic.
If you only need hands and nobody who answers for live, look elsewhere. If you need one owner until the thing stays on, we talk on contact.
