Why Your Startup Idea Is Now a Side Project?

We're not in a normal moment in software. The models keep getting better faster than we can adapt, and that creates a strange psychological effect. What used to be startup-sized problems are now side projects. What used to be side projects are now markdown files. And the gap between what's possible and what we're building keeps widening.

The Model Eras Matter

There's a temptation to treat all model upgrades the same. They're not. We can categorize them by what they fundamentally changed about what's possible.

Sonnet 3.5 was the tool call era. Not the first model to support tool calls, but the first you could actually use reliably for day-to-day coding work. Consistent. Predictable. You could point it at a codebase and get back code that worked.

Opus 4.5 changed something more fundamental. It was the long-running task era. A model that didn't need you to babysit it through each step. You could describe a multi-hour task and it would actually complete it, maintaining context and understanding throughout. It tested its own work. It kept itself on track.

Mythos represents orchestration. It's the first model that doesn't just understand your codebase. It understands itself. It knows how to spawn additional models and break up work in ways that allow verification and completion without custom tooling. You don't need some elaborate software factory. You need to prompt it correctly.

This progression matters because each era makes a category of problems trivial that used to demand attention.

The Uncomfortable Reckoning

Most work that qualified as startup-level complexity two years ago can now be solved by Opus 4.5 in an afternoon. The problems that needed Mythos didn't exist as problems before. This means the tier structure has collapsed.

What we would have called a startup in 2024 is a side project now. What was a side project is now something smaller. Below that there's a gap. A wide gap filled with one thing: the markdown file tier.

You can write a markdown file that describes a workflow, pipe it to Claude or Codeex, add a cron job, and replace an entire service you would have built a year ago. A real example: an automated PR triage system that reviews all open pull requests across multiple repos, determines status, prioritizes work, generates an HTML report, uploads it to S3, and emails you a link. That's a markdown file running every morning at 9 AM. Fifteen years ago this was a startup. Five years ago it was a product people charged for. Today it's a markdown file.

This isn't theoretical. Multiple companies at tech events right now have products that are essentially markdown files being executed by models. We haven't fully processed how insane that is.

What Broke Our Thinking

We're still designing software like it's 2015. The terminal is skeuomorphic now. We pretend Vim is essential because we're used to it. We can't commit environment files because Git wasn't built for that. We qualify ourselves by programming languages we know. None of these things matter the way they used to.

The reason we got away with this limitation before was friction. Finding engineers was hard. Building features was slow. The company couldn't argue when you said "this is just how we do it" because the alternative was six months of hiring. That scarcity is gone. The models don't care about your sunk cost. They don't care about your identity. They care about what works.

The Real Shift: Depth Over Breadth

Verscel doesn't try to be AWS. It goes deeper in the space it occupies. Full-stack, frontend-leaning infrastructure. They're so far ahead in their vertical that even the agents prefer them.

For the last decade, the startup playbook was: pick one vertical, go deep enough to survive, hope you don't need the rest. That worked because competing on breadth against established players was impossible.

That's no longer true. You can now build enough surface area to get users started in a day or two of work with good prompting. You can build a database platform into your product. You can cover enough ground that users can at least try the thing. When they need features you didn't build, if you architect correctly, they can build those features themselves.

This is what Slack accidentally figured out. Slack is a mediocre product. But it's the right shape. It's extensible. People run entire agent systems inside Slack now. The platform won because of its architecture, not its features.

The Uncomfortable Truth

The tier structure that made sense before is gone. The gap at the top is still unclear. Is it training models from scratch? Building operating systems? Competing with npm directly? I don't know. That uncertainty is exciting.

It means you're not limited to the tier you think you belong in. You're being told implicitly that it's time to compete with Slack. It's time to build your own infrastructure layer. It's time to challenge platforms you thought were untouchable.

The reason we don't do this isn't because it's too hard anymore. It's because we're still thinking in the old tiers. We're still protecting the code we wrote. We're still qualifying ourselves by the tools we know. We're still pretending that the shape of the work is the same.

It's not.