Every tool here survived years of production

9+ years, versions 4 through the current release, every production system I've owned. What keeps me on Laravel is that the framework has an answer for the next requirement before the client asks it. Five auth guards when one stops being enough (the platform). Queues that learn tenancy (Visionerro). Artisan commands turning pharmacy submissions into a pipeline (the medical platform).

Eloquent, in particular, rewards knowing it deeply. The difference between an N+1 disaster and a fast dashboard is usually one deliberate eager-load. When I'd choose differently: a service that's genuinely just an API with heavy async I/O. That is where I reach for FastAPI, as screen.io shows.

Vue 2 and 3 across everything I've shipped since 2019. Vue's single-file components keep template, logic, and style in one legible unit. That matters enormously when you maintain systems alone and revisit code cold, years later. The Composition API earned its place the day components needed to share tenant-scoping logic cleanly.

Inertia.js is the piece I recommend most to Laravel teams: SPA feel, server-side routing, and no separate API layer to keep honest. I've done the same migration twice: Blade to Inertia + Vue 3 at the platform, which is still live and in progress, and Jetstream + Inertia at the medical platform. The pattern holds: you get 90% of a SPA for 30% of its complexity. When I'd choose differently: a truly public, SEO-critical site. Then I use Nuxt, which is what this site runs on.

Adopted at the platform, Visionerro, the medical platform, screen.io, and here. Tailwind's gift to a solo maintainer is that styles live where the markup lives. There is no thousand-line CSS file whose deletions require courage. Utility classes plus a small set of design tokens produce more visual consistency than hand-rolled CSS ever gave me. The discipline it needs: tokens first. Without a real scale for type, space, and color, Tailwind happily helps you build twelve slightly different grays.

Every production system since 2016 has used it: ~75 tables at the platform, a four-codebase shared schema at the medical platform, and a database per tenant at Visionerro. MySQL is the least surprising component in my stack. That is precisely the compliment. Backups, replication, hosting, hiring: every operational question has a well-worn answer.

Redis rides alongside for cache and queues. PostgreSQL runs screen.io. I chose it deliberately to broaden the toolkit, and I'd happily take it to production. When I'd choose differently: the honest answer is that for the transactional SaaS work I do, the database choice matters less than the schema discipline. Explicit state machines and audit tables have saved me more often than any engine feature.

Three different billing architectures: layered charges on one account at the platform, Connect as a payment facilitator at Visionerro, and mixed recurring and one-time charges in a FlexSited checkout. The transferable lesson is simple: webhooks are the integration. API calls are easy; reconciliation is the work.

EC2, S3, and SES. I set them up and ran them solo for the medical platform's first 1.5 years: SSL via Let's Encrypt, security groups, deploys through Bitbucket Pipelines, later Docker and Nginx. GitHub Actions runs screen.io's four-platform matrix. I'm a developer who can own production, not a DevOps specialist. On a team with real platform engineers, I'm a grateful customer with informed opinions.

Kubernetes. Microservices. React. GraphQL. Professional PostgreSQL at scale. Serverless beyond toy use. I'd rather you hear that from this page than discover it in a system design interview. My track record says I can learn an unfamiliar stack quickly: telemedicine APIs, database-per-tenant architecture, and a Python desktop app were all "haven't used" once, right up until a project needed them within weeks.