Solfreaks AppCare is our monthly maintenance service for apps that are live and need to stay that way. We keep the app working on new versions of Android and iOS, fix what breaks, renew what expires and answer within a response time we agree up front.
An app isn't finished when it ships. The phones it runs on, the libraries inside it and the store rules around it all keep moving, so an app nobody touches slowly goes out of date.
What happens to an app that is left alone for a year
Usually it isn't one dramatic failure but a pile of small ones. A new Android version changes how background work behaves and some users stop getting notifications. A payment or login SDK retires an old version. Google Play raises its minimum target API level, and an app that misses it can no longer publish updates and may eventually stop being offered on newer devices. A server certificate or an Apple push certificate expires on a Sunday, and the app stops talking to its backend.
Each of these is a small job when it's dealt with on time, and an expensive one when a year of changes lands at once under a deadline. That is how people end up asking about a rewrite. Our legacy app revamp service exists for that case, but it's cheaper for everyone if you never need it.
What a plan covers
- OS compatibility. We test against new Android and iOS releases before they reach most of your users and fix whatever changes.
- SDK and dependency updates. Libraries, Firebase, payment and ad SDKs are kept current in small steps, with a note on anything that changes behaviour.
- Crash monitoring. We watch Crashlytics or Sentry and fix the crashes hurting the most users first. If you have no reporting yet, we add it, much as in our analytics setup work.
- Store deadlines. Target API levels, data safety form changes and policy emails are tracked, so none of them arrives as a surprise.
- Renewals. Server updates, SSL certificates, push credentials, domains and developer-account fees go on a calendar that somebody actually reads.
- A bank of hours. Each month includes time for small improvements, such as a text change or a tweaked screen, which you queue and we work through in order.
- Written response times. Each tier states how fast we acknowledge a problem and how fast we aim to fix it, by severity.
Basic, Standard and Priority
The tiers differ mostly in response speed and in how many hours you get to spend. Basic is monitoring, compatibility work and renewals, for a stable app that isn't changing much. Standard adds a bank of hours and quicker fixes, and suits an app that is still evolving. Priority has the shortest response times, including urgent production issues, and fits an app whose downtime costs you money directly. We'll recommend the lowest tier that covers your real risk.
How we take over an app
- Look under the bonnet. We review the code, the dependencies, the crash history and the store listing, usually in a few days to a week. If we didn't build the app, we need repository and store access first.
- Fix what's urgent. Anything about to expire or break is handled before the plan starts.
- Put monitoring in place. Crash reporting, alerts and a release checklist, plus automated builds where there aren't any yet.
- Run the monthly rhythm. Compatibility checks, updates, the hours queue, and a short note each month on what we did and what's coming.
- Review every quarter. We check whether the tier still fits. Sometimes the answer is to move down.
Who should skip a maintenance plan
Plans fit apps with real users or revenue and no in-house developer, apps built by an agency that has since moved on, and companies that want one named contact for the technical side.
If the app is a prototype nobody uses yet, or you have developers on staff who already do all of this, it's probably not for you. It's also the wrong tool for a large new feature, which is a project with its own scope. And if every fix breaks something else, we'll say so after the audit and suggest repairing before maintaining.
Pricing and timelines
The monthly fee depends on the tier, on one platform or both, on the size and age of the codebase, on how many third-party services it relies on and on the response times you need. A clean, modern Kotlin or Swift app costs less to look after than an old one sitting on abandoned libraries. We offer a monthly plan with a set number of hours, or a smaller retainer with extra hours billed as used. The quote follows a short discovery call and a quick look at the app. Onboarding typically takes one to two weeks.
Why leave it with us
The console, the policy emails and the review process are things we deal with ourselves, because we've published apps on Google Play from our small office in Rawalpindi. You talk to the people who do the work. Your code, repository and developer accounts stay in your name. If you're unsure which tier makes sense, describe the app to us and we'll say what we'd do.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- renovatebot/renovateAutomated dependency update pull requests.
- getsentry/sentryError and performance monitoring.
- dependabot/dependabot-coreThe engine behind GitHub's Dependabot updates.
Frequently asked questions
Can you maintain an app that you didn't build?
Yes, after a short audit. We ask for the repository, store console access and crash dashboards, read through the code and tell you what state it's in. If it's in decent shape we start the plan. If it isn't, we say so and suggest a repair phase first. We can't maintain an app without its source code.
What counts as urgent, and how fast do you respond?
Each plan defines severity levels. An app that crashes on launch or a broken login or payment is urgent. A misaligned button is not. Response targets get shorter as you move up the tiers, and we write them into the agreement for your platform instead of quoting a number here. We always say how long we think a fix will take before starting.
What if we need a new feature as well as upkeep?
Small changes come out of the monthly bank of hours. Anything larger is scoped as a separate piece of work with its own quote, so maintenance time isn't quietly eaten by a feature build. If you want a developer on the app regularly, a Priority plan or a dedicated developer may suit better than a Basic one.
Who pays for servers, Firebase and developer accounts?
You do, directly, and the accounts stay in your name so you can see every bill. Our fee covers our time, not third-party charges. We'll tell you when a renewal is coming, such as the yearly Apple Developer Program fee or a cloud plan change, so it never lapses unnoticed.
How long can an app go without an update?
There's no single safe interval, which is why plans exist. In practice the platforms force at least one change a year, such as a new target API level or SDK requirement, and a gap longer than that tends to compound. Apps with a lot of server dependencies or ad SDKs go stale sooner than a simple offline tool.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
