It took me 3 months to build HewnTree

There’s a genre of post I’ve started to resent a little. Someone vibe-codes a SaaS over a weekend, posts the screen recording, the first comment is a link to their paid guide and the rest of the comments fill up with people asking for the prompt. I get the appeal. I also know it’s mostly not true, or true the way “I made dinner” is true when you ordered the pizza.

HewnTree took me about three months. Evenings and weekends, around a full-time job as a product owner. And I’m not a developer.

That last part is the one worth talking about, because it’s the part that actually made it work.

HewnTree is a tool that helps you define an idea before you build it. You describe the rough thing you have in mind, it asks you targeted questions in batches, and your answers turn into a structured requirements tree, scored by how complete each part is. The point is to get from “I have an idea” to “here’s exactly what it needs to be” without the usual days or weeks or months of going in circles. I built it because I kept watching ideas die in that gap, including my own. I also had many moments when I thought to myself “If I had only thought about this sooner”. HewnTree addresses exactly that.

This article is about what those three months actually looked like, because I wish someone had shown me the unglamorous version before I started.

The easy part really is easy now

I’ll give the weekend crowd this much. Building is genuinely faster than it has ever been. I used AI to write most of the code, the same way I did for the small iOS apps I made before this. You describe what you want, it produces something close, you correct it, you move on. For a product person who knows what they want but couldn’t write it from scratch, that’s a philosopher’s stone.

So if the question is “can AI write the code,” the answer is yes, and it’s not even close anymore.

The problem is that writing the code was maybe a third of the work. Possibly less.

What actually took the time

The first thing that ate weeks was the spec. Before HewnTree could ask anyone else clarifying questions, I had to answer dozens of my own. What happens when the AI returns something malformed? What does the tree do when two requirements contradict each other? What does a user see when they hit a limit? Every one of those is a decision, and AI doesn’t make decisions for you. It implements the ones you’ve already made. Skip the deciding and it will happily build you a confident, coherent version of the wrong thing.

The second thing was everything that has nothing to do with features. HewnTree takes free-text input and feeds it to a language model, which means every input box is an attack surface. So before any “real” feature existed, the first thing I built was a safety gate that every input passes through, checking for injection and abuse, on its own budget so it can’t get starved by the heavier work. Then auth, with rate limits designed for the attacker, not the honest user. Then a spend cap on the AI, because an unlucky retry loop or a bad actor can turn a hobby project into a four-figure bill overnight.

The third thing was tests. I ended up with over 500 automated tests across 76 files before I’d finished all of the features. That sounds excessive for a solo project. It caught a security gap that was protecting rows of data but not columns, which I would never have found by clicking around. For someone who isn’t a developer, the test suite was the thing that let me change code without being afraid of it.

None of that shows up in a screen recording. All of it is the difference between a demo and something you’d let a stranger sign up for.

Why being a PO mattered more than knowing how to code

Here’s the part I didn’t expect. The skill that carried this project was the thing I do at my day job.

AI follows your specification almost literally. If the spec is clear, the code is good. If the spec is vague or contradictory, you get fluent, plausible code that does the wrong thing, which is worse than code that obviously breaks, because at least broken code announces itself. Writing for AI turned out to be the same muscle as writing a good requirement for a dev team. Name the goal, the acceptance criteria, the happy path, the failure path, what you explicitly do not want. The clearer I was, the less time I lost.

That’s a product owner’s entire job. Turning a fuzzy want into something precise enough that someone, or something, can build it without guessing.

The irony wasn’t lost on me. I was using a tool and a method that mostly only works well if you can define what you want clearly, to build a tool that helps people define what they want clearly. At some point I started running HewnTree’s own questions on HewnTree, and they found gaps in my thinking I’d been carrying for weeks.

So when people ask whether you need to be technical to build with AI now, I think it’s the wrong question. You need to be able to think in requirements. The code is increasingly handled. The deciding is not.

A rough timeline, since that’s usually what people want

For context, here’s how the three months actually broke down. None of it was full days. It was a couple of hours after work and longer stretches on weekends. Of course, sprinkled with late nights here and there.

The first few weeks were almost entirely spec and architecture. What the layers of the AI pipeline were, what each one was allowed to do, how they checked each other’s work. Very little of this was visible, which made it the hardest part to stay motivated through.

The middle stretch was the build proper. The question batches, the tree, the scoring, the editing. This is the part that felt fast, because it’s the part where things appear on screen. It’s also the part the weekend videos show, which is why they feel faster than reality.

The last stretch was the unglamorous tail that nobody films. Account deletion that actually respects a grace period. Cookie consent that isn’t a dark pattern. Stripping personal data out of my own error logs. Getting a staging environment in place so my tests couldn’t wreck real accounts. Writing policies and terms that feel tailored for an actual human to read and understand. Each of these was small. Together they were most of the second half.

Then a closed beta, capped at 25 users, on purpose, so I could actually respond to every bug instead of drowning. Which is roughly where things are now.

What I’d tell someone about to do the same

Where has this all led up to? A lot of experience on managing deploys, figuring out test suites and scenarios. A boatload of realization about how much work is actually needed to make something usable. I knew from the iOS app that this was the case, but jumping from a simple app to a simple website was an exponential learning and effort curve. I can only imagine what means a more complicated product implies. But there are good things. As an example, I can share the below things I would have appreciated soo darn much if someone would’ve told me early on:

1. Requirements to Specs to Product. The hours I spent turning a vague want into clear requirements, and requirements into real specs, before writing a line of code were the highest-leverage hours of the whole project. Every decision I skipped came back later, more expensive, usually at a worse time. In the future I will define requirements and specs as close to exhaustive as I can.

2. AI compresses building, not responsibility. It writes the code. It doesn’t know what the code should do, whether it’s secure, or whether you should ship it. It doesn’t care, and it shouldn’t. That part is still yours, and pretending otherwise is how people put insecure products on the internet.

3. The boring half is the real half. Security, tests, deletion flows, limits, consent. None of it demos well. All of it is what separates something you built from something people can trust. If you only budget time for the features, you’ve budgeted for about half the work. Budgeting time for the product means the boring parts as well.

4. Clear thinking beats fast typing. The bottleneck was always the same: how clearly could I define what I wanted. That’s good news, because the skill that matters is learnable and has nothing to do with syntax, code, architecture, or anything complicated. Being clear, including saying plainly what you don’t know, is what builds the context the AI needs.

The bottom line is that I’m still learning, and I want to. I’d rather understand what I’m shipping than move fast on top of things I don’t. That’s a slower way to build, and for now it’s the only way I’m interested in.

Three months of evenings, weekends, and late nights for a tool that helps people fast track the part I clearly couldn’t myself. There’s probably something in that.