Building software is one decision. Maintaining it is another.

Building software creates a working version of an idea; maintaining it means keeping its promises as users, data, dependencies, and circumstances change. A solo founder should budget for both before turning a prototype into a service people rely on.

The first build has a visible finish line. A button works, a demo loads, a form saves. Maintenance is less tidy. A dependency changes, an account needs access removed, an integration becomes unreliable, or a user discovers a case the original demo never covered.

That does not mean launching should be slow. It means deciding what you are willing to operate, rather than treating operation as an unexpected penalty after shipping.

List the promises hidden inside the product

An ordinary feature can contain several promises. A saved document implies that the customer can find it again. A shared workspace implies that permissions mean something. A recurring notification implies that the system can tell whether the notification was sent.

For each important feature, write the ongoing responsibility in a second column. 'Upload files' becomes 'protect, locate, recover, and delete files under the stated policy.' 'Connect an account' becomes 'handle access expiry, changing permissions, disconnections, and incomplete updates.'

This exercise often changes what belongs in an early release. A feature that takes one afternoon to demonstrate may take a disproportionate share of your future attention.

Google distinguishes repetitive toil from lasting improvements. Read the chapter. Decide which recurring tasks to prevent, simplify, or consciously price into your offer.

Separate routine care from exceptional response

Routine care includes reviewing dependencies, checking important jobs, managing access, verifying backups, answering ordinary questions, and updating documentation. Exceptional response includes incidents, corrupted information, unexpected service changes, and urgent customer problems.

You cannot predict every event, but you can decide who notices and what happens next. A simple operating checklist is more useful than a vague commitment to keep an eye on things.

Write down the smallest customer-visible workflow worth protecting. For a booking tool, that might be accepting an appointment and preserving its status. A decorative dashboard may be less important. Allocate maintenance attention according to consequences rather than which part of the code is most enjoyable to improve.

A hypothetical example: an onboarding portal

Imagine a founder builds an onboarding portal for small agencies. The prototype takes a week and looks convincing. A pilot customer then asks whether its freelancers can upload contracts while seeing only their own files.

That request changes the operating responsibility. Access needs to be enforced across account boundaries. Invitations expire. A project manager leaves. Somebody uploads the wrong file and asks for deletion. The portal now contains business information the customer expects to be handled carefully.

The founder could narrow the pilot to a safer workflow, bring in qualified engineering help, or implement and verify the necessary controls before expanding access. Shipping the interface and hoping the permissions are correct is not a maintenance plan.

This is a hypothetical scenario. Its purpose is to show how a feature's real cost emerges from its use, not to suggest that every onboarding product requires a large engineering team.

A backup is a responsibility, not a checkbox

A service can report that backups exist while leaving the founder uncertain about restoration. What information is included? How recent is it? What credentials are required? Could restoring old state overwrite something important?

PostgreSQL's documentation describes several backup approaches with different strengths and weaknesses. See the official backup and restore overview. Your chosen infrastructure may differ, but the need to understand recovery remains.

For the founder's operating plan, record who owns restoration, where instructions live, and how recovery is verified in an appropriate nonproduction setting. Do not promise a recovery window that has never been tested.

The counterargument: overengineering also has a cost

Maintenance planning can become an excuse to postpone contact with users. A personal prototype with no important data needs a different level of care from a paid service handling a customer's operations.

Use a consequence-based boundary. What happens if this feature fails? Can the customer continue manually? Can lost work be recreated? Does the product make a consequential external change? The answers should determine the safeguards and the launch scope.

You can often reduce obligations by offering less: fewer integrations, a read-only starting point, limited file types, or a clearly scheduled manual service. Simplicity is an operating strategy when it preserves the outcome customers actually need.

A maintenance map for your next release

Create a row for each important workflow and fill in:

1. The customer promise in plain language.
2. The routine care it requires.
3. Its external dependencies and access owners.
4. The signal that something has gone wrong.
5. The manual fallback or recovery path.
6. The person responsible when you are unavailable.
7. The monthly time and cash you are willing to spend.

If a row has no owner or affordable fallback, reconsider the scope. The goal is not software that never needs attention. It is a business whose ongoing responsibilities you understand well enough to sustain.