Fabricio Richieri

I build the version after the vibe-coded version. Co-founder @dynasty_devs

[Fabricio Richieri @iamrichieri]

Most founders build twice.

Once with AI tools to validate.
Once when they realize it doesn't scale.

We build the version that skips step two.

https://t.co/d3X888eMLj

#buildinpublic #founder #startups

[Fabricio Richieri @iamrichieri]

@extraordinary @evilrabbit_ @rauchg Crack

[Fabricio Richieri @iamrichieri]

@JohnnyNel_ Yes!

[Fabricio Richieri @iamrichieri]

Claude Max > 5 Cursor Ultra Plans

Last month I was paying for five Cursor Ultra accounts. Five. Every time one hit the usage cap I'd spin up another one to avoid the overages, which are brutal.

Then I switched to Claude Max with Claude Code and realized I was getting more tokens, better context handling, and none of the account juggling. All from the same model Cursor was reselling me at 5x the cost.

Cursor is a wrapper around Claude. A good one, the editor integration is nice, the autocomplete works. But when you strip that away and look at what you're actually paying for, the math stops making sense fast.

If you're hitting usage caps regularly, you're paying a premium for a UI layer. At some point it's worth asking whether you actually need that layer or if you just got used to it.

[Fabricio Richieri @iamrichieri]

AI can build your app. It can't tell you that your app shouldn't exist.

That's not a limitation of the technology. It's a limitation of what building tools are designed to do. You prompt, they produce. Ask for a dashboard, you get a dashboard. Ask for a social feature, you get a social feature. At no point does the tool stop and say "your user doesn't need this" or "this solves a problem nobody has."

And that's fine, that's what tools do. The problem is when the builder treats that loop as product development. Prompt, get output, ship. Prompt, get output, ship. You end up with apps that are technically functional and strategically empty. Every screen works, no one knows why they're there.

The decisions that actually determine whether a product survives are all decisions AI can't make for you. Which features to kill before you build them. Whether your onboarding makes sense to someone who has no idea what your product does and found it through an ad at midnight. What your pricing says about who you're for and who you're not for. Whether the problem you're solving is real or just feels real to you because you've been staring at it for three months.

These aren't technical questions. They're product questions, user questions, business questions. They require saying no, and AI doesn't say no. It doesn't push back on your assumptions. It doesn't tell you your target audience wouldn't pay for this. It doesn't know that your competitor already tried this exact approach and failed. It just builds whatever you ask for, faster than ever.

That speed is genuinely powerful when you know what you're doing. When you have a clear thesis about your user, when you've validated the problem, when you understand the tradeoffs of every integration and every screen you're adding. AI as an accelerator for good product thinking is a real unlock.

But AI as a replacement for product thinking is how you build something fast that nobody wants. And right now, the gap between builders who understand that distinction and builders who don't is getting wider every week.

The most important skill in building product today isn't knowing how to use AI tools. It's knowing when to ignore what they give you.

[Fabricio Richieri @iamrichieri]

Everyone can build a prototype now.

Pick any AI tool, describe what you want, and in a few hours you have something that looks like a real product. That part is solved.

But here's what hasn't changed: building something that actually handles hundreds or thousands of real users is a completely different problem.

A prototype doesn't need to worry about what happens when two users hit the same endpoint at the same time. It doesn't need Stripe webhooks that confirm payments and handle failures gracefully. It doesn't need background jobs that retry, email flows that actually trigger, or a database that won't choke when your data grows 10x in a month.

A real product does.

Security, auth, rate limiting, error handling, monitoring, API integrations that don't break when the third-party service changes something on their end. None of it shows up in a demo. But all of it determines whether your product survives contact with real users who are paying real money.

The barrier to creating something that looks like a product has never been lower. The barrier to creating something that works like one hasn't moved.

That's the gap we close at Dynasty. We take what founders have already built and make it production-ready in 30 days.

[Fabricio Richieri @iamrichieri]

@alexcooldev And knowing what to build

[Fabricio Richieri @iamrichieri]

When everyone has access to the same tools, the advantage stops being technical.

That's what's happening with AI right now. Any founder can open Lovable, Cursor, or Claude and have a working prototype in 48 hours. The technical barrier to entry basically disappeared. And that's exactly why the game changed.

There's a concept in game theory called Nash equilibrium: when all players have the same information and the same tools, nobody wins just by having access to something the other person doesn't. The advantage shifts elsewhere.

In this case it shifts to judgment. To knowing what to build before everyone else, not how to build it. To understanding which problem is worth solving and when a prototype is enough to validate, and when it isn't.

The technical founder who spends three weeks perfecting the architecture loses to the business founder who already validated, iterated, and has real users. Not because technical quality doesn't matter, but because at this stage the scarce resource isn't code, it's decision-making.

AI leveled the technical playing field. What it didn't level is the ability to make better decisions than everyone else, faster.

That part is still yours.

[Fabricio Richieri @iamrichieri]

Claude Code is probably the most capable development tool available right now. It's also one of the easiest to misuse, and most of the takes I've seen online miss exactly why.

The praise is mostly right. It picks up an existing codebase, understands context across files, and can make complex changes without you explaining every dependency. For a developer who knows what they're asking for, that's a real multiplier. Work that used to take half a day takes an hour. Boilerplate that nobody wants to write gets done in minutes. It's genuinely good at the parts of development that are repetitive and well-defined.

The part that doesn't get talked about enough is what happens when the task isn't well-defined. Claude Code doesn't know what it doesn't know. It generates code that compiles, that passes tests if you have them, and that does what you asked. But "what you asked" and "what your system actually needs" are often two different things, and that gap is architecture. No AI tool closes that gap yet, because closing it requires understanding the full product, the business logic behind it, and the edge cases that haven't happened yet.

Where it breaks down in practice is usually one of three places: database decisions that made sense for a feature but created problems at scale, auth logic that worked in testing but had holes in production, or integrations that handled the happy path but nothing else. These aren't bugs Claude Code introduced. They're decisions nobody caught because the tool is optimizing for making the code work, not for making the product work long-term.

The honest breakdown is this. For prototyping new features, for scoped refactors, for accelerating work you already know how to do: it's one of the best tools available. For making structural decisions on an app that already has real users, or for building something where the architecture matters from day one: you still need someone who can think about the whole system, not just the next prompt.

Claude Code makes developers faster. It doesn't replace the judgment that makes software actually work in production.

[Fabricio Richieri @iamrichieri]

If you're about to scale and you're not sure the product can handle it, that's the conversation worth having before your users find out for you.

https://t.co/d3X888eeVL

[Lee Robinson @leerob]

It’s easier than ever to write code…

And yet the hard parts of software engineering are still *very hard*

Don’t get discouraged by the hype. There’s still so much to learn and build.

[Fabricio Richieri @iamrichieri]

Vibe coding your MVP is smart. Keeping that codebase when you start scaling is not.

Getting a working product in front of real users in two weeks, without a dev team, is the right call. Validate the idea, get feedback, close early customers, show traction. Do it fast and cheap.

The vibe coding phase has a job: prove the idea is worth building for real.

The problem shows up when that phase never ends. A user pays but the payment gets stuck in a pending state and nobody knows why. Someone signs up but their session never expires and you have a security hole you didn't know about. You onboard 200 users and the database starts slowing down in ways that make no sense until a developer looks at the schema and explains that it was never designed for this.

That's when professional developers aren't a luxury. They take what you proved and rebuild it so it doesn't collapse under its own weight. Architecture that scales, security that holds, integrations that don't break when something unexpected happens.

The two phases aren't in conflict. The first one makes the second one possible. Most successful products went through both.

[spidey @lochan_twt]

“Ok Claude, do what ever you want, just
make no mistakes”

[Fabricio Richieri @iamrichieri]

The 8 hours to rebuild is usually true for the happy path. The part that takes longer is everything the original product quietly handled that nobody documented: edge cases in the billing logic, the way users actually navigate versus how the founder assumed they would, the integrations that only break in production. That's not in the repo.

[Fabricio Richieri @iamrichieri]

@gregorykennedy That part isn't a joke for most people who skip straight from vibe coded MVP to production. No caching, no connection pooling, no query optimization, just a database getting hit raw by every request. The freedom is real, the bill that comes with it is also real.

[Fabricio Richieri @iamrichieri]

The cost structure part is real, the math on building has changed. What doesn't reset is the cost of running something in production at scale. The $200 subscription gets you the prototype. What it doesn't include is the auth vulnerability you didn't know was there, the database that slows down at 500 users, or the payment flow that drops 8% of transactions silently. Those costs didn't disappear, they just moved to later in the timeline where they're harder to see coming.

[Fabricio Richieri @iamrichieri]

The last 20% is where the actual product lives. The 80% gets you something that works when you're the one using it, in the right browser, with the right data, doing exactly what you designed it to do. The last 20% is what happens when a real user tries something you didn't expect, or two users do the same thing at the same time, or someone leaves the tab open for three hours. That part doesn't get easier with better prompts.

[Fabricio Richieri @iamrichieri]

Not there yet. The PMF part is real, AI tools genuinely changed how fast you can validate an idea. The part that doesn't hold is 1-2 generalists running the whole thing after launch.

Generalists with agents still produce schemas that break under real load, auth flows that work in demos and fail in production, and code that looks clean until someone who knows what they're looking for reads it. That's not a skill issue, it's a context issue. Knowing how to prompt is not the same as knowing why the output is wrong.

The old world had too much overhead. This new world just moves the risk somewhere less visible.

[Fabricio Richieri @iamrichieri]

Lovable and Bolt generate React + Vite apps. v0 generates Next.js. Most founders using these tools have no idea why that distinction matters, and it usually catches up with them.

Vite is great for building SPAs fast. No server, no routing complexity, just a client-side app that runs in the browser. Perfect for prototyping. The problem shows up when you need things that SPAs handle awkwardly: SEO, server-side auth, API routes you don't want exposed on the client, dynamic metadata per page, or a routing structure that scales past 5 screens without becoming a mess to maintain.

Next.js handles all of that at the framework level. File-based routing means your URL structure and your codebase stay in sync naturally. Server components let you fetch data without exposing credentials to the client. Image optimization, caching, middleware, edge functions: things you'd otherwise bolt on later are just there. You're not working around the architecture, you're working with it.

That's why v0 uses it, and why most production apps we work with either start there or end up there after the first rebuild.

If your app was built with Lovable, that's not a dealbreaker. Just worth knowing where the ceiling is before your users find it for you.

[Fabricio Richieri @iamrichieri]

@Hesamation Nah. AI is great!

[Fabricio Richieri @iamrichieri]

@AgusMoyano_ Automating compliance checks is useful, but the tricky part is that the tool is only as good as the rules you feed it. Most early-stage teams skip that configuration step and end up with a false sense of coverage.