Why I Keep Building on Laravel, React, Tailwind and MySQL

Shopify recently announced it's moving parts of its mobile app back from React Native to native code. A few years ago the industry was telling everyone the opposite: write once, run everywhere, don't bother with two native codebases. Now one of the biggest names in ecommerce is quietly walking some of that back. It's a good reminder that fashionable technical decisions and correct ones aren't always the same thing.

I get asked fairly often what I actually build with. The honest answer is boring: Laravel, MySQL, React, and Tailwind, most of the time. Not because I haven't tried other things, but because after ten years of shipping software for real businesses, this combination causes me the fewest problems later. Later is the part people forget to price in.

What each piece is actually doing

Laravel handles the backend: the database logic, the business rules, authentication, queued jobs, scheduled tasks, API endpoints. It's a PHP framework, which some people still think of as old-fashioned. It isn't. It's mature, which is a different thing. The documentation is good, the ecosystem of packages is huge, and it doesn't reinvent its own conventions every eighteen months.

MySQL stores the data. Relational, well understood, backed up easily, and every hosting provider on earth knows how to run it. I don't reach for something more exotic unless there's a specific reason to, and for most business systems (bookings, invoicing, CRM data, policy records) there isn't one.

React handles the interactive parts of the interface, the bits where a page needs to update without a full reload: a booking calendar, a filtered table, a dashboard. Not every page in a Laravel app needs it. A lot of a typical application is still plain server-rendered pages, because that's simpler, faster to load, and easier for me to maintain.

Tailwind is the styling layer. It's fast to build with and it stops a project accumulating the pile of half-used CSS files that older systems tend to end up with, where nobody's sure which class is still doing anything.

Why I don't chase the newest thing

New frameworks appear constantly. Some are genuinely better at a specific job. Most solve a problem that only exists at a scale far beyond what a normal business system will ever hit. Choosing one of these for a client project usually means:

• Fewer developers available if you ever need someone else to pick up the code.
• Less mature tooling for the boring but essential things: error tracking, deployment, backups, security patches.
• A higher chance the framework itself gets abandoned or majorly rewritten in a couple of years, leaving you with a migration project you never asked for.

The Shopify example is instructive precisely because it's a company with enormous resources choosing to move away from a fashionable cross-platform approach for something more direct. If a business that size can end up regretting a trend-driven stack decision, it's worth being cautious before a smaller business bets its core system on whatever's trending on a developer forum this month.

Boring is a business decision, not a technical one

When I'm scoping a Laravel-based system for a client, I'm not just thinking about how fast I can build it. I'm thinking about who fixes it in three years if I'm not available, how easy it is to hire around if the business ever wants to bring development in-house, and how much of the toolchain will still be actively maintained by then. Laravel, React and MySQL all score well on that. They're not going anywhere, and there's a large enough pool of developers who know them that a client is never stuck.

This matters more for a solo developer relationship than it does for an agency, if anything. There's no bench of other developers behind me who can pick up an unusual stack if I'm on holiday or busy on something else. Sticking to well-documented, widely used tools means anything I build can be handed off, reviewed, or extended by someone else without a steep learning curve, and that protects the client, not just me.

Where I'd deviate

None of this means the stack never changes. If a project genuinely needs a native mobile app rather than a web app that works well on a phone, I'll build with React Native properly rather than pretending a website is the same thing, and that's a different conversation covered under app development. If a client already has a Postgres database with years of data in it, I'm not going to insist on ripping it out for MySQL just for consistency. If a project has a genuinely unusual performance requirement, that's worth a proper look at alternatives rather than a default.

The point isn't that Laravel, React, Tailwind and MySQL are always right. It's that they're right often enough, and boring enough, that I'd need a specific reason to move away from them, not just a specific reason to justify staying. That's a different way of making the decision than most trend pieces suggest, and it's the one that's held up over a decade of client projects that are still running, still getting maintained, and still easy to hand to someone else if it ever comes to that.