The three forks before Foundry, and why a launcher won

Vamshi Krishna V.

Patient work, woven in public.

This is Thread 03 of Loomwork. Previous threads — Thread 01 (why this newsletter exists) and Thread 02 (the 40-tool problem) — set up the context for this one.

Before I landed on a launcher, I considered three other shapes for the same problem. Two of them were real enough that I wrote scoping docs. One of them I almost started before I caught myself.

Here's each, what made it tempting, and the specific reason I went a different way. None of these stories ends with "I was right." They end with "I made a sequencing decision under uncertainty, and time will tell."

Fork one — an AI builder kit.

The shape: a curated set of starter templates for indie builders making AI products. Reference architectures for Claude and OpenAI integration. Boilerplate for Supabase + Clerk + Vercel. Packaged prompts you could clone and adapt. The premise was that indie builders shouldn't have to reinvent the AI stack on every new project — and at the time, the official cookbooks were thin and scattered.

What killed it wasn't the idea. It was the timing. By the time I'd scoped it, the major platform vendors were already shipping their own AI starter kits, and the open-source ecosystem had filled in around them. The differentiation a one-person shop could offer would have to come from taste or teaching — neither of which scales as a product. Both scale as a newsletter, ironically. Which is roughly what I'm doing now.

Considered. Decided against. No code written.

Fork two — a thin layer of agents over the stack.

The shape: specialist agents watching the tools you already pay for. One agent on your code. One on your payments. One on your deploys. A master agent synthesizing their findings into a morning briefing — here's what changed overnight, here's what needs your attention, here's what doesn't. Your stack, watched continuously, distilled.

I scoped this one carefully — architecture, phasing, the rough cost shape. It's good.

The reason it isn't shipping yet isn't that it's wrong — it's that it's premature. Most people don't know they want an agent platform until they've felt the cost of not having one. The pain has to land before the fix can sell. And building an agent platform whose audience doesn't yet feel the pain is how you ship something brilliant that nobody installs.

So I deferred. The launcher comes first — it's what people will use today. The agent layer comes after, by which point the audience has felt the cost of running their stack manually, and the agents will land on prepared ground. Same vision, different sequence.

(If you're wondering: yes, this is on the Foundry roadmap. Ask me again when the launcher's earned an audience.)

Deferred. Not killed.

Fork three — a multi-tenant solo-founder OS.

The shape: Foundry, but bigger from day one. Multi-tenant accounts. Pricing tiers. A marketing site. Onboarding flows. Payments. The full "operating system for solo founders" pitch.

This is the one I was closest to starting. I had product positioning written out. I had a defensible pricing structure mapped. I was a few decisions away from beginning.

What stopped me was looking carefully at the room I was about to walk into. Several VC-backed plays in adjacent territory had taken serious funding and stalled, pivoted, or quietly sunset. The space wasn't underserved — it was overserved by attempts that hadn't survived contact with the market. Trying to compete with venture-funded plays as a side-project builder isn't strategy. It's ambition without strategy. Different thing.

So I stripped it back. To the smallest piece that solved the actual pain I had. Which turned out to be a launcher. With a coverage map.

Cut. Entirely.

So why a launcher, of all things?

Three other shapes were sitting on the table, all bigger, all more obviously impressive. The launcher is — by design — the least impressive of the four.

That's exactly why it's the one that shipped.

A launcher is something I open many times a day. I used the first working version within hours of finishing it. Within a week I'd stopped reaching for my browser bookmarks, and started noticing tools that weren't in the catalog yet — which told me what to build next.

The other three forks would have taken six months to find out whether anyone wanted them. The launcher told me within a week.

Fork two isn't dead. It's gated behind fork four shipping first.

There's also the matter of what was honest to ship. I work a day job. I have ten or fifteen hours a week to build, in stretches that get interrupted by life. A launcher is something I could ship to a working state in that budget. A multi-tenant OS or an agent platform isn't. The constraint chose the shape — but only because I let it. The same constraint, ignored, would have produced six months of half-built ambition and nothing live.

The other thing the launcher did, which I didn't fully appreciate at the time: it created the surface area I'll need later. The catalog, the department taxonomy, the coverage map — these aren't just V1 features. They're the data layer the agent platform sits on top of. Fork two isn't dead. It's gated behind fork four shipping first.

The lesson, if there is one: a tool you'll actually use beats a tool you can imagine others using. Foundry survived the early forks because I wanted to use it Monday morning, not because I had a market for it. The other three were all shaped around hypothetical users I hadn't met yet.

Which is the kind of mistake that's easy to see in someone else's product and hard to see in your own.

Next Sunday: Open it. Here's what's actually live. I'll walk you through the real product as it exists today — what's there, what's deliberately missing, what's broken, what to click. There's a real URL. You can see for yourself.

See you then.

— Vamshi

Loomwork is by Vamshi Krishna Veggalam. Building Foundry at mindloomhq.com, with the full archive at loomwork.dev. Find me on LinkedIn.