Engagement model
It shipped. Now it needs someone to run it.
Your product is already in the store with real users, and the team that built it is gone, moving on, or was never meant to run it long-term. We take over the parts that keep a live product alive — uptime, bug fixes, releases, store review cycles — and, where you want it, the growth work that turns existing users into more of them.
What taking over a live product looks like
- —A short audit first — codebase, infrastructure and store standing — before we touch anything in production
- —On-call coverage and a release cadence, so bugs and store updates aren't waiting on whoever's free
- —Store listing, review responses and the submission/review cycle kept current, not left to lapse
- —Growth work — App Store/Play Store optimization, retention, funnel fixes — scoped separately from keep-the-lights-on work
What's usually in scope, and what isn't
- —In scope: stability, releases, store compliance, and a written map of the system before we change anything load-bearing
- —Growth strategy and execution, if you want it — priced and scoped apart from maintenance so you're never paying for one to get the other
- —Deliberately out of scope unless you ask for it: a full rewrite — we work with what's live, not replace it by default
- —A monthly note on what changed and why, the same as every other engagement shape here
Questions people ask.
That's the normal starting condition, not an edge case. The audit exists to rebuild the missing picture — codebase, infrastructure, store standing — before we touch production, so nothing changes based on guesswork.
Both, but priced apart. Keeping a product stable — uptime, releases, store compliance — is one scope. Growth work is a separate one you opt into, so you're never paying for effort you didn't ask for.
Code, repository and IP are yours on this engagement shape the same as every other one. If you build an in-house team later, handover is a transition, not a negotiation.