Experimenting With Single File Applications

I’ve always been fascinated by minimalism—whether it’s keeping code simple, stripping away unnecessary dependencies, or testing how lean an application can really be. Recently, I’ve been diving into what I like to call Single File Applications (SFAs), and the experience has been both refreshing and surprisingly practical.

Why a Single File?

In an era where frameworks, packages, and libraries dominate, the idea of writing an entire app in one file feels almost rebellious. But there’s power in that rebellion. A single file means less overhead, fewer moving parts, and a directness that pairs beautifully with modern AI-assisted coding.

Every time I asked an AI to edit something, I wasn’t worried about context switching between controllers, views, and a jungle of configuration files. The entire application lived in one place. For token-based AI coding workflows, this was ideal: the model didn’t need to consume 20 different files to understand the logic—it could grok the entire app in one pass.

The Stack: PHP, Bootstrap 5, and SQLite

I went with PHP because, love it or hate it, it’s everywhere. It’s fast to write, deploy, and experiment with. Pairing it with Bootstrap 5 gave me instant UI polish without building design systems from scratch. And SQLite was the obvious database choice—lightweight, zero setup, and perfect for something self-contained.

At first, I kept things ultra-basic: just a simple CRUD app to test the waters. One file, a handful of Bootstrap components, and some SQL queries—done. But then I asked myself: what would a real application look like if I pushed this further?

Building a Job Portal

To see how far I could push the single-file approach, I built something that felt closer to a “real” product: a job board + applicant tracker. The entire thing lives in index.php, yet it’s functional enough that a small company could actually use it to run their job listings.

Visitors can browse open roles, search by title/location/type, and even apply directly online (with optional resume upload). On the admin side, there’s a password-only login where jobs can be posted, edited, closed, restored, or soft-deleted into “Trash.” Applications are stored in SQLite and viewable per job or in a global table. From there, I can star candidates, download resumes, or even hard-delete applications when needed.

Uploads are stored locally in an uploads/ directory, with basic validation (file size, MIME type, extension) and randomized filenames for safety. Admins can download resumes (PDF/DOC/DOCX, max 5MB) through a controlled route instead of direct access.

I also made sure to wire in the essentials: CSRF tokens on all POST requests, HTML escaping, prepared statements, and some upload hardening. It’s not bulletproof, but it’s enough to make the app feel solid while still being minimal.

Check out the project on GitHub. It’s fully functional, though the code isn’t as polished as it could be. One of my next exploration goals is to refactor and clean it up to make it more maintainable.

Building a Menu System

After that experiment, I applied the same philosophy to a different kind of product: a menu + admin system. This one also fits into a single index.php file and could realistically be deployed by a small café or food truck. On the public side, visitors can browse dishes by category, filter, or search. Each item has a name, price, description, and optional photo. On the admin side, there’s the same lightweight password login, but now with tools for managing categories, adding/editing menu items, and uploading images (with size/type validation and randomized filenames).

The admin panel even includes JSON export/import, so you can back up or seed an entirely new menu in seconds. Like the job board, it has a dashboard with stats (counts of items, categories) and the same security scaffolding: CSRF tokens, output escaping, prepared statements, and hardened upload handling.

You can checkout the project repo here.

The One-File Money Machine

While researching, I stumbled upon something that gave this experiment even more weight.

Here’s a site serving thousands of users daily, proving that “single file” isn’t just a hobbyist stunt—it can power real businesses. It was validation that sometimes simplicity is the winning formula.

PHP in the AI Era

PHP often gets dismissed as old or clunky, but I think it’s positioned for a renaissance—especially in the AI coding era. Why? Because PHP is:

  • Stateless and simple: Easy for AI to understand without large dependency trees.
  • Battle-tested: Every weird edge case has been solved by someone before.
  • Perfect for MVPs and microapps: When you want to test an idea quickly, nothing beats spinning up a single PHP file.

When AI is part of the workflow, the game changes. The less cognitive and technical overhead, the better. Single-file PHP apps hit that sweet spot.

Limitations

While single-file applications shine in simplicity and speed, they do come with some natural constraints. As a project grows, a single file can start to feel crowded, and organizing code for readability or team collaboration becomes trickier. Certain best practices—like layered security, modular testing, or large-scale maintainability—are harder to achieve in this format.

That said, these challenges don’t diminish their value; they simply mark the point where an SFA might graduate into a multi-file structure. For small apps, prototypes, and quick experiments, the single-file approach remains a surprisingly powerful option.

Takeaways

I’m starting to see single-file applications not just as a curiosity, but as a strategy. They’re cheap to host, easy to reason about, and AI-friendly.

Yes, they’ll never replace a giant enterprise app. But for MVPs, side projects, and microapps? They’re perfect. And in a world where speed and iteration matter more than ever, the leaner the setup, the better.

Sometimes, the best innovation isn’t about chasing the latest framework—it’s about rediscovering the simplicity that got us here in the first place.