The initial commit was at 3:13 PM on a Wednesday. I was at work — full time on clove, my day job. Version 0.1.0 landed on npm at 3:46 PM. Thirty-three minutes from empty directory to published package, slotted between meetings and pull requests on the main codebase.

Then I spent the next two hours shipping eight patch releases because the code was broken in every runtime I actually cared about. All of it happened in background Claude Code sessions while I kept working on clove in the foreground.

That's the part nobody talks about with vibecoding. It's not just that Claude writes fast — it's that the work happens in parallel with your actual job. I'd kick off a fix from my phone, review the diff ten minutes later, publish, and go back to clove. An entire npm package shipped across 21 days without taking a single full day off the main work.

Why I stopped reaching for PostHog

Every project I've shipped in the last few years started with the same ritual: set up PostHog or Segment, wire up a dozen events, deploy, then never open the dashboard. The data sat there. Nobody queried it. When I finally did need an answer — "how many people signed up last week?" — I'd spend ten minutes remembering where the funnel lived and another ten wrestling with the date picker.

PostHog and Segment cost $120–450+/mo once you pass the free tier. Amplitude is worse. The cost isn't just money; it's the entire category of "analytics dashboard you maintain but don't use."

The thing I actually do when I need an answer is ask Claude. "Show me last week's signups." "How many Pro conversions since Tuesday?" Claude can query BigQuery directly. It already does for my other projects. So the question became: why am I piping events to a dashboard I never open when I could pipe them to a warehouse Claude already talks to?

bq-analytics sends events to BigQuery. That's it. No dashboard, because the dashboard is BigQuery itself — queryable by CLI, notebooks, or Claude. At 5M events/month the storage and query cost is roughly $0.40. Not $400. Forty cents.

The fix cycle

The first publish was triumphant for about fifteen minutes. Then I tried to use it in a React Native app and everything fell apart. APIs that don't exist in Hermes, imports that choke the bundler, serverless functions freezing before the event queue flushes. Twenty-eight commits in three hours. Ten releases before dinner.

That's what vibecoding actually looks like. The code was wrong eight times and right by dinner. Each fix was five minutes — paste the error, get a patch, publish, hit the next bug. The cost of each wrong was a patch version and two minutes.

The pattern repeated throughout. One afternoon I shipped six versions in a row trying to make Expo OTA updates feel invisible — silent reload, then fixing the white flash, then fixing the lost analytics events, then adding an auto-reload timer. Each version revealed the next problem. None of them were predictable from the armchair. You ship it to a phone, watch it behave, and react.

The side project is a background thread now

The final numbers: 72 commits, 22 releases, 21 calendar days, 10 active coding days. Thirty-nine source files, roughly 4,140 lines of TypeScript, 92 unit tests, 16 export paths.

I never sat down and said "today I'm building bq-analytics." I was always working on clove. bq-analytics happened in the cracks — a background agent here, a phone review there, a patch published between standups. Ten active coding days spread across three weeks of full-time work on something else.

That's the thing about vibecoding that the discourse misses. People argue about whether AI-generated code is good enough. It's the wrong question. The code was wrong eight times on Day 1 alone. What changed is the cost of iteration — and the fact that iteration no longer needs your full attention. A side project used to mean nights and weekends. Now it's a background thread that runs while you do your actual job.