Running a product alone means doing every job: deployment, support, monitoring, invoicing, marketing. The work that scales badly is not the building — it is everything around it.
This is a guide to the automation that actually pays off for a solo maker, and the automation that quietly costs more than it saves.
The Rule for Deciding
Automate when the task is frequent, deterministic, and boring. Skip it when any of those is missing.
The trap is automating something rare. A task you do twice a year takes ten minutes; automating it takes three hours and then breaks silently by the time you next need it. That is a net loss you will not notice, because the cost is invisible and the satisfaction is immediate.
A rough test before building anything: how many times will this run in the next six months, and what breaks if it fails quietly? If the answer is "a few times" and "nothing," write it down as a checklist instead.
Start Here: CI That Runs Your Tests
The highest-return automation available, and the one most solo makers skip because "I'll just run the tests locally."
You will not. Not consistently, not when you are tired, not on the Friday deploy. A pipeline that runs tests on every push takes twenty minutes to set up and catches the class of mistake that costs an evening.
Keep it minimal at first: install, test, done. Add linting and type checking once the basics are stable. Resist building a twelve-stage pipeline for a product with four users.
Deployment
If deploying involves you running commands in order, automate it now. Manual deploys fail in the specific way that hurts: you skip a step at 11pm because you have done it forty times and are confident.
Most managed platforms give you push-to-deploy for free. If you self-host, a deploy script triggered by CI is a couple of hours of work you will recover in a month.
Add a rollback path while you are there. Automated deploys make shipping easy, which means you will ship broken things faster than before. Being able to revert in one command is what makes that safe rather than reckless.
Monitoring: Automate Knowing, Not Fixing
The single most valuable automation for a solo product is being told when it breaks, because otherwise you find out from a user — or worse, you do not.
Three things, all cheap:
Uptime checks. Ping your main endpoint every few minutes, alert if it fails twice in a row.
Error tracking. Capture exceptions with enough context to debug them. Free tiers are generous.
A weekly digest. Signups, revenue, errors, and traffic in one automated message. Not to react to, just to notice trends you would otherwise miss.
Alert on things you would act on at 2am, and nothing else. This is the discipline that decides whether monitoring helps you or trains you to ignore it. Site down: alert. Error rate tripled: alert. One user hit a validation error: log it, do not wake up.
Alert fatigue is a real failure mode, and once you start ignoring notifications you have effectively no monitoring while still paying for it.
Customer Emails
Automate the transactional ones: welcome, password reset, receipt, trial ending. These are deterministic, frequent, and expected.
Do not automate your early customer conversations. For your first hundred users, personally messaging people is one of the highest-value things you can do, and a drip sequence is a much worse substitute than it looks. Automate that once the volume genuinely stops it being possible.
Backups
Not glamorous, and the one whose absence is unrecoverable.
Automate a daily database dump to storage that is not your application server. Set a retention window so it does not grow forever.
Then test a restore. An untested backup is a hypothesis, not a backup, and people discover this at the worst possible moment. Restore into a scratch database once, confirm the data is there, and put a reminder to repeat it in six months.
The Content and Social Question
Scheduling posts in advance is fine and saves real time. Generating content automatically is usually not.
Auto-generated posts perform poorly, and the reason is structural rather than technical: the value of a build-in-public post is that a specific person had a specific experience. Automate the scheduling, keep the writing.
What Not to Automate
Support replies. At small volume, personal answers are a competitive advantage. Automating them removes the main thing a solo product can offer over a larger competitor.
Anything with a rare, expensive failure mode. Automated billing changes, automated account deletion, automated data migrations. The time saved is small; the blast radius is not.
Onboarding for your first hundred users. Covered above — those conversations are research, not overhead.
Things you have done fewer than five times. You do not yet know the shape of the task well enough to automate it correctly, and you will end up automating a process you would have changed.
Keep Automation Debuggable
Automation that fails loudly is fine. Automation that fails silently is worse than no automation, because you have stopped checking. Three habits that prevent this:
Every scheduled job reports. Success or failure, somewhere you will see it. A backup job that has silently failed for three weeks is the standard version of this story.
Make jobs safe to re-run. If a job fails halfway, running it again should not double-charge someone or send a second email. This is worth designing for up front.
Keep it in your repo. Scripts and workflow files in version control, not clicked together in a UI you will not remember the shape of in six months.
A Realistic Order
If you are starting from nothing, roughly this sequence:
Automated tests in CI. Twenty minutes, catches the most.
Push-to-deploy with a rollback path.
Error tracking and uptime alerts. Free, and the difference between finding out and being told.
Automated backups, with one tested restore.
Transactional emails.
A weekly metrics digest.
That is most of the value. Everything past it has sharply diminishing returns for a one-person product.
The Underlying Point
Automation is not the goal — attention is. Every automated task is one less thing consuming the limited attention you have for the work only you can do.
Which is also why over-automating backfires: a pipeline with nine stages, four notification channels, and a bespoke deploy system is itself a product you now maintain, competing for the attention it was supposed to free up.
Automate the boring, frequent, deterministic things. Do the rest by hand and stop feeling bad about it.
If you are building solo, our guide to choosing a stack covers the other half of this, and you can list your product free.
