Lab Notes · AI-Native Development

Eleven hours bought a working product.

Not "about a week of work." Eleven point one hours of human attention, measured from git history and session transcripts, timestamped to the millisecond.

I just shipped a product. Not a demo, not a prototype — a live, cloud-based product running on Cloudflare, with a marketing site, a free tier, and a Pro tier. And because every session was logged, I can tell you exactly what it cost me: 11.1 hours of my attention, spread over nine days.

That is not an estimate, and I want to be careful about the distinction. Afterwards I ran an audit against the actual record — 191 commits across two git repositories, 42 session transcripts, 24,218 logged events — and counted the time properly. What follows is that audit, with the method attached so you can decide whether you believe the number.

How it started

My co-founder Arnaud likes to send things — presentations, pricing calculators, little interactive tools he builds. He was sharing them as Claude artifacts, which works, but comes with real security and access trade-offs.

So I said: I can fix that.

The idea was simple. Drop a single HTML file, get a link. No account, no login for your recipient, nothing modified in your file. If you want more — swap the file without changing the link, see exactly who opened what — that's the $5 Pro tier.

Then, as these things go, we kept adding. Per-recipient tagged links. A private dashboard. Analytics that separate real readers from mail scanners. It turned into an actual product: veladrop.com.

The number that surprised me

I felt it hadn't taken long. I was still shocked when the audit came back.

Attention
11.1 h
Human composing time across nine days.
Commits
191
Across two repositories, 2–11 August.
Code
46,863
Lines, across 131 files.
Rate
3.5 min
Human attention per commit.

And here's the part that matters most: those eleven hours weren't a sprint. In between turns I was doing my actual job — client work, internal apps, analysing investment deals. This was built in the gaps.

What "eleven hours" actually counts

The unit is composing time: the interval between the assistant finishing its output and me sending the next message. That interval is where a person reads what came back, decides whether it is right, and says what happens next. It is the only stretch of the clock during which a human is unambiguously working.

Intervals longer than fifteen minutes are treated as me having walked away, and counted at a flat three minutes — so a lunch break doesn't inflate the total. There were 338 such turns, each with a timestamp to the millisecond.

You could count this three ways, and the three answers are very far apart:

Method Basis Total Per commit
Original estimate 191 commits × 1–3 min 3.2–9.6 h 1–3 min
Composing Measured gap before each human turn 11.1 h 3.5 min
At the keyboard Session wall-clock, 30-min idle split 40.1 h 12.6 min

The first undercounts, because commits are not turns. The third overcounts, because it bills me for time the machine was working alone. Composing time is the honest figure, and it is the one I quote.

What's interesting is why the original estimate was wrong. "A minute to three minutes of human effort per commit" was measuring something real — it was just attached to the wrong unit. There are 1.8 human turns per commit, and the median turn takes 61 seconds to compose. Multiply those together and the intuition lands almost exactly on the measured figure. The instinct was sound; the denominator wasn't.

Two very different kinds of work, one identical cost

Two repositories were built over those nine days: the Cloudflare Worker that serves Vela Drop, and the separate marketing site.

Measure Worker Website Combined
Commits 166 25 191
Files 114 17 131
Lines 41,233 5,630 46,863
Human turns 282 56 338
Turns per commit 1.70 2.24 1.77
Composing 9.6 h 1.5 h 11.1 h
Minutes per commit 3.47 3.70 3.50

Durable Objects on one side, marketing copy on the other. The human cost per commit is the same to within fourteen seconds.

That stability is the most useful thing in the whole audit. It suggests the per-commit cost is a property of the working method rather than of the material — which makes it a number I can actually plan the next project with, rather than a war story.

This was supervised, not delegated

The distribution of those 338 turns says more about the working method than the total does:

Gap before the human replied Share of turns What that is
Under 30 seconds 42% Watching output land and answering immediately.
30 seconds – 2 minutes 19% A quick read, then a correction or a next step.
2 – 15 minutes 23% Actually reading — the expensive turns.
Over 15 minutes 16% Away. Counted at a flat three minutes.

Four turns in ten arrive within thirty seconds. That is someone reading output as it lands, not a queue of instructions dropped off in the morning and collected at night. The eleven hours are eleven hours of supervision.

Nine days, in full

The work is heavily front-loaded. The stretch from 2 to 7 August carries 79% of the attention and 85% of the commits; the last four days are review and polish at roughly half an hour a day. The 3 August spike is the densest day in the record — 91 turns, nearly all of them on the Worker.

Day Worker Website Turns Composing
Sun 2 Aug 305391.72 h
Mon 3 Aug 213913.09 h
Tue 4 Aug 239280.64 h
Wed 5 Aug 140530.99 h
Thu 6 Aug 205391.39 h
Fri 7 Aug 302230.97 h
Sat 8 Aug 5190.50 h
Sun 9 Aug 5070.47 h
Mon 10 Aug 110320.79 h
Tue 11 Aug 70170.57 h
Total 1662533811.13 h

Commit counts are by repository. The same period measured as wall-clock at the keyboard comes to 40.11 hours — but that figure double-counts across the two repositories and bills me for time the machine was working alone, which is why composing time is the column that matters.

What the measurement misses

A number is only as good as its caveats, so here are mine.

The split between repositories is a heuristic. Both were edited from inside the same sessions, so each turn is assigned by whether its work referenced website paths. A turn that revised a pricing claim and its underlying entitlement together is counted once, not split.

Keyboard time overlaps. It apportions each session's wall-clock by its share of turns, so the same minute can appear against both repositories. Composing time is the sound figure; the 40.1 hours is context, not a total.

Thinking away from the machine is invisible. Design decisions made on a walk, or the reading behind a pricing page, leave no timestamp. This measures attention at the keyboard and nothing else.

One day nearly went missing. The 5 August work happened inside a git worktree with its own transcript directory, and was absent from the first pass. It's in the table above. Work in directories nobody thought to examine would be invisible in exactly the same way — which is a good reminder that "measured" and "complete" are different claims.

What it's not

It's not finished. Pro pricing still needs to be wired up, the marketing site could be sharper, and how-to videos are on the list. I'd rather be honest about that than pretend otherwise. Eleven hours bought a working product, not a polished company.

And the boundary conditions matter, the same way they did when I shipped a Mac app without opening Xcode. This was a greenfield problem, specified by the person building it, with no existing system to integrate against, no regulator to satisfy, and no consequences worse than a broken link. That is not the situation inside a bank's document pipeline. The gap between what this method does on a clean problem and what it must be constrained to do on a consequential one is precisely the layer we spend our days building at Vela.

Why I bothered to count

Because "it only took a week" is a story, and 3.5 minutes per commit is a planning input. One of those you can put in a budget.

The bottleneck in building software has moved. It's no longer typing — it's deciding: reading what came back, judging whether it's right, and saying what happens next. Forty-two per cent of my turns took less than thirty seconds, and that's the whole shape of it. Eleven hours of decisions bought a working product.

The full audit was published, fittingly, as a Vela Drop — a single HTML file behind a link, which is the entire point of the product it was measuring.

See what eleven hours built →

Vela Drop is a personal project by our CTO, published via Vela Labs. Figures in this article are drawn from 191 commits across two git repositories and 42 Claude Code session transcripts totalling 24,218 logged events, snapshotted on 11 August 2026 while the final session was still open. Vela Intelligence builds decision intelligence infrastructure for regulated, high-stakes environments. For strategic conversations, contact contact@velaintelligence.com.