Petadev maintains live mobile apps, fixes bugs and runs the backend systems behind them. We work with apps we built ourselves and apps taken over from other teams. At the start, we assess the system, then agree on the tasks, the responsibilities and the terms of support.
30+ apps
released with React Native
Since 2022
continuously developing and running Trinity Guard
iOS + Android
updates and app store releases
The app's current condition determines whether we first need to fix bugs, catch up on missed updates, or can move straight to regular support.
We review the app's framework, dependencies and platform-specific settings. After the necessary update, we check the affected flows and prepare the new version for release. In a React Native upgrade, besides the JavaScript packages, parts of the iOS and Android projects may also need changes.
We manage the versions that go to the App Store and Google Play, the test releases and the store settings. An update can become necessary even if nothing in the app has changed: Google Play raises the Android version that new apps and updates must target every year, and Apple regularly requires uploaded builds to be made with recent Xcode and SDK versions. We track these deadlines so future updates meet app store submission requirements.
First we look at when and under what conditions the problem occurs. The device model, the app version, the network or the status of a third-party service can all matter. After the fix, we check the affected functionality and the important flows connected to it.
Support can include managing the backend services, the database and the server environment. We agree separately on what the system monitors, where alerts go and who acts when there is a problem. Hosting or cloud service fees and the operations work are billed as separate items.
We document which data needs backing up, where backups can be stored and which recovery requirements they have to meet. The agreement sets out who is responsible for checking the backups and testing a restore, and how these tasks are scheduled.
New features are estimated and scheduled separately. This keeps maintaining the existing app and growing the product easy to track, and the cost of a larger development request doesn't get mixed up with regular maintenance.
We have been working on Trinity Guard since late 2022. Besides the mobile app, the web interface and the backend, we also handle the infrastructure and ongoing development.
The system runs in three separate environments: two AWS regions and a dedicated server in Budapest. Each environment has its own application data, and we roll out updates region by region. This means concrete operational work, and it is not the same as a system with a shared database where environments automatically fail over to each other.
1We get to know the app. We talk through how it works, the current problems and which processes are critical for your business.
2We review its technical state. We look at the source code, the versions, the backend, the integrations and the available documentation. We clarify how to create a test build and how to release a new app version.
3We define the first steps needed. We separate the work required for the handover or stabilization from the regular tasks that come later. If access or important information is missing, that has to be sorted out first.
4We agree on the scope of support. We document the tasks we take on, the responsibilities of the client and the development team, how to report issues, and how billing works.
5We handle changes as agreed. Before fixes and updates, we consider the expected impact, the testing needs and the release conditions. New business requirements can get a separate development plan.
Which systems are we responsible for?
Exactly which parts: the mobile app, backend, database, infrastructure and third-party integrations.
When and how is support available?
Points of contact, support hours, urgency levels and the response time we can commit to.
How do we prioritize issues?
We agree on severity levels that distinguish a full outage or a revenue-impacting bug from a minor visual issue.
What does the fee cover?
Regular tasks, ad hoc work, separately priced development and third-party service costs.
Who manages access?
Permissions for the source code, app store accounts, cloud, domain and integrated services.
How do we manage releases?
The steps for testing, approval, deployment and, if needed, recovery.
The maintenance fee is set based on the state of the system and the support we take on. Response time refers to our reply to a report; the time to resolve an issue also depends on its cause and the work needed.
Tell us which app you need a support partner for and what started your search: a specific bug, missed updates or a long-term partnership. We will talk through what needs to be assessed to decide the next step.
For a new product, see our mobile app development services. If you want to learn the basics of running an app first, read our guide to app maintenance after launch.
Yes, after a technical review. We mainly take over React Native mobile apps, Node.js backends, React or Next.js web interfaces and PHP backends. Our article on taking over an app explains what to watch for when you switch developers and how our handover process works.
Only if we have agreed on it separately. Running the backend and maintaining the app installed on users' phones are different tasks. The agreement has to name who is responsible for each.
Operating systems, developer toolkits and connected services can change. Because of this, an app whose features stay the same may still need changes. The work should be defined by how a given change actually affects the product. We don't think a startup should pay a fixed monthly fee when there is no real work to do. Development work within maintenance is scoped and priced per project, before it begins. Any recurring tasks, such as monitoring or backups, and their fees are defined in the support agreement.
Not necessarily. A requirement that affects submitting a new version has different consequences from an actual malfunction. The wording of the warning, its deadline and the state of the app have to be reviewed together.
It depends on the cause of the bug and the terms of the contract. Fixing our own implementation where it deviates from the agreed specification, adapting to a change in an external system and building a new feature are different kinds of work. To classify it, we first need to know the cause of the problem. For an app we take over, we warrant our own work. We cover the existing code only if the engagement starts with a contract and a targeted code review, and then only for the parts and under the terms set out in the contract.
The app's store link, a short description and the current problem are a good starting point. If you know them, include the technology, when the app was last updated, and whether the source code and the previous developer are available. Don't send passwords or access keys through the contact form.