We Launched and It Keeps Going Down: What to Do in the First Two Weeks

If your app keeps going down after launch, the next two weeks have a known order: stop changing it, find out the moment it breaks, make sure you can get your data back, and only then decide whether to stabilize what you have or rebuild part of it. Most young apps go down for a short list of ordinary reasons, and most are fixable without starting over. This guide is for the founder who is not technical, is getting messages from customers, and wants to know what to do tonight, this week and next week.

Is it normal for a new app to keep going down?

Yes, because launch is the first time the app meets real traffic, real data and people doing things nobody tested. One sentence we hear from founders at this point: “It fell over once already. I don’t know why, or if it’ll happen again.” That is a normal moment, not a verdict on you. What is not normal is outages nobody can explain, and that visibility problem is the first thing to fix.

What should we do in the first 48 hours?

In the first 48 hours, freeze non-essential changes, put monitoring and error tracking on the app, prove you can restore your data, secure every account, and start a written log of every outage. None of this requires knowing what is wrong yet.

• Freeze changes. Google’s SRE book states that roughly 70% of outages are due to changes in a live system. Until the outages stop, only fixes for the outage go out, one at a time, each written down. Features wait two weeks.
• Get told before your customers tell you. Set up an outside uptime check that loads your app every minute or so and texts a named person when it fails.
• Turn on error tracking. It records every crash with the page, the user action and the line of code involved. Usually the same few errors account for most of the pain.
• Prove you can restore, not just back up. Find the newest backup, restore it to a separate copy and look at the data. Google’s SRE book puts it plainly: no one really wants to make backups; what people really want are restores. AWS’s reliability guidance says to validate your backups by performing a recovery test.
• Secure the keys. List every account the app depends on: hosting, database, domain, code repository, payments, email. Make sure the company, not a departed developer, owns each one. If passwords or API keys sit in the code, rotate them. OWASP notes that many organizations have secrets hardcoded within the source code in plaintext.
• Keep an outage log. For every incident: when it started, what users saw, what changed in the hour before, what brought it back. Keep it blameless, as Google’s postmortem practice does, focusing on contributing causes without indicting any individual, because people hide information from a log used to assign blame.

What usually causes repeated outages in a young app?

Repeated outages in a young app almost always trace back to one of seven causes, and six of them are fixable without a rebuild.

Each row has a public source. PostgreSQL documents that its default connection limit is typically 100, and AWS warns about oversubscribing connections or new connections being created at a fast rate during surges. Without an index, the PostgreSQL manual says, the database would have to scan the entire table, row by row. Google’s SRE book says the most common cause of cascading failures is overload. The OWASP Top 10 for 2025 added Mishandling of Exceptional Conditions, which it says leads to crashes and unexpected behavior. And Let’s Encrypt issues its certificates for 90 days by default, so one set up by hand at launch expires about three months later.

How do we find out which cause it is?

You find the cause by lining the outage log up against the clock and four numbers, not by reading the code first. Google’s SRE book calls them the four golden signals: latency, traffic, errors, and saturation. Saturation is how full your tightest resource is. Then look for the pattern:

• Outages start right after a release. A change problem. The freeze helps now, a rollback path fixes it for good.
• Outages track busy hours. Capacity: connections, slow queries or overload.
• Outages hit at the same time every day or week. Something scheduled: an import, a report, a batch email.
• Outages are random and a restart fixes them. Unhandled errors or memory filling up.
• Each fix holds for a while, then it breaks elsewhere as you grow. That points at the design, and it is worth paying an engineer to assess properly.

My app was vibe coded and now I am scared to make changes. What do I do?

Treat the fear as accurate information: the app has no safety net, so build one before you make more changes. Make change boring again, in this order: a staging copy where changes are tried first; automated tests on the paths that touch money and data (signup, login, payment, anything that writes); and a deploy path where a bad release comes back out in minutes. Our prototype to production page states the goal in one line: shipping a change is a routine, repeatable step, not an act of courage.

AI-built apps tend to work for the person who built them and leave out what nobody asked for: an access model, error handling, tests, a deploy process. Our vibe-coded app hardening page lists what usually needs adding.

Our developer left and nobody understands the code. Who can we hire?

You can hire an engineer or a firm that takes over code someone else wrote, and the original developer’s absence matters less than it feels. Most of what a new engineer needs is in the code, the data and the infrastructure. You supply the business context: what the app should do, what customers depend on, and what breaks most often. First, make sure a developer who left does not still own the hosting account or the domain. Then match the hire to what you have in-house:

• You have a technical person on your side. A vetted freelance engineer is usually cheapest and fastest, because someone can judge the work.
• You have nobody technical. Hire for ownership, not hands. See what to hire when you have no technical cofounder.
• You need it in writing for investors or a board. Ask for independent technical due diligence first.

To compare firms, our roundup of firms that take over existing codebases names six, including where others fit better than we do.

What are the signs a prototype will not scale to real users?

The clearest sign is that failures grow with usage and fixes do not stick. A bug breaks the same way at any size; a ceiling gets worse as you add users or data. Other signs:

• You have paused onboarding customers because the system cannot take more.
• Hosting costs rise faster than usage.
• The data model fights the product, so simple requests take weeks.
• A one-line change breaks something unrelated, more than once.

Most of these together usually mean the core needs rebuilding. Our post on whether to rewrite or refactor an inherited codebase goes deeper.

What Spider taught us about failures that would not stop

Spider is our clearest example of a system that hit its ceiling, and it was not AI-built. It began as an internal tool at Kriya RevGen that emailed hotel business intelligence reports to revenue managers, and as more properties came on, it became clear there was a commercial product in it.

That growth is what broke it. As our software rescue page puts it, “At the volumes involved, ingestion was failing almost daily, and they could not onboard more properties.” Re-indexing terabytes could take up to 24 hours. Patching would not have helped, because the cause was the design meeting a volume it was never built for. We established first whether to extend or replace it, and the answer was replace. We rebuilt it on Elixir and Phoenix while the existing platform kept serving customers.

The Spider case study has the results: from a few dozen daily users to more than 10,000, from re-indexing that took up to 24 hours to continuous updates, hosting costs down about 90%. Within months of the rebuild launching, Kriya was acquired by Lighthouse, and Spider ranked #1 of 74 for Business Intelligence at the 2025 HotelTechAwards, 4.7 out of 5 from 588 verified reviews, its fifth consecutive win. We are still its engineering team.

The lesson for your app is not “rebuild.” Most young apps that keep going down have a connection limit or a missing index, not a Spider-sized ceiling. The lesson is to find out which you have before anyone spends money on a fix.

Should we stabilize the app or rebuild it?

Stabilize first in almost every case, because you need the app up while you decide, and rebuild only where the cause is the design itself. A rebuild started in a panic usually means two broken systems instead of one.

Razoyo’s Five-Gate Production Check, run in week two

Once outages are under control, run this yourself before you call anybody. It is the check we publish in our guide to taking a vibe-coded app to production. Each gate is pass or fail, and every fail is a line item on the quote you are about to receive.

1. Access model. Name every role and what each can do, without reading the code. Then revoke one person’s access and confirm they are out. After a developer leaves, this gate matters most.
2. Secrets. Search the repository for key, secret, password and token. A credential in the code or a committed config file is a fail, and rotating it is job one.
3. Tests. Change a value that should be invalid and try to save it. If nothing objects, cover the money paths first: signup, payment, permissions, anything that writes.
4. Deploy path. Time how long a one-word change takes to reach users, then how long to pull it back out. A bad release that cannot be reversed in minutes is a fail, and the gate most tied to repeated outages.
5. Monitoring. Ask how you found out about the last outage. If a customer told you, you are not monitoring, you are being monitored.

Four or five gates passed means hardening. Two or fewer means a rebuild of the core, whatever the invoice calls it. Three is where a second opinion pays for itself.

Who should we call, and what will it cost?

Call whoever matches the cause you found, and do not pay for a rebuild until someone has written down why you need one.

Here is where Razoyo fits. The first step is a free 30 minute consultation with a senior engineer, not a sales rep. If it is worth a deeper look, the Production Spec is $2,500 fixed and answers one question: is this buildable and safe as it stands, and what will it really take to get it there. You get findings, a risk ranking and a remediation plan, plus a senior-engineer level-of-effort estimate, and the Spec is yours even if you never hire us. It typically takes weeks, not months, which is why the 48-hour steps come first.

Our pricing page lists the rest: production builds from $10,000, support from $1,500 a month with an emergency line at its own rate, and dev bursts at $1,200 a day or $4,500 a week for fixed-scope work. Before any work above the Spec, a business analyst puts a level of effort and a budget on each piece and gets your confirmation first. No approval, no work. See our process page and the cost of taking an AI-built prototype to production.

When you do not need us: if the log points at one expired certificate, one missing index or one plan limit, a competent freelancer or your provider’s support will fix it in an afternoon. Do that first.

The short version

Freeze changes, get alerted before customers notice, prove your backups restore, secure every account, and log every outage. Within two weeks the log usually points at one of six ordinary causes. If it points at the seventh, a design that has hit its ceiling, get it assessed in writing before anyone starts rebuilding.

Key takeaways

• Freeze first. Google’s SRE book attributes roughly 70% of outages to changes in a live system.
• Monitoring comes before diagnosis. If customers tell you about outages, fix that first.
• A backup is only real once you have restored it. Test one restore in the first 48 hours.
• Own every account. Hosting, database, domain and repository belong to the company.
• Six of the seven usual causes are fixable without a rebuild.
• Failures that grow with volume point at the design. That is when a written assessment earns its fee, as it did for Spider.

Key terms glossary

• Change freeze. A pause on all releases except fixes for the current problem.
• Rollback. Reversing a release to the previous working version, quickly and without data loss.
• Connection pool. A shared set of database connections the app reuses instead of opening one per request.
• Index. A structure that lets the database find rows without reading the whole table.
• Ceiling. The point where a design cannot handle more volume, however many bugs are fixed.
• Production Spec. Razoyo’s fixed-price written assessment of whether an app is buildable and safe as it stands, and what it will take to get there.

FAQ

We launched and it keeps going down. Who do we hire to stabilize it? Let the outage log decide, because the cause decides the hire. A hosting limit or provider incident is for their support. A known, contained bug is usually enough for a freelance engineer, if someone on your side can judge the work. If nobody understands the code or fixes keep not sticking, hire a firm that takes over code someone else wrote, and ask for a written assessment before any rebuild.

What should we do in the first 48 hours after repeated outages? Freeze all changes except fixes for the outage, add an outside uptime check and error tracking, restore one backup to prove it works, make sure the company owns every account, and log every incident.

What are the signs a prototype will not scale to real users? Failures that grow with usage and fixes that do not stick. Other signs are slowdowns that track growth rather than releases, pausing customer onboarding because the system cannot take more, hosting costs rising faster than usage, and simple feature requests taking weeks because the data model does not fit the product.

My app was vibe coded and now I am scared to make changes. What do I do? Build a safety net first: a staging copy where changes are tried, automated tests on the paths that touch money and data, and a deploy path that undoes a bad release in minutes. Until then, keep changes small, one at a time, and written down. The goal is to make shipping a change routine again, not to stop changing the app.

Our developer left and nobody understands the code. Who can we hire? An engineer or firm that takes over code someone else wrote. The original developer is rarely needed, because most of what a new engineer needs is in the code, the data and the infrastructure. You supply the business context: what the app should do, what customers depend on and what breaks most often. First make sure the company owns the hosting, domain and code accounts.

Should we rebuild the app from scratch? Usually not, and never as the first move. Stabilize first so the app stays up while you decide. Rebuilding the core makes sense when failures grow with volume and patches stop working. Get that judgment in writing from someone who has read the code.

How much does it cost to stabilize an app that keeps going down? It depends on the cause. One expired certificate or missing index can be an afternoon’s work. Razoyo publishes its prices: a free 30 minute consultation, a $2,500 fixed Production Spec, production builds from $10,000, support from $1,500 a month, and dev bursts at $1,200 a day or $4,500 a week.

Talk it through

If your app has gone down more than once and nobody can tell you why, that is the conversation we are set up for. Bring your outage log, and in 30 minutes a senior engineer will tell you which of the seven causes it looks like and whether it needs a Production Spec or just a freelancer this week. If you do not need us yet, that is what you will hear.

Schedule Free Consultation

Paul Byrne is President of Razoyo, a software engineering firm in The Colony, Texas taking prototypes and constrained systems into production since 2011.