Ship It Without a Framework

The Default Answer Is Always a Framework

Someone asks "how should I build this?" and the answer is almost always the same: spin up a React app, install Laravel, set up WordPress with plugins. That's the industry default. It's also frequently overkill.

I build production web apps without frameworks. Not because I'm stubborn, but because for a certain category of projects, a hand-rolled solution ships faster, runs faster, and costs less to maintain.

When Frameworks Make Sense

Let me be clear: frameworks are great tools. If you're building a SaaS product with complex state management, use React or Vue. If you need an ORM with migrations and a job queue, reach for Laravel or Rails. If a client needs to manage a blog with 50 plugins, WordPress is fine.

The question isn't "are frameworks good?" It's "does this specific project need one?"

When They Don't

Most of the sites I build fall into a pattern: a business needs a fast, custom website with some dynamic functionality. Contact forms, content management, maybe an API integration or a dashboard.

For these projects, a framework adds:

• Dependencies to maintain. Every package is a future security patch or breaking change.
• Bundle size. React alone is 40KB+ gzipped before you write a single component.
• Build tooling. Webpack, Vite, npm scripts, CI pipelines. All to serve what's ultimately HTML, CSS, and a bit of JS.
• Abstraction overhead. Learning a framework's way of doing things that PHP or vanilla JS already do natively.

What I Use Instead

A flat-file PHP architecture with vanilla JavaScript. No Composer. No npm. No build step.

Routing: A single index.php with a regex-based route function. About 15 lines of code that handles every URL pattern I've ever needed.

Templates: Plain PHP files with extract(). No template engine needed when PHP already is one.

Content: Markdown files with YAML front matter. Blog posts and case studies are text files on disk. No database queries, no CMS overhead.

Frontend: CSS custom properties for theming, grid and flexbox for layout, vanilla JS for interactions. The browser is incredibly capable out of the box.

Data storage: JSON files for structured data (users, settings, analytics). Simple filegetcontents and json_decode. For 99% of small-to-medium sites, this is all you need.

The Results Speak

Sites built this way consistently score 95+ on Lighthouse. Sub-200ms response times. Zero npm audit warnings. Deployments are literally copying files.

When a client asks "can you update this in a year?", I can say yes with confidence. There's no framework version to upgrade, no deprecated API to migrate from, no dead dependency to replace.

The Trade-offs

This approach has real limitations:

• No ecosystem. Need a date picker? You're building it or copy-pasting one. No npm install magic.
• No convention. New developers have to read the code to understand the architecture. There's no "oh, it's a Laravel app, I know where everything is."
• Manual solutions. Things that frameworks handle automatically (CSRF, session management, input validation) you handle yourself.

These are acceptable trade-offs for the kinds of projects where this approach shines. For larger applications with teams of developers, use a framework. For fast, custom web properties? Consider going without.

The Point

The best technology choice is the one that fits the project, not the one that fits the resume. Sometimes that's React and Next.js. Sometimes it's a few PHP files and some Markdown.

Don't reach for a framework by default. Reach for it by necessity.