Buyer's guideProject rescue10 min

Is your SaaS ready to launch on AWS?

You have promised a date and you are not sure the platform will hold. Readiness is a list you agree on in writing, not a feeling. Here are the blocker categories, a one-day check, and how to decide what ships as a known risk.

By Rahul LadumorSeptember 13, 2026

The short answer

Your SaaS is ready to launch on AWS when a written list of blockers has been checked against evidence and every remaining item has an owner and a date. Not before, and not because the demo went well. The list has six categories: can you roll back, can you lose data, can you lock yourself out, will you hit a limit, will you find out when it breaks, and is there a ceiling on what it can cost. Fix the items that cannot be undone before launch. Ship the rest as known risks. A launch with known, owned risks is a normal launch.

The rest of this page is the method, drawn from taking a serverless SaaS platform at ProdigyBuild from pilot to production-grade: 23 hand-built resources across three accounts, no IaC, no monitoring, and 15 to 30 minutes of downtime every deploy, to one-command environments and zero-downtime releases.

Readiness is a list, not a feeling

"I am not confident" is the right instinct and the wrong unit of work. You cannot fix a feeling, and you cannot tell the board when it will be resolved. What you can do is convert it into a list of specific things that would take the launch down, check each one against evidence, and end up with three columns: confirmed fine, fix before launch, ship as a known risk. The confidence comes from the columns being full, not from anyone's reassurance, including mine.

The list also outlives the launch. The same checklist, re-run before every significant release, is how a team stops relaunching the same anxiety each quarter.

The six blocker categories

Rollback. Can you undo the release in minutes without a human doing something clever? If the deploy causes 15 minutes of downtime and the undo is another 15, you have a 30-minute outage built into every bad release. On the ProdigyBuild platform, blue-green deployment took that from 15 to 30 minutes per deploy to zero.
Data. Are backups running, have you restored one, and can a migration be reversed? Untested backups are not backups. Data loss is the one blocker you cannot ship as a known risk.
Access. Who holds root and admin, is MFA on, are deploy credentials scoped, and can two people recover the account if one is unavailable on launch night?
Limits and quotas. Lambda concurrency, API Gateway throttles, database connections, service quotas you have never hit because you have never had this many users. Launch day is when you find them. Find them first.
Observability. Will you know the sign-up flow is broken before a customer tweets it? One alert per flow the business cannot lose, routed to a person, beats a dashboard nobody is watching at 2 AM.
Cost ceiling. Is there anything that can run away? A retry loop, a build job with no timeout, an AI call with no cap. On that platform a runaway build could burn compute fast, so the workers got a 15-minute hard timeout before launch, not after.

The readiness check you can run in a day

You do not need me for the first pass. Take a day with the engineer who knows the system best and answer each category with evidence, not opinion. Deploy a trivial change to production and roll it back, and time both. Restore last night's backup to a scratch environment. List everyone with admin access and check MFA. Pull the service quotas page and compare it to your launch-day traffic estimate multiplied by three. Break the sign-up flow in staging and see whether anything pages. Find every job, retry and external call and ask what stops it running forever.

Write down what you find in the three columns. If the fix-before column is empty and you trust the evidence, you may not need a review at all. If it is long, or you are not sure the evidence is honest, that is when an outside pair of eyes earns its fee: not to find different things, but to check the list is complete and that "fine" means tested rather than assumed.

Fix before launch, or fix after

The fix-before rule is simple: anything that cannot be undone, loses data, or locks you out gets fixed before launch, however long it takes. That usually means rollback, backups and restore, access recovery, and any unbounded cost. Everything else can ship as a known risk with an owner and a date, and that is not a compromise; it is how every real launch works.

Performance is the common judgment call. On the ProdigyBuild platform, API P95 latency went from 800 milliseconds to under 100, and Lambda cold starts on the first request after idle were fixed with provisioned concurrency on the three most-hit endpoints. Both were worth doing. Neither would have stopped the launch if they had slipped a week, because slow is recoverable and data loss is not. Put performance in the fix-after column unless the numbers say customers will leave.

Agree the checks so the decision is shared

The list only works if the team agrees it is the list. Write it together, argue about what belongs in fix-before, and get the people who will be on the launch call to sign the same document. That does two things. It stops the launch decision being one person's gut versus another's, and it means when something does go wrong, the conversation is "that was a known risk with an owner" rather than "why did nobody check". The person accountable for the product makes the call. The list makes sure they make it with the same facts as everyone else.

One-command environments help more here than they look like they should. When standing up a full environment took three days, nobody re-ran the checks. Once Terraform brought it to about 12 minutes on that platform, the readiness check could be run against a fresh environment before every significant release, and the list stopped going stale.

When the launch goes wrong anyway

Something will. The measure of readiness is not that nothing breaks; it is that you find out first, you can undo it in minutes, and no data is lost. If those three hold, a bad launch is a bad hour and a good story. If they do not, it is a bad week and a lost customer. Everything on the fix-before list exists to put you in the first group.

If you would rather not run the first pass alone, or the list came back longer than the calendar allows, theproduction readiness review is the paid version of exactly this, with the evidence checked and the fix-before list agreed with your team. If the system was inherited and the questions run deeper than launch readiness,the project rescue review starts further back.

Next step

Have the same problem on your stack?

Send the architecture, AWS bill concern, deploy pain, or GenAI reliability issue. I'll find the first real bottleneck and propose a small, reversible fix.

Book a production readiness review See the SaaS platform case study

FAQ

How long does a production readiness review take?

For one product on one AWS account, the review itself is a few days of inspection and a findings call, and you get the blocker list with a fix-before, fix-after split. The fixes are where the time goes, and how long they take depends entirely on what the list says. If the deploy path has no rollback, that is days to weeks of work. If it is quotas and alerting, it can be done in the same week. Start the review early enough that a bad answer does not move the launch date.

Can you review a system you did not build?

Yes, and most readiness reviews are of systems I did not build. The review works from the artifacts: the AWS account, the repositories, the pipeline, the billing data and the monitoring that exists. Not knowing the history is sometimes an advantage, because I check what is there rather than what the team remembers deciding.

What if we find blockers a week before launch?

Then you have a week to fix the ones that can take the launch down and a decision to make about the rest. That is a better position than finding them on launch day. The fix-before list is deliberately short: the things that lose data, lock you out, or cannot be undone. Everything else can ship as a known risk with an owner and a date. A launch with three known, owned risks is a normal launch. A launch with unknown risks is a gamble.

Do you sign off the launch, or do we?

You do. My job is to make sure the list you are signing is complete and honest, and that every item on it has evidence behind it rather than a green tick from someone who wanted the meeting to end. The decision to launch belongs to the person accountable for the product. I give you the information to make it well and the record of what you knew when you made it.

What happens if the launch goes wrong anyway?

Something will go wrong; the readiness work is about making sure it is recoverable and noticed quickly. That is why rollback and alerting are on the fix-before list and never on the fix-after list. If you can undo the release in seconds and you find out about failures before customers do, a bad launch is a bad hour. If you cannot, it is a bad week. The review makes sure you are in the first group.

Will I just receive a report?

You receive the blocker list split into fix-before and fix-after, the evidence for each item, and a readiness checklist your team owns and re-runs before the next launch. Your team can do the fixes. If you want hands-on help, that is scoped separately with agreed checks and a handover. The review stands on its own.