Here’s a pattern we see often enough that we could set a clock by it: a founder raised money, hired a freelancer or a cheap agency to build the MVP, got something that demoed fine in a pitch deck, and then watched it fall apart the moment real users touched it. Six months and a chunk of the seed round later, nobody on the team can tell you why the app crashes on Android but not iOS, the backend has three different authentication systems bolted together, and the original developer has gone quiet. If that’s you, the question isn’t “can this be fixed” — almost everything can be fixed. The real question is how long it takes and what it costs to find out. Here’s the actual timeline we’d run, not a marketing version of one.

Days 1-10: Triage, not a sales pitch

Before we write a line of code, we spend the first one to two weeks doing a full audit of what exists. This isn’t a courtesy call — it’s the part of the process that determines whether “rebuild” even means the same thing to us as it does to you. We’re looking at:

  • What runs, what crashes, and under what conditions — not what the previous team claims works
  • How the codebase is structured: is this a few bad decisions in an otherwise sound app, or is the architecture itself the problem
  • Where the security gaps are, especially around auth, data storage, and any third-party API keys sitting somewhere they shouldn’t
  • What’s genuinely reusable versus what needs to be rewritten from scratch

At the end of this phase you get a written breakdown, not a verbal reassurance: a list of specific issues, which ones are blocking launch versus which are annoyances, and a real estimate for fixing each. If the honest answer is “this needs six months, not ninety days,” we tell you that here, not after you’ve paid for two months of work. We’d rather lose the engagement than string it along.

Days 11-45: Stabilize before you add anything new

This is the phase founders want to skip, and it’s the one that determines whether the rebuild sticks. Before touching a single new feature, we get the existing product into a state where it behaves predictably — same input, same output, every time, on every device you actually ship to. In practice that means:

  • Fixing the crashes and race conditions that make the app unreliable, which is almost always where the real engineering time goes on a stalled build
  • Untangling backend logic that’s grown organically without a clear data model, so the admin console and the app aren’t fighting each other
  • Closing the security gaps flagged in triage — this is non-negotiable if the app touches user data or payments
  • Setting up a basic deploy and testing process, even a lightweight one, so “it works on my machine” stops being a risk

We treat this phase as the foundation the rest of the 90 days is built on. Skipping it to chase visible features is exactly how the app ended up broken the first time.

Days 46-80: Rebuild the parts that were actually the problem

With a stable base, we rebuild — but only the parts that need it. A rebuild doesn’t mean throwing out working code because it’s unfamiliar; it means replacing the pieces that were structurally wrong, whether that’s a Flutter app that never should have avoided native modules for camera or payments, a backend with no clear separation between business logic and API routes, or an AI feature that was wired in without any thought to cost, rate limits, or what happens when the model returns something unexpected. We’ve built and shipped consumer apps ourselves — Crumb Count and Kompete both went from nothing to production — so this phase runs on the same standard we hold our own products to: does it hold up under real usage, not just a demo.

Throughout this stretch you’re not waiting for a big reveal at the end. You get working builds on a regular cadence, direct access to the two of us actually writing the code (not a project manager relaying updates), and a running list of what’s done versus what’s still in progress.

Days 81-90: Ship, document, and hand over control

The last stretch is about making sure you’re not dependent on us to understand your own product. That means documentation that a new developer could actually use, a clear map of what was rebuilt and why, and a known list of anything we didn’t get to — because on a genuinely broken MVP, ninety days won’t fix everything, and pretending otherwise is how you end up back in this exact situation a year from now. You should leave this phase with a product that works, and a clear-eyed view of what’s next.

What determines if 90 days is realistic

Three factors decide whether this timeline holds: how much of the existing code is salvageable versus needing a full rewrite, whether the core data model is sound or needs restructuring, and how much scope you’re trying to add alongside the fix. A rebuild that’s purely “make what exists actually work” fits comfortably in 90 days. A rebuild that’s “make it work and also add the three features we always wanted” usually isn’t a 90-day project, and we’ll say so upfront rather than let the deadline slip quietly.

This is roughly the process we run whether the engagement starts with an audit, a full rebuild, or just a second opinion on whether a codebase is worth saving. If you’re sitting on a stalled build and want a straight answer on where it actually stands, that’s a conversation we’re glad to have before any commitment is made.