The First 90 Days: Honest Numbers from Running on Our Own Platform

The actual numbers

Let us start with the numbers, because they are the point.

In the first 90 days of running Hivemeld on Hivemeld — using the platform to build and operate itself — we ran 13 agents across 6 active workspaces. Those agents completed 644 tasks. We shipped a QA gate, a goal-directed execution model, auto-split for over-budget tasks, an onboarding demo, and a billing system. We fixed dozens of bugs, wrote and rewrote the marketing site, and handled a complete ops reset.

Zero paying customers.

Both of those things are true, and neither one invalidates the other. What we learned in those 90 days is the subject of this post.

What the agents actually did

Of the 644 completed tasks, the split broke down roughly as follows: about 40% were engineering tasks — code changes, test runs, deploy preparation, dependency updates, QA cycles. About 30% were content and marketing — blog posts, site copy, social drafts, documentation. About 20% were operations — config management, monitoring checks, credential rotation, infrastructure bookkeeping. The remaining 10% were what you would call research and analysis — competitive scans, user interview synthesis, decision support.

The distribution surprised us. We expected engineering to dominate, because we thought of ourselves as building software. What the actual numbers revealed is that a substantial fraction of what it takes to operate a software company is not software — it is the surrounding work of communication, documentation, and administration. The agents handled that work, which meant we did not have to, which meant our human attention stayed concentrated on the decisions the agents could not make.

The 30% content and marketing share is particularly telling. Before agents, this work was either skipped (blog posts did not get written, documentation stayed stale) or it consumed founder time that should have been going to product. With agents, it happened on a schedule, at a consistent quality level, without requiring a context switch from whatever else was going on.

Where the agents fell short

The numbers make it sound cleaner than it was. Six hundred forty-four completed tasks means there were also tasks that got stuck, tasks that produced output that needed to be redone, tasks where the agent's interpretation of the goal was subtly wrong in ways that only became apparent downstream.

The most common failure mode was underspecified goals. An agent given a vague task produces vague output. "Improve the onboarding flow" sent to an agent without a clear picture of what better looks like generates changes that look plausible but do not actually address the problem. We learned to write goals with exit criteria — not "improve the onboarding flow" but "the onboarding flow should get a new user to their first running agent within 10 minutes, with no required support contact, as measured by the demo session timer."

The second failure mode was agent-to-agent handoffs that lost context. When an agent completed a task and filed the output for the next agent in the chain, important nuance sometimes did not survive the transition. The receiving agent worked from the filed output, not from the full context the sending agent had, and the gap produced downstream errors that were expensive to trace back to their source. We added explicit context-passing to handoff templates — the sending agent now writes a handoff note that captures what the receiving agent needs to know that is not in the raw output.

The third failure mode was our own review habits. Early on, we reviewed agent output too lightly — trusting that the task was done because the agent marked it done. Several cases taught us that "done" from the agent's perspective means "the specified task was completed," not "the outcome you wanted was achieved." Those are often the same thing. When they are not, the gap is usually in the task specification, but you do not discover that until you review the output carefully.

The zero customers problem

Six hundred forty-four tasks and no revenue is a specific kind of result. It means the operational machinery works but the growth machinery does not yet.

The diagnosis is straightforward: we built the platform before we built the funnel. We prioritized getting the agent system working — which required dogfooding — over getting potential customers through a sign-up experience that would actually convert them. The sign-up flow had bugs. The demo was not polished. The paywall was in the wrong place. Each of these is fixable, and we fixed them, but they were fixed in the second half of this period, not the first.

There is an argument that this sequencing was correct — you cannot dogfood a broken platform, and dogfooding a working one produces genuine product insights that would not exist otherwise. The QA gate exists in its current form because we used it on our own PRs and discovered three sharp edges. The goal-directed model was redesigned once because running it on a real goal exposed a flaw in the subgoal handoff. These improvements happened because we were users.

The counterargument is that zero customers at 90 days is information too, and it should have triggered an earlier pivot to growth. That is probably right. We tilted the balance too far toward product and not far enough toward distribution.

What changed in the last 30 days

The last 30 days of the 90-day window looked different from the first 60. We moved the paywall to after the onboarding demo, fixed the major sign-up friction points, hardened the billing integration, and activated a trial tier. Signups started coming in. Eleven so far, all on trial, none yet converted to paid.

Eleven signups is not validation. But it is signal: the funnel now converts at the top. The question we are now holding is whether it converts at the middle — whether a user who gets through the demo becomes a user who sees the value and pays for it.

The answer to that question will come from the next 90 days, not from reflection on the first ones.

What we would do differently

Three things, with the benefit of hindsight.

First: write better task specifications from day one. The cost of a vague spec is paid in rework, and rework is invisible in aggregate task counts. We would have done fewer tasks with better specs and gotten better outcomes from each one.

Second: build the sign-up and demo flows in the first 30 days, not the last 30. You cannot measure product quality without users, and you cannot get users without a functional onboarding path. These are preconditions, not nice-to-haves.

Third: treat the review habit as infrastructure. We would have built explicit review checkpoints into every significant agent chain — not because we did not trust the agents, but because the combination of agent execution and human judgment produces better outcomes than either alone. The agents are fast and tireless. The human review is where the judgment lives. Neither one is sufficient by itself.

The 90 days produced a working platform, real product insight, and zero revenue. That is an honest accounting. The next 90 will tell us whether the foundation we built is what we needed to build.