Shipping Alone: What Is Safe to Skip

The core trade-off of solo maintenance

The solo developer workflow is defined less by what you build and more by what you refuse to build. It is a discipline of subtraction, where every hour spent on infrastructure is an hour not spent on product features or content. When you are the only person maintaining the stack, the goal is not to mimic enterprise architecture, but to minimise the surface area that can break. You do not need a microservices mesh if a single Node process can handle the load. You do not need a distributed database cluster if one PostgreSQL instance fits in memory. The safety of skipping a practice depends entirely on whether its absence creates a single point of failure that you cannot repair alone.

What actually pays for itself

Some practices remain essential even when the team size is one. Automated TLS certificate renewal is the first. Managing Let’s Encrypt certificates manually is a time sink that offers no value. Caddy handles this automatically, terminating TLS for every site. This removes a recurring administrative burden that would otherwise consume significant mental bandwidth. Similarly, using systemd oneshot services with timers for scheduled work is superior to cron. Cron is stateless and opaque; systemd provides structured logs and dependency management. If a job fails, the system reports it clearly. For a single maintainer, observability is not a luxury; it is the only way to know something is wrong before a user does.

Static builds are another high-value practice. Serving static files from disk requires no server process and no database connection. It is the most reliable way to serve content because there is nothing to crash. The fewer moving parts in the request path, the higher the probability that the site remains available. This approach reduces the cognitive load of debugging. When a page loads, you know exactly where the file came from. There is no server-side rendering logic to trace, no database query to inspect. The system behaves predictably because it is simple.

Practices that become cargo cults

Many standard practices in larger teams are designed to manage coordination overhead, not technical complexity. When that overhead disappears, the practices often become liabilities. Complex CI/CD pipelines with multiple build stages are a prime example. If you are the only one pushing code, a long pipeline introduces latency without adding safety. A simple build and deploy script, run locally or via a basic remote trigger, is often faster and easier to debug. The time spent configuring and maintaining a sophisticated pipeline exceeds the time saved by automation. In a solo context, the bottleneck is human attention, not machine speed.

Over-engineering the data layer is another common trap. Splitting a database into multiple instances for different microservices adds network latency and transactional complexity. If your applications can share a single database instance, do so. The risk of data inconsistency is lower than the risk of operational failure. Similarly, introducing message queues for tasks that can be handled by synchronous execution or simple timers is often unnecessary. Queues add persistence and ordering guarantees, but they also add state that must be monitored. If the task is idempotent and low-frequency, a timer is sufficient. The goal is to reduce the number of stateful components that require attention.

Applying this to the current stack

The current setup reflects these principles. One Next.js process serves four sites by host-based routing. This consolidates the runtime environment, reducing the number of processes to monitor. The memory footprint is manageable because the workloads are distinct but share the same base. Instalaz runs as a separate Node process, proxied by Caddy, because its specific requirements justify the isolation. However, it shares the same PostgreSQL 16 database as the Next.js app. This avoids the complexity of data replication while keeping the data source consistent. The decision to keep them separate processes rather than separate databases is a trade-off. It accepts a shared dependency in exchange for operational simplicity. If the database goes down, everything goes down. But that is a risk that is easier to manage than the risk of data divergence between isolated systems.

GamingCap and Invoiceful are static builds. They have no server process and no database. This is the ideal state for a solo developer. There is nothing to patch, no runtime to update,