Choosing a stack you can maintain alone.

Dan McKinley’s Choose Boring Technology gives a company “about three innovation tokens” to spend on new technology, and argues that the long-term cost of keeping a system working dwarfs the inconvenience of building with familiar tools. Boring, in his sense, means the failure modes are known. Postgres, Python and cron are boring. That is the point.

A one-person company has fewer tokens than that, probably one. Spend it on the product. If the product is a scheduling tool for dental clinics, the scheduling logic is where novelty belongs; the database, the web framework and the deploy pipeline should be things you could fix half-asleep.

The practical test: when this part breaks at 23:00, can you find the cause from its logs without opening the documentation? If not, it is not boring to you yet, however popular it is.

Postgres covers most of what small SaaS products reach for extra services to do. Each of these keeps one fewer thing running:

• Background jobs: a queue that stores jobs in Postgres, such as GoodJob or Solid Queue for Rails, pg-boss for Node or Procrastinate for Python. Jobs are rows, they survive restarts, and you can inspect them with SQL.
• Scheduled work: a cron-style trigger that calls an HTTP route in your app beats a separate scheduler process.
• Sessions and rate limits: signed cookies, or a small table with an expiry column. A cache server earns its place when you can measure a query that is too slow, not before.
• Search: Postgres full-text search (tsvector, to_tsquery) handles a catalogue of tens of thousands of rows without a search cluster.
• Files: an object-storage bucket, never the app’s local disk, which a redeploy may replace.
• One codebase: a monolith with folders, not services with network calls. Splitting later is a refactor; merging services back is a migration.

Money is the visible cost of a component. Time is the larger one for a solo founder, and it is rarely written down. The ranges below are our estimates, not measurements: they assume a small production app, a few hours of incident time spread over a year, monthly dependency updates and the upgrade cadences in the next section. Use them to compare options, not to plan a budget.

Runtimes and databases stop getting security fixes on known dates. Put them in your calendar the day you choose a version. The three you are most likely to run:

• Node.js has changed its schedule: from Node 27 every line becomes LTS and is supported for 36 months from its first Current release. Production should run only LTS lines.
• Python gives each version about two years of bug fixes, then security fixes until five years after release.
• PostgreSQL supports each major version for five years and ships minor releases at least every three months. Minor upgrades need only new binaries and a restart; major ones need pg_upgrade or a dump and restore.
• A cadence that works alone: apply minor and patch updates monthly, on the same day each month. Do one major upgrade a year per component, and never two in the same week, so a regression has one suspect.

A solo founder does not watch dashboards. Set up only signals that arrive by themselves, and make each one rare enough that you act on it.

• Errors by email, grouped. One message per new kind of error, not one per occurrence. If you get more than a few a week that you ignore, fix them or silence them; an inbox you skim is no inbox.
• An outside uptime check on a route that touches the database, every few minutes. It catches what in-app error tracking can’t: the app not running at all.
• Backup alerts. A failed backup should page you the same day. So should no successful backup for two intervals, which is how a job that silently stopped shows up.
• A monthly look at slow queries. With the pg_stat_statements extension, select query, mean_exec_time from pg_stat_statements order by mean_exec_time desc limit 10 is the whole review. Check that your host allows it; on Canner, extensions need the dedicated Postgres instance.
• Skip for now: distributed tracing, custom metrics pipelines, log shipping to a second vendor. They pay off with many services and many people.

If you are weighing a platform against a server you run yourself, PaaS, VPS or Kubernetes compares the three in detail.

• Two languages in production. Every runtime doubles the upgrade calendar above.
• A database you have never restored. Pick a host where a restore is a button or one command, and try it before you need it.
• Building your own auth. Password storage, reset flows and session fixation are well-solved problems; use your framework’s auth or a hosted service.
• Self-running stateful services to save $10 a month. At three to six hours a month for a self-run Postgres, the managed one pays for itself if your time is worth more than a few dollars an hour.
• Microservices for a future team. Hire the team first. A clean monolith splits more easily than a distributed system merges.
• The newest major version on day one. Wait for the first few minor releases; the Node project itself recommends only LTS lines for production.