12 months to rebuild 12 years

Groove took 12 years to build. Helply took 12 months.

That comparison is unfair in about six directions and I'm going to make it anyway, because the interesting part isn't the speed. It's what we didn't have to rebuild.

We started by not writing code

Before anyone touched a keyboard on the new product, I ran 50+ requirements calls with support teams. Not demos. Not discovery calls with a pitch bolted on the end. Just asking people to walk me through a Tuesday.

I own a help desk. I've owned one for 12 years. I assumed I already knew the answers, and the first 15 calls were mostly me finding out that I knew the 2014 version of the answers.

Three things came up so consistently they became the product:

The volume isn't the problem, the sameness is. Teams weren't drowning in hard tickets. They were drowning in the same 40 questions arriving in slightly different words, forever.

Nobody trusts the bot because nobody can see what it did. Every team that had tried an AI layer had a story about it confidently telling a customer something wrong, and the response was always to turn it down until it was useless.

The information needed to answer well is never in the help desk. It's in Stripe, in the product database, in a Slack thread, in someone's head.

None of those are features. All three are architectural, which is why bolting AI onto the old thing didn't work.

What carried over

Almost nothing in the codebase. Some infrastructure patterns, some hard-won knowledge about email deliverability and threading, which is a genuinely miserable problem that took us years to get right the first time and about 3 weeks the second.

What did carry over was 12 years of knowing what customers complain about. That's not code, but it's the reason we could skip a lot of the discovery a new entrant has to do. When a support team told me the thing that annoys them about their current tool, I usually already knew the ticket number.

Everything else went in the bin. The data model, the workflow engine, the permissions system, the reporting, the pricing logic, the entire UI. 12 years of work, and the honest accounting is that most of it was solving a problem that no longer exists in the same shape.

That's a strange thing to sit with. It's also just true.

The AI-assisted part

10 engineers, all of them using AI heavily to write code. That's the other reason 12 months was possible.

I want to be careful here because "we built it with AI" has become a way of saying "we didn't really build it." That's not what happened. The architecture decisions, the data model, the eval work, the thing that makes it actually correct rather than plausible: all human, all argued about at length, some of it multiple times.

What AI collapsed was the middle. The 3 days of plumbing between deciding what to build and having it work. Multiply that across 10 people for a year and you get the delta.

I'll write more about this separately because "is this vibe coding" is its own argument and it deserves more than a paragraph.

What 12 months actually looked like

Roughly: 2 months on the calls and the data model. 4 months building the ingestion and context layers, which is the part with nothing to show for it. 3 months on the agentic loop and the eval harness. 3 months making it not embarrassing to look at.

The 4 months with nothing to show for it were the hardest to hold the line on. There's constant pressure, mostly from yourself, to ship the demo-able thing. We'd already learned where that road goes.

We launched, and 8 months later it's at $1M arr growing 7% a month. Most of it from teams leaving platforms that are still shipping the retrofit.

The bill

12 months of 10 engineers, funded by Groove. 85% of R&D, 100% of marketing. Groove was flat at $5M arr for 3 years and that flatness turned out to be the most useful asset we had, because a flat profitable business is a very good way to fund a rebuild that has no revenue for a year.

I don't think we could have done this on a growing business. There would have been too much to protect.

The part I still don't have a clean answer on: 12 months was the right call for a product where the architecture was genuinely wrong. It is absolutely the wrong call for most companies, most of the time, and I've had 4 or 5 founders tell me since that they're thinking about doing the same thing to a business that doesn't need it. The rebuild is only justified if you can name the specific structural thing that can't be fixed with a feature. If you can't name it, you're just bored of your codebase.

I could name ours. Cost us a year to be sure.