The article
Every framework under a web app has a date after which its version stops getting security fixes. A portal, a dashboard or a SaaS product keeps working past that date, so nothing looks wrong until a hole is found in that version and nobody will ever patch it. The database, the libraries and every outside service the app calls age the same quiet way.
Our web app maintenance services keep the products your clients and staff log into current and working: updates for the frameworks, the database and the integrations, and fixes when something breaks. The price follows from what we find in the code, so this article shows what we read, what makes an app cheaper or dearer to maintain and what should stay yours, whoever maintains it. Web apps are one of the systems our IT support and maintenance covers, next to websites, mobile apps and servers.
Web app maintenance services: the short version
| Question | Answer |
|---|---|
| What we maintain | Portals, dashboards and SaaS products, the whole stack from the front end to the servers |
| What is included | Updates of frameworks, libraries, the database and the integrations; fixes; answers from the developers |
| How it starts | A code review, then the findings, then a plan with a monthly price |
| Price | Set by the scope agreed after the code review; the first call and the rough estimate are free |
| New features | From the same developers, each estimated before work starts |
Who it fits, and who it does not
It fits a company whose clients or staff log into a web app every day: a portal, a dashboard, a SaaS product or an internal tool in the browser. It fits whoever built the app, because we start by reading the code.
Three cases need something else:
- A website we built on our $499 package. Its upkeep is website maintenance, $29 a month, billed annually ($348).
- A product that needs to grow more than it needs care. That is web application development, from $5,000 for a first version; larger work is estimated before it starts.
- A full security audit. Our code review looks for what is outdated and fragile; a security audit is a service of its own.
Why a web app ages while it runs
A web app ages because everything around it changes while its code stays put. The changes come from four directions:
- Framework versions reach the end of their support. After that date nobody fixes their security holes.
- Outside services retire old versions of their APIs. Payments, messages and sign-in keep working until the day the old version is switched off.
- New browser versions bring out old bugs. Code that leaned on a quirk breaks when the quirk is fixed.
- Every new feature is more code to keep working. A product that grows needs more upkeep each year, not less.
Browsers deserve a word of their own, because owners forget them. In October 2026 I read the five company service pages in Google's top ten for this search: four never mention browsers, and the fifth does so in passing. Yet bugs that live in one browser are real: on RIM International, a variable named top hid the browser's own window.top and took down the whole animation engine, in Safari only. Five pages are a small sample, but the lesson holds: test in the browsers your users have, not only in your developer's.
What our web application maintenance services cover
We maintain the whole stack, not only the code you see:
- The front end in React, Next.js or Vue.
- The backend in Django, FastAPI or Laravel.
- The data in PostgreSQL and Redis.
- Stripe, Twilio and Auth0 when they change their APIs.
- The servers and the deployment behind the app.
The developers who do the work answer your questions directly. Copies of your data are a service of their own, cloud backup, and servers you run for other systems are server maintenance.
Who hears that an API is about to change
The owner of the account hears first. Services like Stripe, Twilio and Auth0 announce the end of an old API version ahead of time, usually by email to the address on the account. If the account was opened by a developer who left years ago, the warning lands in an inbox nobody reads, and you find out on the day payments or text messages stop.
Check whose email sits on each of those accounts and move it to an address your company controls. Updating integrations when these services change is part of our maintenance, and it goes far better when the warning reaches someone.
A web application maintenance plan starts with a code review
We do not quote maintenance for code we have not read. The plan comes together in four steps:
- Code review. We read the code, the tests and the deployment.
- Findings. What is outdated, what is fragile and what to fix first.
- Plan and price. The monthly scope and its price, in a contract.
- Maintenance. Updates and fixes when the app needs them, with a direct line to its developers.
Your part is access to the repository, the servers and the outside accounts, and a call to walk us through what the app does and what hurts today. You see what we found and what maintenance would cost before you sign anything. If the findings say the app needs work before it can be maintained, such as an upgrade of the framework, that work is estimated separately, before it starts.
What we read in a code review
A code review for maintenance answers practical questions:
- Which versions of the framework, the libraries and the database the app runs on, and when their support ends.
- Whether there are automated tests, and whether they still pass.
- How a new version reaches production: one command, or a person copying files to a server.
- Which outside services the app calls, and on which versions of their APIs.
- Where the passwords and keys live, and who can change them.
- How pages and files are cached, so that a fix actually reaches your users. On Kinderstar, phones kept showing stale pages until the HTML stopped being cached and only files with a version in their name were kept for a year.
- What the error logs say, if anyone keeps them.
Each answer moves the price one way or the other. The next table shows which way.
What makes a web app cheaper or dearer to maintain
| What we find | Cheaper to maintain | Dearer to maintain |
|---|---|---|
| Framework version | Supported, with years of fixes ahead | Past the end of its support |
| Tests | Run on every change | None, or failing for months |
| Deployment | A script anyone on the team can run | By hand, known to one person |
| Integrations | A few, on current API versions | Many, on versions about to be retired |
| Documentation | Setup and access written down | In the head of someone who left |
| Errors | Logged and read | Nobody looks until a client calls |
| Changes a month | A handful of small ones | A steady stream of new features |
Forward this table to whoever maintains your app today: every row in the right column is a cost you already pay, only later and at a worse moment. None of the five pages I measured names a price for web app maintenance, and we name ours only after the review; our one fixed maintenance price, $29 a month, billed annually, is for the websites we build.
Web apps we know from the inside
- PBM Source. Compliance software for pharmacy benefit managers: new laws and regulations land on a dashboard as tasks with a summary, a jurisdiction and a date. Under it run Python, Django, React, TypeScript, PostgreSQL, Redis, Celery, GitLab CI and CloudFront, each on its own release schedule.
- RxPhoto. A platform where clinics capture and store patient photos, built for HIPAA work. We worked on the backend, the web front end and the API behind the mobile app, and support the practices that use it every day.
- HirePilot. A product we co-founded and built end to end. Its browser extension fills job applications on forms that keep changing, so upkeep is part of the product, not an afterthought.
- Buhgalteria na doloni. Every request on the site is saved first and only then sent by email and Telegram. When an outside service fails, no client is lost, the kind of design that makes maintenance calmer.
What stays yours
Whoever maintains your web app, three things should never leave your company:
- The code, in a repository your company owns, with its history.
- The accounts: the cloud, the domain, Stripe and every other service, registered to your company.
- The access list: who can log in where. We keep ours written down, so if you ever change teams, offboarding is a list of what to revoke.
Who answers, and where to start
The developers who maintain the app answer, and you write to them directly. Our team is usually seven hours ahead of Miami, so a problem you find in your morning is already in their working day. We have 5.0 on Clutch from 26 verified reviews as of September 2026, and not one negative review.
Show us the app and its code. On weekdays from 9 am to 6 pm Miami time we answer a new request within 30 minutes, and one code review tells us what the app needs and what its maintenance would cost. Mobile apps have a page of their own, mobile app maintenance, and everything else we maintain is under software maintenance.
