I’ve been working with my developer on my SaaS product for several months now. I’m not a developer and I don’t know how to write code. Here is a snapshot of my commits in the last 2 weeks:
- Fix N+1 query in Like component and remove bloated Livewire snapshot
- Use cryptographically secure
Str::randomfor share link hashes - Convert campaigns table rows from Livewire components to inline Blade markup
- Add Dependabot config for weekly Composer and npm updates
- Add daily/monthly toggle to funnel line chart and fix session key error
- Queue email verification notification
- Move strategy route behind auth middleware
- Codebase cleanup: remove redundancies, improve queue resilience, use enum for stages
- Fix null dereference risks in public report and subscriber deletion
- Rename URLs from /experiments to /campaigns and /experiment to /campaign
- Add migration to drop
dashboard_linkcolumn from teams table - Autolink URLs in hypothesis chat and harden search results
- Fix CI migration failure by removing non-existent foreign key drop
Somewhere along the way, I stopped wondering if I could do this and started noticing why Laravel specifically made it possible. Not React, not Next.js, not a no-code tool. Laravel. Here’s why.
Table of contents
Open Table of contents
- Convention eliminates decisions
- The ecosystem is curated, not assembled
- Livewire keeps you in one world
- Eloquent reads like intent
- AI-legible code
- Artisan makes the invisible visible
- Documentation written for humans
- The real question I asked
- Why not just use a vibe-coding tool?
- Laravel is a framework for builders
Convention eliminates decisions
Laravel is famously opinionated, and those opinions are a gift to non-traditional developers.
Every Laravel app follows the same structure. Controllers go in app/Http/Controllers. Migrations go in database/migrations. Routes go in routes/web.php. Models go in app/Models. There’s a convention for how to name things, where to put things, and how things connect.
For a traditional developer, conventions are a convenience — they save time debating architecture. For a non-traditional developer, conventions are the difference between being able to build the product or not. Every decision the framework makes for you is one fewer decision you need the expertise to make yourself.
| Decision | Without conventions | With Laravel |
|---|---|---|
| Where do controllers go? | You decide, document it, enforce it | app/Http/Controllers — always |
| How do you talk to the database? | Research ORMs, pick one, configure it | Eloquent — built in, ready to go |
| How do you handle auth? | Evaluate libraries, integrate, maintain | Breeze — one command |
| How do you send email? | Choose a provider, write an adapter | Mail — built in, swap providers in .env |
| How do you run background jobs? | Set up a queue system from scratch | Queues — built in, php artisan queue:work |
| How do you structure tests? | Decide on a framework and conventions | PHPUnit + Pest — configured out of the box |
This matters even more when you’re working with AI. When I tell Claude Code to “add a new controller,” it knows exactly what that looks like because every Laravel app looks the same. There’s no ambiguity about file structure, naming, or patterns.
The ecosystem is curated, not assembled
Need queues? Built in. Email? Built in. Auth? Breeze. Payments? Cashier. Search? Scout. File storage? Built in. Real-time events? Reverb. Server management? Forge. Serverless deployment? Vapor. AI? The first-party AI SDK.
These aren’t random packages found on Stack Overflow. They’re first-party or officially blessed by the Laravel team. You don’t need the expertise to evaluate fifteen competing libraries for each concern — Taylor Otwell has already made the decision for you.
For a traditional developer, this is “batteries included.” For a non-traditional developer, this is “you don’t need to know what batteries to buy.”
Livewire keeps you in one world
This is the thing that I think makes Laravel uniquely suited for non-traditional developers compared to other frameworks.
With most modern web stacks, you need to learn a backend language and a frontend framework — typically JavaScript with React, Vue, or Svelte. You need an API layer connecting them. You need separate build tools, separate mental models, and often separate deployment pipelines.
Livewire eliminates all of that. You write PHP and Blade. One language, one set of files, one mental model. Interactive UIs — search bars, forms, real-time updates — all built in PHP.
As Taylor Otwell puts it:
“Applications feel really interactive like they had tons of JavaScript behind them when really you’re just writing PHP and Blade the whole time. And you don’t have to deal with any complicated build steps or front-end scaffolding.”
— Taylor Otwell, Laracon US 2023
For someone directing an AI coding agent, this halves the surface area you need to understand and review. I don’t need to context-switch between PHP and JavaScript. I don’t need to understand REST API design. I work in one world.
Eloquent reads like intent
This is something I didn’t appreciate until I’d been reviewing AI-generated code for a while. Eloquent, Laravel’s ORM, reads like English:
User::where('active', true)->latest()->first();
Even if you couldn’t write that from memory, you can read it and know what it does: find the most recent active user. Compare that to raw SQL or a less expressive ORM, and the difference for a non-traditional developer is enormous.
When my AI assistant writes a query, I can review it. I can see if it’s doing what I intended. I can spot when it’s loading too much data or querying things it doesn’t need. That ability to read code and evaluate intent — without being able to write it from scratch — is exactly what makes Eloquent such a good fit.
AI-legible code
Here’s something I only appreciated after working with Claude Code for months: Laravel’s conventions make AI dramatically more effective.
Because every Laravel app follows the same structure, AI models have trained on millions of examples that all look similar. When I say “add a migration to drop the status column” or “create a resource controller for campaigns,” the AI knows exactly what that looks like, where the files go, and what conventions to follow.
Compare that to a bespoke project where every team invents their own file structure, their own naming conventions, their own patterns. The AI has to learn your conventions first. With Laravel, the framework’s conventions are the conventions. The AI already knows them.
This is why I can ask a single question like “is there anything obvious in the code that could be having a negative impact on performance?” and get back 9 specific, actionable issues. The AI can read Laravel code fluently because Laravel code is predictable.
Artisan makes the invisible visible
php artisan migrate
php artisan queue:work
php artisan route:list
php artisan make:model Campaign -m
These are plain-English commands that map directly to what’s happening. You don’t need to understand the underlying implementation to use them confidently. When I first ran php artisan migrate, I was terrified I’d break something. But once I understood that a migration is just a recipe for a database change — with a built-in undo button — the fear disappeared.
Artisan commands also give you and your AI agent a shared vocabulary. I can say “run the migrations” or “list the routes” and we both know exactly what that means. There’s no translation layer between intent and execution.
Documentation written for humans
Laravel’s documentation is famously good — and not just “comprehensive API reference” good. It explains why things work the way they do. Concepts are introduced progressively, with examples that build on each other.
For a non-traditional developer, this is the bridge between “I can copy-paste this” and “I understand what I’m using.” And when you understand the concepts, you can direct an AI far more effectively. As I wrote in a previous article: the concepts matter more than the commands. Once you understand what should happen, AI handles how.
The real question I asked
This article started with a real question I asked during a Claude Code session:
Why do you think Laravel is such a perfect fit for people like me? It’s the opinions, the rails, the conventions… everything seems perfectly suited.
The answer came back to one core idea: Laravel compresses the knowledge gap. Every opinion the framework holds is one fewer thing you need to be an expert in. Every convention is one fewer decision to make. Every first-party package is one fewer technology to evaluate.
For a traditional developer, that’s convenience. For a non-traditional developer, it’s what makes building possible at all.
Why not just use a vibe-coding tool?
Tools like Bolt, Lovable, and v0 are impressive for prototypes. But they generate code you can’t maintain, lock you into their platform and stack, and can’t handle what a real SaaS needs — queues, scheduled jobs, payment webhooks, background processing.
Laravel takes longer to get started with. But you end up with a real codebase that follows conventions, that any Laravel developer can pick up, and that AI agents can read and modify reliably. Vibe-coding tools give you speed at the start. Laravel gives you something you can actually maintain.
Laravel is a framework for builders
Laravel didn’t set out to be the perfect framework for non-traditional developers. It set out to be the most productive framework for all developers — through convention, through a curated ecosystem, through readable code, and through relentless focus on developer experience.
It turns out that when you remove enough friction from the development process, you also remove the barrier between “developer” and “non-developer.” Add an AI coding agent, and the line blurs almost completely.
If you’re a founder, a designer, or anyone else who needs to build software but can’t write code from memory — Laravel and an AI agent might be all you need. Not because it’s easy, but because Laravel’s conventions give both you and the AI a shared foundation to build on. The framework does the structural thinking so you can focus on the product thinking.
Rails did this for a generation of Ruby developers. Laravel is doing it for a new generation of builders — many of whom don’t think of themselves as developers at all.