The Site Builder Setup That Fits a Solo Indie Hacker

Most solo builders spend their first month on the wrong decision. The stack of tools gets picked before the stack of constraints gets named, and the result is a site that works perfectly for a company of forty and creaks under the weight of one person who also has to answer support email. The site builder choice matters less than the shape of the setup around it.

A solo indie hacker running a site builder is not running a smaller version of an agency stack. The constraints are different in kind. There is no one to hand off a broken DNS record at 11 p.m. There is no second pair of eyes on a plugin update that quietly breaks a checkout form. Every dependency added is a dependency that will one day fail alone, at the worst possible hour, with no one else to notice.

That reality should push the setup toward fewer moving parts, not more. The instinct to add a caching layer, a CDN, an analytics suite, an A/B tool, and a form service on day one is the instinct that kills a solo operator's evenings. Each of those is a thing that can break. Each is a thing that needs a login, a billing cycle, and a mental slot.

The builder is the smallest decision in the stack

WordPress, Webflow, Framer, Squarespace, Ghost, a hand-rolled Astro site: the differences between them matter far less than the differences between a setup with three moving parts and a setup with eleven. A solo builder can ship a real business on any of the major options. None of them will save a bad operating model.

What does matter is the escape hatch. Any builder that holds the content hostage in a proprietary format is a builder that has to be trusted for years. A solo operator should be able to export the posts, the images, and the URLs and move them somewhere else without hiring a developer. That single property, portability, eliminates more bad options than any feature comparison.

The second property is boring reliability. A builder that ships a breaking change to its editor every three weeks is a builder that forces the operator to relearn the interface mid-launch. WordPress gets mocked for moving slowly. For a one-person shop, slow is a feature.

Hosting sits on the same bill as the domain, and it should

The cleanest solo setup puts the domain, the DNS, and the hosting under one roof when the builder allows it. This is not laziness. It is a deliberate reduction in the number of places a misconfiguration can hide. When a site goes down, the operator wants one dashboard to open, not four.

Managed hosting for a WordPress site costs somewhere in the range of a modest monthly bill, and the value is not raw server power. It is the automatic backups that actually restore, the staging site that lets a plugin update get tested before it touches production, and the fact that someone else is watching the PHP version. A solo builder paying for a $5 VPS and managing it personally has taken on a second job.

For a static site on a builder like Framer or a hand-rolled setup, the calculus flips slightly. Static hosting is cheap and reliable enough that the managed layer matters less. What still matters is that the deploy process is one step. If publishing a typo fix requires a Git commit, a build, and a manual cache purge, the operator will stop fixing typos.

The plugin list should fit on a napkin

Every plugin is a small bet that its author will keep maintaining it. A solo operator can afford maybe eight to twelve of those bets, and should prefer the ones that do one thing. A single plugin that handles forms, email, and CRM integration is a single point of failure with three jobs. Three small plugins doing the same work fail independently.

The honest test: if the site's plugin list were deleted and rebuilt from scratch tonight, which ones would actually be reinstalled? Security, backups, a form handler, an SEO field editor, maybe a redirect manager. That is the list. Everything past it is a feature that sounded useful in a YouTube tutorial and has not been touched since.

Plugins that inject their own dashboards, their own upsells, and their own update nags deserve particular suspicion. They are the ones that turn a clean admin into a Christmas tree, and the solo operator is the only one who has to look at that tree every morning.

Analytics has to be a single script tag

The dominant cost of analytics for a solo builder is not the tool. It is the cognitive overhead of maintaining consent banners, cookie policies, and the legal exposure that comes with shipping a heavyweight tracker to every visitor. A privacy-focused analytics tool that sets no cookies and collects aggregate page views removes that entire category of work.

Plausible, Fathom, and Simple Analytics all sit in this category. One script tag, no cookie banner, no GDPR paperwork beyond a line in the privacy policy. The trade-off is that the granularity is lower than a full product analytics suite. For a solo builder trying to answer "which pages get read and where do people come from," it is more than enough. For a solo builder trying to answer "which button in which onboarding step caused churn," a different tool is needed.

The point is that most solo sites never need the second question. They need the first one, and they need it to cost nothing in maintenance. A tool that requires a teammate to interpret is a tool that will go unread.

Email belongs to a service, not the host

Transactional and marketing email are the single most common place a solo setup quietly breaks. Sending mail from the same server that hosts the site is a reliable way to end up in spam folders, and diagnosing deliverability is a specialist skill the operator does not have time to build.

A dedicated email service handles the SPF, DKIM, and DMARC records, the bounce handling, and the reputation management. The setup is one afternoon of DNS work and then it is done. The builder connects to it through a plugin or an API key, and the operator never has to think about whether a password reset email landed in a promotions tab.

This is the one place where adding a service is clearly the right call. Email infrastructure is genuinely hard, and the failure mode is invisible. A site that looks fine while silently dropping signup confirmations is worse than a site that is obviously down.

Backups live somewhere the host cannot reach

Host-provided backups are a convenience, not a plan. They protect against the operator's mistakes. They do not protect against the host's mistakes, and they disappear with the account if billing lapses or the company gets acquired. A solo setup needs a copy of the site that lives on storage the host does not control.

Object storage from a major cloud provider, a few dollars a month for a site of any realistic solo size, is enough. The backup plugin pushes a nightly archive there, and the operator has a restore path that does not depend on a support ticket. Testing that restore once, deliberately, on a staging site, is the difference between a backup and a hope.

This is the step most solo builders skip, and it is the step that determines whether a bad Tuesday is an annoyance or a business-ending event.

The staging site is not optional for anyone touching plugins

A plugin update that breaks a checkout flow can run unnoticed for days on a low-traffic site. The fix is a staging copy where updates land first, get clicked through, and only then move to production. Managed hosts include this. Static builders approximate it with preview deploys. Either way, the operator needs a place to break things that is not the live site.

The cost is one extra environment to keep in sync, and the workflow is a few minutes per update. The benefit is that the operator finds the breakage on a Tuesday afternoon instead of discovering it from a customer email on a Friday night.

What the whole setup costs in hours, not dollars

The dollar cost of a lean solo setup lands somewhere around the price of a couple of streaming subscriptions per month: hosting, a domain, an email service, a backup target, and maybe a paid builder tier. The number is not the interesting part. The interesting part is the hours.

A lean setup costs maybe two hours a month in maintenance: updating plugins on staging, checking that backups ran, glancing at the analytics. A heavy setup costs five to ten, and the difference compounds. Those are hours not spent on the product, the writing, or the customer conversations that actually grow a solo business.

The builder is the visible choice, and it gets all the attention in comparison posts. The setup around it is what determines whether the operator spends the next year shipping or firefighting. A site with three moving parts that has never gone down beats a site with eleven that has a beautiful admin panel and a support queue.

The practical test is simple enough to run before committing: name every service in the stack out loud, and for each one, name the person who fixes it when it breaks. If the answer is the same name eleven times, the stack is too heavy. Cut it until the list fits on one hand, and the site will outlast most of the tools that built it.