A solo founder's maintenance budget should reserve both cash and protected time for keeping the existing service dependable. Start with your actual workload, include interruptions and support, and adjust new feature commitments when recurring obligations no longer fit.
There is no reliable universal percentage that every early startup should spend on maintenance. Products differ in their customers, dependencies, information sensitivity, and operating model. A budget becomes useful when it makes those responsibilities visible, rather than borrowing a fashionable ratio from another company.
Start with available capacity, not an ideal week
Write down the hours you can sustainably give the business. Include sales, customer conversations, administration, and time away from work. Avoid treating every evening as emergency capacity that is somehow free.
Now list the work needed to keep the current promise: support, dependency care, access administration, failed-job review, backups, billing questions, and recurring manual operations. Some items will happen rarely. Record that uncertainty rather than omitting them.
Google describes repetitive operational toil. Read its explanation. Borrow the concept, not its staffing model. Measure your own obligations before choosing an allocation.
Two weeks of honest notes may be more useful than a detailed annual forecast built on guesses.
A hypothetical weekly budget
Consider a founder who chooses a sustainable 36-hour working week. This is an illustration, not a recommended schedule. They reserve 10 hours for sales and customer learning, four for administration and planning, and six for expected maintenance and support.
That leaves 16 hours before allowing for unexpected work. If they reserve four hours as a buffer, the realistic feature-building capacity is 12 hours, not 36.
Now suppose support and routine operations actually consume 11 hours for two consecutive weeks. The founder has not become five hours less motivated. The business has a capacity problem. They can reduce feature commitments, simplify the service, improve the recurring issue, adjust the offer, or obtain appropriately scoped help.
The numbers are deliberately hypothetical. The important calculation is available time minus existing obligations minus a sensible uncertainty allowance. Only the remainder should support new promises.
Keep cash and attention separate
A managed service may reduce operational work but add a recurring bill. A cheaper infrastructure choice may increase the time required to operate it. Neither choice is inherently better.
Create two columns. Cash includes hosting, databases, monitoring, email, external APIs, and paid assistance. Time includes supervision, support, updates, recovery exercises, and changes caused by those providers.
Do not convert every founder hour into a pretend salary and call the result a precise cost. You can use an opportunity-cost assumption when comparing options, but label it as an assumption. The more immediate question may be whether a task displaces the customer conversations the company needs to survive.
Review external dependencies regularly. Anthropic's official documentation, for example, explains that older models can be deprecated and retired, requiring application updates. The general lesson is to budget for provider changes rather than assuming a working integration stays unchanged. See the lifecycle documentation.
Classify work before trying to automate it
A recurring task may be necessary service work, a preventable defect, a temporary learning activity, or a feature disguised as maintenance. The response should depend on which it is.
If customers repeatedly ask the same setup question, clearer onboarding may help. If a job repeatedly fails for the same reason, repair the cause. If manual review teaches you about unknown cases, retain it deliberately for a defined period. If an enterprise account needs extensive bespoke reporting, price and scope that work explicitly.
Automation also consumes maintenance. A script that saves an hour but requires frequent debugging may not be the best use of a constrained week. Count the supervision it creates, not only the clicks it removes.
The failure mode: buffers becoming permanent overtime
A buffer is for variation, not a place to hide predictable work. If it is consumed every week by the same activity, move that activity into the baseline and reduce the planned feature load.
Likewise, one quiet week does not prove you can add another critical integration. Look at the pattern, the consequences of failure, and the upcoming commitments. A new customer may change the workload more than their account count suggests.
There is a counterargument worth taking seriously: too much scheduling can become administrative overhead. Keep the system lightweight enough to use. A short weekly review and a simple table are often sufficient at the beginning.
Your weekly maintenance worksheet
Create a table with these columns: task, reason, frequency, expected minutes, actual minutes, cash cost, owner, and next improvement. Group the tasks by the customer promise they protect.
At the end of the week, answer:
- Which obligation consumed more time than expected?
- Was the work recurring, exceptional, or avoidable?
- Which feature commitment should change because of it?
- What one improvement could reduce repeated work?
- Can the service still run within a sustainable week?
The budget is doing its job when it changes a decision. A spreadsheet that says everything fits while you work every night is not a plan. It is an unrecorded subsidy.