Why I Build Small

Most of the side projects I care about are small. A personal site, a script that moves files around, a little page that answers one question well. For years I reached for the biggest tool I could find, then wondered why nothing ever shipped. These days I do the opposite: I build small, and I ship.

This is not a rant against frameworks. It's a note to myself about what actually gets finished.

The cost nobody bills you for

A framework is a loan. You get structure and speed today, and you pay interest forever. The interest looks like this: an upgrade breaks your build three months in, a dependency gets abandoned, the deploy needs Docker, which needs a CI runner, which needs a paid plan. None of that is writing. All of it is maintenance.

When I look at my finished projects versus my abandoned ones, the pattern is boring. The finished ones had fewer moving parts. The abandoned ones started with a package.json that I never quite tamed.

If a project's setup takes longer than the idea is worth, the setup wins and the idea dies.

That's the whole argument, really. Build small enough that the boring parts stay boring.

What "small" actually means

Small is not an aesthetic. It's a budget, and you spend it in a few places:

• One language I already know. Usually PHP or plain JavaScript. No new runtime to learn on a Tuesday night.
• Files on disk as the database. Markdown in, HTML out. If the site dies, the content is still readable in any editor.
• Boring hosting. A VPS that costs less than a coffee per month, running nginx and PHP-FPM. Nothing auto-scales because nothing needs to scale.
• No build step. If I can edit a file and refresh the page, I will actually edit it.
• Deploy as a copy. rsync and move on. Most of the time the "deploy pipeline" is one command I can remember.

None of this is clever. Clever is what got me into trouble.

A real example

This site is the case study. The whole engine is a couple hundred lines of PHP that read the konten/ folder, parse a tiny frontmatter block, and render Markdown. Here is roughly how a post gets found:

function ia_find($slug) {
    if (!is_string($slug) || $slug === '' || !preg_match('/^[A-Za-z0-9._-]+$/', $slug)) {
        return null;
    }
    foreach (ia_articles() as $a) {
        if ($a['id'] === $slug) return $a;
    }
    return null;
}

That's it. No router library, no ORM, no template engine. If I want a new post, I drop a .md file in a folder. If I want to change the design, I open one CSS file.

Small versus heavy, honestly

I'll be fair to the other side. There are projects where the big stack earns its keep.

The rule I use: start small and let the project earn its complexity. If real users show up and the simple thing hurts, upgrade then, with real information instead of imaginary scale. Almost nothing I build ever reaches that point, and the things that do tell me clearly.

The unglamorous benefits

Small projects are quiet in a way that surprised me:

1. I can hold the entire thing in my head.
2. Onboarding past-me takes minutes, not a day of reading.
3. Backups are a .zip I can email to myself.
4. The site loads before you can blink, on a phone, on bad wifi.
5. It costs almost nothing, so it can live for years without a decision.

That last one matters more than it sounds. A project with no bill and no maintenance is a project that never has to be shut down. It just keeps working, like a chair.

---

I don't think "small" is a virtue on its own. It's a way to protect the part that matters — the idea, the writing, the thing you actually wanted to make. Frameworks are fine. But the fastest way to never finish something is to build the scaffolding first and the thing second.

Build small. Ship it. You can always grow later, and most of the time you shouldn't.