How an ER trip in Ireland Taught Me Why Convex is Saving Startups from Themselves

Justin Rich

Justin Rich

— 6 min read
How an ER trip in Ireland Taught Me Why Convex is Saving Startups from Themselves

Or: Why good architecture shouldn't require a Series A wake-up call

Picture this: I'm sitting in an Irish ER waiting room, staring at the very best public access programming the country has to offer at 5 am, while I wait on blood tests for "a wee infection" that needed sorting.

If you haven't been through the EU public health system, have you really been to Europe? Because let me tell you, nothing says "authentic cultural experience" quite like explaining to a Galway ER nurse how American ambulance trips aren't free and that you toughed out what you thought was a "minor" case of road rash when you laid your Harley down the week before your trip to the emerald isle.

But this story isn't about my questionable life choices (though there are many). It's about how being laid up in bed led me to discover something that might actually save startups from one of the most expensive mistakes they make.

The Accident That Wasn't Really About Motorcycles

So there I was, supposed to be touring the Irish countryside, instead playing the world's most pathetic version of "Netflix and chill" in my Airbnb. I was supposed to meet up with my dad in London in a week, so I was franticly trying to complete our itinerary with GPT. When I got tired of copy-pasting the third page of context into my prompt I realized we needed a solution that wasn't just "Justin working as a glorified GPT clipboard."

So naturally, being a programmer with too much time and wounded pride, I decided to build an app. Because apparently when life gives you lemons, engineers make a lemon-sorting algorithm.

The concept was simple: store all my travel research in a vector database, then use AI to recommend places based on our location and my notes. If we still needed inspiration, it would hit Exa.ai for more suggestions. I called it "Serendrift" because I thought I was being clever. (Spoiler: I wasn't.)

The Backend Dilemma (Or: Why I Almost Made a $2 Million Mistake)

Here's where things get interesting. I needed a backend that I could build quickly because, you know, vacation app for two people doesn't exactly require enterprise architecture. My first instinct was to reach for Supabase—throw some database calls directly into my Next.js components and call it a day.

This is the exact moment where most startups make a decision that will cost them millions of dollars later. But more on that in a minute.

Instead, I decided to try Convex, mostly because I was bored and slightly medicated. At first glance, I thought it was just another "AI infrastructure" Supabase clone trying to ride the AI hype train. You know, like how every startup in 2023 suddenly became "AI-powered" even if they were just selling artisanal soap.

I was wrong. Like, really wrong. The kind of wrong that makes you question your entire understanding of how backend infrastructure should work.

The Pattern That's Destroying Startups

Before I explain why Convex blew my mind, let me tell you about a pattern I've seen at literally every startup I've consulted with. It goes like this:

Phase 1: The "Move Fast" Phase

  • Build a beautiful frontend really quickly
  • Use Firebase or Supabase for instant backend magic
  • Make database calls directly from your UI components
  • Ship fast, get users, raise Series A
  • Everyone feels like geniuses

Phase 2: The "Oh No" Phase

  • You need to add one more feature
  • That feature requires changing your data structure
  • But your frontend is so tightly coupled to your backend that changing anything breaks everything
  • Development velocity drops to the speed of continental drift
  • Your Series B investors start asking uncomfortable questions

Phase 3: The "Expensive Lesson" Phase

  • CTO announces: "We need to get off Firebase"
  • Hire 10 engineers to rebuild everything properly
  • Spend 8 months and $2 million re-architecting what you built in 3 weeks
  • Wonder why you didn't just do it right the first time

I've watched this movie so many times I could recite it from memory. It's like Groundhog Day, but with more TypeScript errors and existential dread.

The problem isn't Firebase or Supabase—they're great tools. The problem is they make it too easy to implement terrible patterns. It's like giving someone a Ferrari with no brakes and being surprised when they drive into a tree.

Enter Convex: The Framework That Saves You From Yourself

So there I am in Dublin, expecting Convex to be just another backend-as-a-service that lets me make database calls from my React components. Instead, I discover they've actually solved the fundamental problem I've been watching startups struggle with for years.

Here's what makes Convex different: they force you to define functions on their server with strict contracts. You can't just randomly query your database from your frontend. You have to create actual API endpoints with proper separation of concerns.

Let me give you a simple example. With traditional approaches, you might have something like this scattered throughout your frontend:

// DON'T DO THIS (but everyone does)
const user = await supabase
  .from('users')
  .select('name, email, preferences')
  .eq('id', userId)
  .single()

const posts = await supabase
  .from('posts')
  .select('*')
  .eq('user_id', userId)

This looks innocent enough, right? Until you need to change your user schema or add some business logic. Suddenly you're hunting through dozens of components, updating database calls, and praying you didn't break anything.

With Convex, you're forced to do this:

// Define your API function in convex/users.ts
export const getUserWithPosts = query({
  args: { userId: v.id("users") },
  handler: async (ctx, args) => {
    const user = await ctx.db.get(args.userId);
    const posts = await ctx.db
      .query("posts")
      .filter(q => q.eq(q.field("userId"), args.userId))
      .collect();
    
    return { user, posts };
  },
});

// Use it in your frontend
const userWithPosts = useQuery(api.users.getUserWithPosts, { userId });

Now when you need to change something—add a field, modify the business logic, whatever—you change it in one place. Your frontend doesn't know or care about your database schema. It just knows it's calling getUserWithPosts and getting back the data it needs.

This might seem like a small difference, but it's the difference between a codebase that can evolve and a codebase that turns into digital quicksand.

The Speed vs. Architecture False Dilemma

Here's what really impressed me about Convex: it doesn't sacrifice speed for good architecture. The tooling is actually faster to work with than the "quick and dirty" approaches because the types flow through your entire application automatically.

When I added a new field to my travel recommendations schema, Convex automatically updated the types everywhere. My frontend immediately knew about the new field. My API functions were properly typed. Everything just... worked.

It's like having a really good project manager who won't let you skip the important stuff but also makes sure you don't get bogged down in bureaucracy.

Compare this to the Firebase approach where you change your database schema and then spend the next two hours hunting down every place in your codebase that broke because you added a field. It's like performing surgery with a sledgehammer—technically possible, but probably not optimal.

Why This Matters More Than Your Series A Valuation

Look, I'm not saying Convex is perfect or that it's the right choice for every project. But here's what I am saying: they've identified and solved a real problem that's costing startups enormous amounts of money and time.

Every startup thinks they're different. "We'll just use Firebase for now and refactor later." "We need to move fast to find product-market fit." "Good architecture is a luxury we can't afford."

But here's the uncomfortable truth: bad architecture becomes exponentially more expensive to fix as your team and user base grow. It's like compound interest, but in reverse—the debt accumulates faster than you think, and the interest payments (in the form of development velocity and engineering hours) become crushing.

Convex forces you to make better decisions from day one, without sacrificing the speed that early-stage startups need. It's like having training wheels that actually make you faster rather than slower.

The Serendrift Epilogue

My travel app? It worked great. My dad and I discovered some amazing spots in London and Paris that we never would have found otherwise. The AI recommendations were surprisingly good, probably because I'd dumped a ton of my research into the vector database and the app could actually use it intelligently.

But more importantly, when I wanted to add a feature to share recommendations between users (because my dad kept asking "how do I see that place you found?"), it took me about 20 minutes instead of 20 hours. I added a new Convex function, updated the UI, and boom—sharing worked perfectly.

If I'd built this with my usual "database calls scattered everywhere" approach, that simple feature would have required touching a dozen different files and probably would have introduced three new bugs.

The Bigger Picture

This isn't really about Convex specifically—it's about the broader pattern of tools that make good practices easier rather than harder. Too many developer tools force you to choose between speed and sustainability. The best tools eliminate that false choice entirely.

The startups that figure this out early will have a massive advantage. While their competitors are spending millions on "technical debt sprints" and "architecture refactors," they'll be shipping features and scaling sustainably.

And hey, maybe they'll even have time to take a proper vacation without needing to build an app to manage it. Though honestly, where's the fun in that?

What patterns have you seen startups repeatedly struggle with? Are there other tools that force good practices from the beginning? Let me know in the comments—I promise not to judge your Firebase horror stories.

Thanks for reading Hackerpug! Subscribe for free to receive new posts and support my work.