There's a specific kind of irony in building a tool whose entire job is to tell founders the hard truth about their ideas.
The irony is this: it will also tell you the hard truth about yours.
I designed krucbl to run startup ideas through a fixed framework I affectionately call The Fourteen: 14 structured pressures that map every failure mode before you've committed six months of your life emotionally, financially, and physically. But I should tell you: I built this initially as really ugly code, just for me. The first version was the Seven. Then I added a couple more and it became the Nine. I think I stopped naming it at that point for a while. We ended up calling it The Fourteen somewhere around the seventh month of building the final product.
Here's what I need to be clear on before we go any further: I built this for me first. Not for you, not for anybody else. And I think that matters, because a lot of the time the best ideas are the ones that fix a problem for you first. It's after a while of living with that messy code or messy formula that you get to the point where you realise: if this helps me, it could help others. That right there was my A-HA moment that became krucbl.co.
14 structured pressures that map every failure mode before you've committed time, money, and emotional effort. The pitch is simple. It doesn't flatter. It doesn't score. It doesn't give you a number from one to a hundred. I don't think any of that helps. It finds the thing that will quietly kill you and names it. And then, because I'm an eternal optimist, it gives you a way out or a different direction. If it's a genuinely strong idea, it tells you what can kill it and helps you avoid those things.
What I didn't see coming was that building it would do exactly that to me.
Let's go back to why I initially built the grubby code that was my Six, then my Seven, then my Nine, and whatever that became before it was krucbl. All of this happened around the time I'd started teaching myself how to code. A large portion of that was building tools that became things other people now use day to day. Like krucbl.
The first painful lesson I learned while working out the initial code and the inspiration for it was this: the people closest to you are the most dangerous advisors you have. Not because they're wrong. Because they care about you. And caring about you means they're optimising for your confidence, not your clarity.
The second-best example of this is a friend you feel you've got on your computer or your phone, something we now call Claude or ChatGPT or DeepSeek or whatever. It's exactly the same. They enable you; they do not educate you. They will lead you down a garden path. Beware that path.
Luckily for me, I do have a few friends who care about me enough to tell me exactly what they think. That's what a good friend should do, by the way. Tell you what they really think.
A trusted friend of mine, one of my oldest friends, actually the person who gave me my first-ever coffee boy job in a recording studio, Troy Hazard, gave me a piece of advice early on that sent me initially chasing a different user entirely. A more sophisticated one. A more funded one. Someone further along with a lot more to lose.
It took me longer than I want to admit to realise I'd left my actual user behind. The founder at the kitchen table at midnight who just needs someone to tell them the truth before they quit their job. That person doesn't need me to chase the other one.
Now, initially that side quest was not on Troy. His advice was very solid. What it came down to was one important thing that added an awful lot to the power of krucbl: context. Enabling a user to give context during onboarding.
- Who are you?
- What do you do?
- What are you good at?
- What kind of things do you build?
- What kind of help are you after?
- Are you a builder?
- Are you looking for career advice?
- Are you an investor?
- What level, financially, are you working at?
All of those questions and more are in the onboarding because of Troy's initial advice, which essentially came down to that one word: context.
There's a lesson in The Fourteen called Dead End Detector. It's about mistaking a shiny detour for progress. I managed to walk straight into it while building the tool that's supposed to catch it. Irony much, anybody?
Trusted advisors and really good friends and family can send you on side quests. Filter everything through a couple of questions you keep right at the top of your mind:
- Is this relevant to my actual user?
- Does this help my user have a better outcome?
The second thing I learned is that your tools will flatter you, and flattery is expensive.
The tools I use to code vary depending on which machine I'm on. My MacBook Air, my PC with a ridiculous amount of GPU and RAM and hard drive space, or my MacBook Pro. They all have different things on them. But one thing they all have in common is Cursor, which is an AI-assisted IDE. Put simply: you can build software, websites, and code inside it.
One of the things I've done while building is create what we generally call AI agents, but personalised ones. I've built a debug agent designed around the way I work and my expectations. A QA agent that operates the same way. A general analysis agent that looks through code and tells me things I want to know in the way I want to know them.
A lot of this connects to what I wrote in my article about learning to code at 54: always ask for a 101 explanation and context. My ask agent in Cursor is built specifically for that. If I say "tell me about this" or "tell me about that," it gives me a plain-English explanation combined with direct context to the project I'm working in. That single thing changed how fast I could move. But it took me a long time before I wrote that agent. Until then I was relying on built-in defaults that assumed experience I didn't have.
Here's what Cursor will absolutely do: fix your error. Cheerfully, enthusiastically, immediately. And sometimes it fixes it in a way that adds logic you never asked for. Don't be deceived by that. Those additions become what I call patches from hell.
A line I've typed into a Cursor prompt more times than I can count is some version of this: Stop patching. Take a few steps back, look at the problem, look at the end result I expect from this code, and work out how to build it properly. Then remove the last five patches you added.
Because here's the thing: Cursor is optimising to make the code work. To give you a clean build in its own terms. That has nothing to do with giving your user the outcome your product is actually supposed to deliver. A clean build and a good product are not the same thing, and an AI agent cannot tell the difference between them.
A good example of this: I had a retry mechanism added to my analysis engine that silently fell back to a lower-quality result whenever a web search failed. Web searches inside krucbl are a significant part of what makes The Fourteen powerful: the competitive analysis, the market timing, all of it pulls from live data at the moment your report generates. That's not a detail; that's a core promise.
So when the search failed, the report still generated. From the outside, everything looked fine. From the inside, users were getting a worse report. Neither of us knew it. Thank you, Cursor, for that fix I didn't ask for.
The lesson isn't that the tools are bad. It's that the moment you feel most confident a tool is working is exactly the moment you need to be reading what it's actually doing. Audit everything, especially when it looks fine. And when you do audit, go through it like a user who has never seen it before. Because that's who's going to find the thing you missed.
The third thing is about the details you decide don't matter yet.
There was a naming issue baked into krucbl from early on. The framework was marketed as The Thirteen in one context and referenced as The Fourteen in another. I knew about it. I had a rationale for it. I'd convinced myself it was intentional positioning.
It wasn't. It was a small confusion sitting in the product's foundation, waiting. Every piece of copy, every sample report, every place the framework was named, all of it carried a quiet inconsistency that no individual user would necessarily catch, but that collectively made the product feel slightly off in a way nobody could point to.
I fixed it. Replaced every instance. It was a copy change, not a code change, and it took an afternoon.
But here's the real lesson: I'd been protecting the wrong thing. The rationale I'd built for the inconsistency was a story I told myself to avoid the friction of fixing it.
The details you wave past now will demand more of you later. Usually at the worst possible time.
The fourth thing is harder to say without sounding like I should have known better. I did know better. I did it anyway.
There's a live bug in krucbl where if a report fails during generation, the user's credit is not automatically refunded. They paid. They got nothing. And for a window of time, the error message they saw was so generic it looked like a network hiccup, which meant some of them tried again, got charged again, and the second attempt also failed.
I knew this was a problem. I'd flagged it. But it was irritatingly hard to fix, and other things kept feeling more urgent, so I kept putting it off.
If that bug had gone live with paying customers, it would have been an unmitigated disaster for the user experience. One of the most important people you'll ever need to impress are your first initial paying customers. Bad experience on the first take? They won't come back.
So let me be direct with you: there is no feature on your roadmap more urgent than the thing that takes money from someone and gives them nothing in return. Not the new report type. Not the glossy marketing page. Not the email funnel. Stop it. Don't be a dick. Fix the thing that takes money off people and gives them nothing. That bug was awful. I fixed it.
The lesson is this: the business you're building is made of the trust people extend when they hand you their credit card details. Treat that accordingly.
The thing that surprised me most, though, was that I didn't discover what krucbl was really for by thinking about it. I discovered it by watching who used it and what they did with the output.
The users who got the most from it weren't the ones with the most brilliant, detailed ideas. They were the ones at the earliest stage. Pre-build. Pre-commitment. People who had an idea and a feeling of unease and no useful place to take either of those things.
Take that same idea to ChatGPT and it'll tell you: "Wow, this is a great idea. Just go ahead and build it." It will also tell you that after you've emptied your bank account. Yeah, sorry, that was a bad decision of mine. I won't do that again. Sorry, that doesn't really help you now, does it?
A friend of mine who's very deep in the funded world described it this way: "krucbl's sweet spot is helping founders develop ideas before they reach the sophistication of already-funded deals."
That sentence rearranged something for me. I'd been thinking about the product as a pressure test for ideas that were nearly ready. It turned out to be more useful as a pressure test for ideas that aren't ready yet, and need someone to say so clearly, without softening the blow.
It also showed me something I hadn't expected: how useful krucbl is for people who aren't building a thing at all, but are just trying to work out what to do next. A few of my initial users threw their CV and career questions into it. The reports it generated for them, and the feedback they gave me about those reports, were outstanding. I've seen some of them myself. I was genuinely impressed.
krucbl told me what it was. I just had to listen harder.
None of these lessons are unique to building krucbl. Talk to any founder who's been honest about it and you'll hear versions of all of them.
What is unusual is building a tool specifically designed to surface these failure modes and then experiencing most of them personally in the process. That's not a failure, by the way. That's the deal: you learn by doing the thing, and the thing teaches you, and you ship the next version with those lessons baked in.
Here's something that was genuinely hard for me to sit with: I put the overview of what krucbl was and what it did into krucbl itself, and asked it what it thought. The outcome was positive. But a lot of the things you'll find in krucbl today weren't there initially. They were there because krucbl did its job on its own DNA and helped me sharpen the edges.
I'm still learning. The product is still becoming what it is. But I'd rather be the person building the thing imperfectly than the person waiting until they understand it completely.
Those people are still waiting. And they haven't built a thing.
Much love, be good to yourselves and each other.
Michael Pearson-Adams michaelpa.com
krucbl is at krucbl.co. If you've got an idea you're not sure about, that's exactly what it's for. And if you want to read about why I started building in the first place, that story is here.
— Michael
More writing →