The Minimum Viable Software Infra (What Most Solo Builders Get Backward)

Most solo builders spend weeks on features and treat domain, HTTPS, deployments, and environments as an afterthought. That order costs far more later.

Most solo builders do things in the wrong order. They spend weeks dialing in features, leaving the domain, HTTPS, deployments, and environment setups as an absolute afterthought.

It always costs you way more time and frustration later.

I've learned to treat infrastructure as a core part of the product, not just some boring scaffolding around it. That includes your portfolio site. That site isn't a side quest; it's the front door to whatever you are building.

Identity on the Internet

Before writing a single line of code, I want total control over the setup.

The Domain: I buy the domain myself and use a DNS manager where I can actually read the records. A record, CNAME, whatever the host needs - I make sure I know exactly where everything points.
HTTPS: This is non-negotiable and has to be automated. I am not hand-renewing SSL certificates once a year and hoping I remember some random calendar invite. Let the platform handle it.

This sounds incredibly basic. It is basic until it goes wrong, and suddenly you are debugging email deliverability and mixed-content warnings instead of actually building your product.

The Portfolio Site's Actual Job

A portfolio has one specific job. It is not a museum for every random coding experiment you've ever run. It should clearly state who you are, what kind of work you do, how to reach you, and where to go next. One clear call to action beats five vague buttons every single time.

Technically, keep it as light as humanly possible. Static pages or a minimal site generator. Fast fonts, readable type, sane spacing, and a mobile-first layout. No clunky carousels, no autoplay videos, and no over-engineered frameworks for a site that changes only once a month. If it doesn't load instantly on a phone over a weak cell signal, it isn't done.

Content-wise, focus on the outcomes: what your product does, who it is for, and where to try it. Save the deep, long-form thinking for the internal pages. The homepage just needs to open the door.

Keeping the Pipeline Thin

I want one branch that means production. One build I can reproduce locally. One artifact I can redeploy when something goes sideways.

Your CI pipeline can be minimal. Lint, test, build, deploy. You do not need a twelve-stage enterprise workflow just to ship a landing page update.

Most importantly, figure out your rollback strategy before you actually need it. Know exactly which button to press to redeploy the last good build. The middle of your first live outage is the absolute wrong time to navigate a hosting platform's confusing UI.

Environments and Safety Nets

Production gets the real domain, the real secrets, and the real billing alerts. Development or staging should look like production in its layout, but not in its cost. Use the same services, just on smaller, free, or cheap tiers with fake API keys where possible.

The rule I care about most: if your development environment shouldn't send real emails, charge real credit cards, or post to social media, disable those features directly in the code and the infrastructure. Hope is not a strategy.

Environment variables are how you split these worlds. Keep the architectures identical, just swap the variables.

Secrets, Accounts, and Observability

Use a password manager, create a separate email for your cloud accounts, and keep your API keys in a secure environment store. Never let them slip into a GitHub repo or a random screenshot.

Set up billing alerts on day one for every single cloud account with a low threshold. Your first surprise cloud invoice will teach you this lesson faster than any blog post ever could.

As a solo developer, you also don't need a wall of massive dashboards. You just need three things:

An uptime check on your main route (/).
Error logs consolidated in one place you will actually look at.
A single status link you can pull up on your phone when someone says the site feels down.

That is plenty until you have real evidence that you need more.

The Real Goal

Good infrastructure is quiet. HTTPS just works. Deployments are boring. Your development environment cannot accidentally overwrite production. Your portfolio loads fast and tells the truth.

Get those fundamentals right early. Building new features is much easier when the floor beneath you is solid.

If you are building alone, nobody is coming to fix your DNS at midnight. Build like you know that.

That's the reality of being a team of one.