Skip to content

App takeover and launch · Assessment

We take over your unfinished app and launch it

For an app another developer left “90% done”: a one-week review of what is left before launch, then we finish it. We don’t rewrite the parts that already work.

FormatWritten assessment
Timeline1 week
PricingFixed-price assessment · hourly work
Proof3 case studies

The assessment in 4 parts

01 · Signs you need it

If two of these apply, this is a good fit.

  • The app has been “90% done” for months
  • The developer or agency that built it has left, and you have the code
  • What remains is edge cases, store submission and the work that wasn’t in the plan
  • You don’t know which parts of the existing code are worth keeping
  • The previous developer’s accounts and keys are gone, or nobody knows who has them

02 · What you get

Before any code is changed, the review tells you:

  • What works today. We find that out by running the app, because the repository alone doesn’t show it.
  • What is still missing before launch, item by item, with an estimate for each.
  • For each part of the existing code, whether it is cheaper to keep or to replace, and why.
  • What the App Store and Google Play reviews will check: permissions, privacy declarations, accounts and anything else that commonly gets a submission rejected.

03 · How we decide

STEP 01Working code stays.Rewriting code that works spends time on something you already have, so the hours go to what is still missing for launch.
STEP 02Launch blockers come before improvements.Anything that doesn’t move the app toward launch waits until after it.
STEP 03Nothing people rely on changes without a reason.That covers existing users, their data and any URLs already in use.
STEP 04Store requirements are handled early.Review times, permission declarations and access to the store accounts are outside your control, and they decide the last two weeks, so we start on them at the beginning.
Explained in:A rollback in seconds let us migrate PHP to Node during the dayThree kinds of design system bug that TypeScript and ESLint miss

04 · If we find nothing

If the app is closer to launch than you thought, the review shows the few items left and what each one will take.

Proof

Where we’ve done this before

All 18 case studies
Case study 04 · MarketplaceZero outagesWe inherited a live US marketplace that kept crashing on its hosting. Two months went into stabilizing it, and in four years it never had an outage.Read the case study →Case study 02 · Platforms~100 / 30+A client came back after three years because their Android app could no longer be installed on current devices. It now runs on new and older phones alike.Read the case study →Case study 17 · Business systemsZero deploysWe moved a Swedish SaaS company’s marketing site onto HubSpot CMS, a platform someone else had already chosen, and built the custom forms the client had been told were not possible.Read the case study →

FAQ

Questions about this service

No. We rewrite only what blocks the launch or isn’t safe, and the review lists those parts.
All services47 services, most of them backed by a case study.Back to services →How we decideEach option’s five-year cost and the point where the recommendation changes.See how we decide →

Next step

Describe the problem and we’ll come back with three options.

The first call takes 30 minutes, and you’re under no obligation.

Request this reviewcontact@microtech.consulting