Stop Choosing Your Tech Stack Like It's 2018

I’m going to say something that will make half of you close this tab: Most JavaScript frameworks are a mistake for most products.

There. I said it.

Now, before you accuse me of being a dinosaur or some PHP apologist living in 2010, hear me out. I’ve built products with React, Vue, Svelte, and yes, the full alphabet soup of modern JS frameworks. I’ve shipped code in Next.js, Nuxt, SvelteKit, and whatever new thing appeared on Hacker News last Tuesday.

And I’m here to tell you that we’ve been doing it wrong.

The great JavaScript framework delusion

Every few months, a new JavaScript meta-framework emerges, promising to solve all the problems created by the previous one. Server components! Island architecture! Partial hydration! Each one sounds revolutionary until you’re three months into a project, debugging why your authentication tokens aren’t persisting across page navigations, or why your server-side rendering is mysteriously breaking in production.

We tried this. Multiple times. With multiple clients. It does not work.

You keep reinventing solutions for problems that were solved twenty years ago. User sessions? Solved. Form validation? Solved. Database migrations? Solved. But somehow, in the JavaScript ecosystem, we treat each of these as exciting greenfield opportunities rather than what they actually are: boring, critical infrastructure that should just work.

This is what actually happens: You start a project. You pick Next.js because it’s popular and you want to be “modern.” Six months later, you’ve accumulated a custom authentication system held together by hope and whatever Claude hallucinated for you that morning. You’ve got seventeen different state management solutions because you couldn’t decide between Redux, Zustand, Jotai, and just using React context. Your bundle size has ballooned to 10MB because every npm package pulled in its own universe of dependencies (and occasionally, a self-replicating worm harvesting your AWS keys). Your deployment process requires sacrificing a small animal during each full moon.

And somehow, we call this progress.

The complexity tax comes due

And that complexity has real costs.

On December 3rd, 2025, React disclosed CVE-2025-55182, a CVSS 10.0 (that’s the maximum severity rating) remote code execution vulnerability in React Server Components. An unauthenticated attacker could craft a malicious HTTP request and achieve full code execution on your server.

Think about that for a moment. Server Components were supposed to be the elegant solution to React’s complexity problem. Send HTML from the server, they said. It’ll be simpler, they said. Instead, the abstraction created an entirely new attack surface that didn’t exist before. The very feature meant to reduce complexity introduced a critical security flaw that affected Next.js, React Router, Waku, and others.

This is what happens when you build cathedrals of abstraction. Every layer you add is another place things can go wrong. Bugs. Security vulnerabilities. Production outages at 3 AM.

Meanwhile, Laravel quietly ships another point release. Rails keeps chugging along. Django remains boring and predictable. Funny how “boring” starts to look pretty attractive when “exciting” means emergency security patches.

The ego problem

There’s something nobody talks about: a psychological component to tech stack decisions.

Choosing boring technology feels like an admission. Like you’re not innovative enough. Like you’re just a code monkey cranking out CRUD apps while the real engineers are out there pushing boundaries with cutting-edge architectures.

I get it. I’ve felt it too.

But your ego is lying to you. The most innovative thing you can do is ship a product that solves real problems. That’s it. Nobody gives out awards for using the most complex rendering strategy. Your users don’t care if you’re using server components or server actions or whatever the React team invented this quarter. They care if the thing works.

The developers I respect most aren’t the ones chasing every new framework. They’re the ones who shipped. Who built businesses. Who solved problems. And almost universally, they did it with boring technology that let them focus on what actually mattered.

Innovation happens in your product. Infrastructure should disappear.

What actually works

The secret that agencies and consultancies don’t want you to know: Boring technology is beautiful technology.

Laravel. Rails. Django. AdonisJS if you’re committed to the TypeScript lifestyle like we are. Phoenix if you’ve seen the Elixir light.

These frameworks have something the JavaScript ecosystem desperately and JS framework people lack: a thought process.

They tell you where your code belongs. They provide built-in authentication that actually works. They handle database management with mature, battle-tested tools. They have testing patterns refined over a decade of production use. And when something goes wrong (which it will), someone has encountered that exact problem before you. The solution exists. It’s documented. It works.

I know what you’re thinking: “But Fawaz, these are old technologies. They’re not innovative.”

Exactly. That’s the whole point.

When you’re building an MVP, innovation should happen in your product, not in your infrastructure. Nobody cares if you’re using the latest rendering paradigm. Your users care whether the product solves their problem.

A note on LLMs and vibe coding

Speaking of things that seem innovative but will hurt you: LLM-assisted development.

I use Claude daily. It’s genuinely useful for boilerplate, for exploring unfamiliar APIs, for rubber-ducking problems. But there’s a trap here, especially with newer frameworks.

The training data for these models skews heavily toward popular, established technologies. Ask Claude about Rails or Django and you’ll get solid, working code. Ask it about the latest Next.js App Router patterns or some bleeding-edge React Server Component setup, and you’ll get creative fiction.

You hit a wall with some obscure framework behavior. You ask Claude Opus 4.5 about it. It responds with “You’re absolutely right!” and proceeds to hand you the sloppiest slop imaginable: functions that don’t exist in the package, packages that don’t exist at all, solutions that completely misunderstand your problem. It adds comments like // This ensures proper hydration above code that does nothing of the sort.

The model isn’t being malicious. It’s being sycophantic. It wants to help so badly that it’ll confidently hallucinate rather than admit uncertainty. And because newer frameworks have less training data, the hallucinations get worse precisely when you need help most.

Boring frameworks don’t have this problem. Laravel questions get Laravel answers. The ecosystem is mature enough that the models have seen thousands of correct implementations.

The exception that proves the rule

I’m not a zealot. There are cases where a JavaScript-heavy approach makes sense.

Single-purpose applications, for one. We built Astrolabe, an MVP that did exactly one thing: take court documents, analyze them, and output reasons why a company lost their case along with recommendations for improvement. Pure text processing. The user management was trivial. The data model was simple. The scope was deliberately constrained. For something like that, a lighter stack works beautifully. When your app needs to do one thing extremely well, the full artillery of a monolithic framework is overkill.

Simple directories and static sites work the same way. Marketing pages, blogs, landing pages, documentation: content that doesn’t need user accounts or complex state. For these, absolutely use Astro, or Next.js in static mode, or whatever makes you happy.

Then there are apps where interactivity is the product. Building a Spotify competitor? Yes, go SPA. A design tool like Figma? The real-time collaborative experience demands it. A multiplayer game? You need that hyper-responsive feel.

But most of us aren’t building Figma.

The interactivity spectrum

Think of it as a spectrum.

On one end sit server-rendered applications. Maximum maintainability. A team of two can ship features, squash bugs, and actually leave the office at reasonable hours. Forms submit and pages refresh exactly how the web was designed to work. The mental model is simple: request comes in, response goes out.

On the other end sit full SPAs. Native app-like experience. Smooth transitions between views. Optimistic updates that make the interface feel instantaneous.

The uncomfortable truth: unless you’re building a consumer app where user experience is your primary differentiator, you probably belong closer to the server-rendered end.

Got a B2B SaaS with multiple user types and permission levels? Audit logging requirements? Third-party integrations to manage? Go monolithic. Laravel. Rails. Django. AdonisJS. Your future self, the one debugging production issues at 2 AM, will thank you.

When native makes sense

Sometimes the web isn’t the answer at all.

We built Khutwatayn, an engagement app for Saudi couples featuring 500 compatibility questions. Could we have built it as a web app? Sure. It’s essentially a TikTok-style feed of questions with a directory feature.

But we built it native.

Sharing an app with your partner should feel effortless: tap a link, download, done. Scrolling through compatibility questions while curled up on the couch feels intimate in a way a browser tab never could. Push notifications arrive naturally, part of the phone’s rhythm rather than a permission popup. The whole experience of downloading an app for something this emotionally significant feels right. It signals commitment.

Sometimes products yearn for a certain medium. Listen to that yearning.

UI polish is not for every MVP

Another controversial take: most MVPs shouldn’t have fancy UI/UX touches.

I can hear the designers gasping. Stay with me.

Animations, micro-interactions, beautiful transitions: these are expensive. The cost isn’t just development time. It’s maintenance overhead. Every animation is a potential bug. Every micro-interaction is code that can break when the underlying library updates.

Save the polish for when your product genuinely demands it.

Games and gamified experiences live or die by how they feel. A clunky game is an abandoned game. Products where emotion is the value proposition need that care too. Khutwatayn needed to feel warm, intimate. The subtle animations weren’t vanity; they were essential to making something as clinical as “compatibility questions” feel romantic. And consumer apps competing on delight in crowded markets need polish as a weapon.

But that inventory management tool for warehouse workers? Skip the parallax scrolling. Your users want fast and reliable. They want to clock out on time.

Security: do the basics, skip the theater

Security basics are simple. Security theater is what gets complicated.

Get the fundamentals right. Keep your S3 buckets private. Use randomly generated keys, not predictable patterns. This is table stakes.

Don’t roll your own crypto. I almost didn’t include this because it should be obvious in 2025, but I’ve seen it happen. Every modern language has excellent cryptographic libraries. Use them. Your clever hashing scheme is not clever.

Know the common attack vectors. CSRF. XSS. Cookie theft. Session hijacking. SQL injection. If you’re building for the web, you need to understand these. The good news? If you’re using the frameworks I recommended (Laravel, Rails, Django, AdonisJS), these protections are built in. Out of the box. You don’t have to think about them because smart people already did.

Audit your LLM-generated code. This is important. In our experience, the latest models like Claude Opus 4.5 and Gemini 3 Pro generally don’t output obviously insecure code anymore. That’s progress. But “generally” isn’t “never,” and LLMs should never substitute for human review, especially for security-critical paths. Authentication flows, payment processing, data access controls: a human needs to read that code.

If you want to go deeper, the OWASP Top 10 for 2025 is worth your time. It’s the industry standard list of web application security risks, and it’s updated regularly.

What NOT to do in an MVP

Now for security theater: the stuff that feels responsible but actually just slows you down.

Rate limiting everything. Don’t be proactive here. Be reactive. Unless you’re integrating with APIs that cost hundreds of thousands of dollars per query (looking at you, government APIs), rate limiting can wait until you actually have a rate problem. You probably don’t have enough users for this to matter yet.

Over-validating inputs. This sounds paradoxical, but excessive validation actually slows you down and increases customer friction. Especially in B2B. That enterprise client whose data doesn’t fit your rigid schema? They’ll go to your competitor who’s more flexible. Validate what matters for security and data integrity. Don’t validate for imaginary edge cases.

Device posture assessment. Tools that continuously monitor devices for malicious behavior are enterprise-grade security solutions for enterprise-grade threats. You’re building an MVP. You’re not getting targeted by North Korean hackers. If you ever become important enough to warrant state-sponsored attacks, congratulations: you can afford proper security infrastructure by then.

The pattern is simple: solve problems you actually have, not problems you imagine having. Security theater makes you feel safe without making you safer, and it costs you speed.

Architecture for speed

When I design systems, I optimize for one thing above all else: iteration speed.

Enable over-the-air updates wherever possible. We use React Native with Expo for mobile projects specifically for this capability. Push a fix and users get it immediately, without an App Store review. For IoT projects, we apply the same philosophy. We once made the mistake of deploying sensors without OTA capability. Updating a tens of devices by hand is an experience I don’t recommend. Learn from our suffering.

Make database migrations painless. Whatever ORM or migration tool you choose, it needs to be reliable and fast. Few things kill momentum like spending more time wrestling with migrations than building features. And if your migration process is scary, you’ll avoid making schema changes. You’ll start working around the data model instead of evolving it. Your schema calcifies into something that doesn’t match reality.

Establish a rapid deployment workflow. You don’t need a CI/CD pipeline with seventeen stages and Slack notifications for every linter warning. A ./deploy.sh script that runs in 30 seconds beats a “proper” pipeline that takes 20 minutes. The goal is simple: minimize the time between “I had an idea” and “it’s live in production.” Everything that lengthens that loop is your enemy.

The bottom line

I’m not telling you to never use React or Vue or whatever framework is trending this week. I use them myself. This very website is built with Astro.

What I am telling you is this: choose your technology based on what your product actually needs, not based on what’s popular on Twitter or what looks good on your resume. And definitely not based on what makes you feel like a “real” engineer.

For most MVPs, especially B2B products, admin dashboards, anything with complex user management, you want a boring, battle-tested monolithic framework. Laravel. Rails. Django. AdonisJS. These aren’t exciting. That’s the main feature.

For single-purpose tools and products with simple auth requirements, lighter stacks work fine.

For native-feeling consumer apps where experience is everything, go SPA or native mobile.

And whatever you choose, optimize for iteration speed. The only thing that matters in the early stages is learning, and you can’t learn if you can’t ship.

Stop building cathedrals. Start building products.

Have questions about choosing the right stack for your MVP? Get in touch. We’ve made most of the mistakes so you don’t have to.