Software Maintenance & Support: We Take Over Your Product and Keep It Moving.

Everything that keeps a live product working, secure and changeable: crash and error triage, hotfixes, security updates, OS, SDK and framework upgrades, app-store compliance and submissions, certificates, release management, CI and the bug backlog, plus small features. At Trembit this runs as a monthly engagement with the same engineers on your product. Larger features are scoped separately or handled by a dedicated team.

In four steps. First, a 30-minute technical call. Then an NDA and read access to the code. Next, a free Takeover Assessment: about two hours in which a senior engineer reads the code and reports the risks, the upgrades due and the recommended path. Finally, onboarding, from one day to a week depending on the product, in which we set up environments and take over releases. The product keeps shipping throughout. When we took over Learnster from its previous team, the full transfer took one week.

That’s the normal case, not the exception. We work from the code itself, the build and deploy setup, crash reports and ticket history, and we write the missing documentation as we go: setup, deploy, configuration and the decisions behind them. If the previous vendor is still reachable, a short handover call saves time. It isn’t a precondition.

Onboarding takes from one day to a week, depending on how complex the product is: how many apps and platforms are in scope, and the state of the build and release process. After that, releases are ours. Even a stalled product that needed a whole new team moved quickly: Learnster’s full project transfer took one week.

We don’t sell a one-size SLA. We agree severity tiers with you, based on what’s critical for your product: a broken purchase flow, a store removal notice, a crash spike after a release. Then we agree how each tier is handled and the coverage hours that overlap your team’s day. Many products need disciplined release management far more than round-the-clock cover. Coverage beyond the agreed hours is scoped explicitly.

Not by default. Most of the value in an existing product is code that works, and rewriting it adds risk without adding features. The assessment recommends one of four paths: maintain as is, stabilize then maintain, modernize specific parts, or rebuild. A rebuild comes with the evidence for why. If keeping your current team is the cheaper option, the assessment says that too.

Yes, one part at a time. We upgrade frameworks and SDKs in steps, refactor the modules that cause most defects, replace deprecated third-party services, and add tests and monitoring before touching risky areas, so the product keeps releasing throughout. This is modernization inside one product we maintain. A program that modernizes several systems or re-platforms the business is digital transformation.

Yes. A common split is that we own maintenance, upgrades and releases for some apps or platforms while your team builds features. Scope boundaries are written down, for example “mobile apps in scope, backend with your team”. Your tech lead talks directly to ours, both teams work in the same Slack channel and board, and documentation stays current so either side can pick up the other’s work.

It depends on what the assessment finds. The main cost drivers are how many apps and platforms are in scope, how far dependencies and OS targets have fallen behind, how often you release, the coverage hours you need, compliance requirements, and how much feature work you expect. Support is usually a monthly package sized for continuity, with extra work approved in advance. We quote after the assessment, never before reading the code.

You own it. All source code, documentation, architecture diagrams and intellectual property transfer to you, and we can work under your preferred IP agreement. We sign an NDA before you share anything, plus a GDPR DPA or a HIPAA BAA where relevant. Documentation and knowledge transfer are part of every engagement, so moving the product in-house is a planned step.