2
1 Comment

I accidentally built what the majors spent millions to figure out. Here's how it happened.

In early 2025 I started vibe coding before the tools were anywhere near where they are today. No Claude Code yet. Just Claude desktop and Cursor, and a project I was determined to ship... a tool that would automatically pull applicants from LinkedIn easy-apply jobs, evaluate them against a job description using AI, and surface the best candidates.
I got it built. But the integration was a nightmare.

Here's what I learned the hard way: when you're building complex software with AI, if you don't define your contracts upfront, you end up with a pile of individually working pieces that don't talk to each other. The agents build in isolation. Nothing fits. I burned weeks figuring that out.

The context window problem forced my hand

Early Claude desktop had very short context windows. A single agent simply couldn't hold enough context to build anything serious. So I did what made sense at the time... I ran multiple Claude desktop chats in parallel, each working on a different piece of the project simultaneously.
And that's when I discovered both problems at the same time.

Single agents run out of context faster than you think. And multi-agents, left to their own devices, produce pieces of code that don't fit together. I hadn't solved the problem by going multi-agent. I'd just traded one failure mode for another.

The second project: going manic on contracts

I started my next project, an RFP proposal evaluation tool for enterprise, and this time I was obsessive about it. Full specification upfront. Contracts defined before a single line of code got written. The whole thing mapped out before any agent touched it.
It worked better. Significantly better. But it still took months... and I was still doing all the specification and contract work manually.
Somewhere around month two I had the realization that would change everything. The real unlock wasn't just doing contracts first. It was automating the entire process of getting there.

The third project: GoBananas.dev

I started fresh. This time I designed the architecture from day one as a multi-agent, contract-first platform. The idea was simple but the implications were significant... agents would create contracts before they wrote code, so every agent working in parallel would know exactly what every other agent was building. No misfits. No context loss.
I got 98% of the way there with my own orchestration architecture. Then Anthropic dropped the Claude SDK.

I looked at it and realized... they had arrived at the exact same place I had. Independently. From a completely different direction. I gutted my own system and rebuilt the orchestration layer on top of theirs.
That convergence was the validation I didn't know I was looking for.

What GoBananas actually does

When you chat with GoBananas it doesn't start building immediately. It creates a full specification document that you review and approve first. Then agents create contracts before they build. Every agent working in parallel knows the full shape of what's being built before it writes a single line.
All the speed advantages of multi-agent architecture. None of the chaos.

The lesson

Looking back there are three things I'd tell anyone building right now...

First, if you keep hitting the same wall, stop and ask yourself if there's a business in systematically solving that problem for others. The wall I kept hitting became GoBananas.

Second, don't be afraid to pivot no matter how far down the rabbit hole you've gone. I gutted a near-complete architecture because something better came along. That decision probably saved the whole project.

Third... and this one is critical in AI right now... don't get so heads down that you miss what's dropping around you. The tools are moving fast. The ones that didn't exist when you started your project might be exactly what you need to finish it.

I'm not sure whether to feel vindicated or humbled by how close my architecture was to what Anthropic built. Probably both.

on February 20, 2026
  1. 1

    the contracts-first thing is something i wish someone had told me earlier... i made exactly that mistake. built pieces that worked individually and then spent way more time than i want to admit trying to make them talk to each other
    the bit about 'if you keep hitting the same wall, ask if there's a business in solving it' is what got me. that's literally how frikt started. i kept seeing good ideas die in conversation and thought... wait, that's the product
    also respect for gutting your own architecture when something better came along. that takes more confidence than most people have mid-project

Trending on Indie Hackers
Why Indie Founders Fail: The Uncomfortable Truths Beyond "Build in Public" User Avatar 114 comments I built a tool that turns CSV exports into shareable dashboards User Avatar 92 comments $0 to $10K MRR in 12 Months: 3 Things That Actually Moved the Needle for My Design Agency User Avatar 72 comments The “Open → Do → Close” rule changed how I build tools User Avatar 63 comments I got tired of "opaque" flight pricing →built anonymous group demand →1,000+ users User Avatar 43 comments A tweet about my AI dev tool hit 250K views. I didn't even have a product yet. User Avatar 42 comments