How many developer hours does an application need each month?

What does a 10–20 hour monthly package actually provide?

A small package fits recurring work that does not require a full-time developer: updates, bug review, small integrations, consultations, code review, backlog organization, and a few hours of development. A 10–20 hour range is not a market standard or research result; it is a practical model to test against a specific backlog. At TreeTank, reserved availability starts at 20 hours per month; smaller needs can be handled ad hoc.

The value may not be only lines of code. The developer keeps application context, remembers earlier decisions, can spot risk sooner, and does not need to learn the system from zero each time. This is an observation from the engagement model, not a promise that every package hour automatically saves a fixed number of owner hours.

• good scope: recurring backlog, updates, small fixes, consultations, and review;
• poor scope: several large features without priorities;
• different product: on-call support, SLA, and response outside agreed hours.

A package is not a project or on-call support

If one large feature takes several months, name it as a project with scope, estimate, and limit. An hours package works for small tasks but can hide a larger project when every conversation starts with a different priority and nothing gets finished.

24/7 support requires response times, backup capacity, monitoring, and escalation. Several hours per month can prepare an application for calm maintenance, but they are not a promise that someone is available at every minute of an incident.

AI speeds up work but does not remove maintenance

AI can speed up log analysis, finding change locations, writing tests, documentation, and small fixes. It does not remove review, dependency updates, production observation, backups, or the decision that a change actually matches the business process.

DORA 2025, based on answers from nearly 5,000 professionals, found a positive relationship between AI adoption and delivery throughput and product performance, and a negative relationship with delivery stability. That is a statistical relationship, not proof that AI itself causes instability. In METR’s early-2025 experiment, 16 experienced developers completed 246 tasks; with AI allowed, tasks took 19% longer on average, with an uncertainty interval from 2% to 39%. The result concerned large open-source repositories and a specific tool set, so it is not a universal saving or a rate card. Honest billing should cover needed work and outcomes, not imaginary manual actions a tool did not need to perform.

Custom software or SaaS? Count the full life cycle

Custom software can be worthwhile for a specific, repeatable process that ready-made tools cannot represent well. SaaS usually wins for a standard problem, fast start, and ready-made updates. Eurostat reports that 52.7% of surveyed EU enterprises used paid cloud services in 2025; among cloud users, 26.1% used platforms to build, test, or deploy applications. The second number is not a share of all enterprises.

Compare a horizon that matches the planned life of the solution; a working 24–36 month model helps expose costs but is not a universal threshold. Include subscription, users, limits, data export, integrations, training, manual work, updates, backups, monitoring, provider change, and author replacement. Custom software makes sense when it repeatedly saves time, reduces risk, or gives control that cannot be bought — not merely because its first version can be generated quickly.

Maintenance starts before handover

A prototype or new application is easier to maintain when it has a README, data description, configuration example, dependency list, deployment process, backup, logs, and a section listing limitations. In Eurostat’s 2024 data, 93% of surveyed enterprises used at least one ICT security measure and 79% stored a backup separately; these are reported practices among the surveyed enterprises, not an audit of backup quality. They still show why recovery belongs to basic hygiene rather than post-incident work.

The same applies to design. SEI describes a design system as a reusable source of truth with components and patterns. The practical benefit is fewer repeated decisions when adding pages, although there is no basis for promising one universal percentage saving. Ask another person to run the project cleanly. If they need the author for every step, the system is not ready for calm maintenance.

Good documentation does not pretend risk is absent; it shows where the risk is and how to respond.