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.

My work on Trans.info showed another boundary, but I would not describe it only as sensible maintenance prioritization. From a management perspective, it was mismanagement: for several years, day-to-day maintenance dominated the decision to plan a migration, and an incremental path was not treated as a real option early enough. A developer needs room to proactively say that a migration can be done in pieces; without that room, an hours package only preserves the current state. When a migration is needed, it needs its own scope and an assessment of smaller, reversible steps rather than the leftovers of an hours package.

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.

A fast application does not always have fresh data

After the first versions of a live product were deployed, we improved image handling and caching. We moved image optimization to WordPress, then also improved how images passed through Next.js and how content was stored in several layers: WordPress, Elasticsearch, and Next.js. Most of the solution remained file-based because expanding the technology stack would have been too costly and was not allowed in that environment. As a result, the server handling the site was very fast.

The post-status problem did not appear immediately. Only after about two years did a side effect of long-lived cached data become visible: some status changes were not refreshed quickly enough. We added mechanisms for forcing a refresh of specific data. They were rarely needed, but the ability to refresh a particular result manually became important.

This does not mean that caching was a mistake. It shows that performance and data freshness have to be designed together. A system can be fast for years and later need an additional refresh path when the editorial process changes.

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.