Startup rescue audit: first 10 questions founders should ask

When a startup needs a rescue audit

A rescue audit usually starts before anyone says the company is in trouble. The signs show up in smaller misses first. Launch dates move again. Features stay "almost done." Planning meetings end with different versions of reality.

That gap matters more than one late sprint. It means nobody can say what is real, what is blocked, and what people only hope will happen.

Another warning sign is story drift between founders and the team. A founder thinks the product is two weeks from release. Engineers know billing still fails, the data model changed twice, and nobody owns the last 20 percent. Once two groups describe the same roadmap in different ways, the roadmap has already stopped doing its job.

Production trouble is another trigger. If bugs, outages, and support issues keep stealing days from the roadmap, the team stops building and starts patching. This gets expensive fast. One bad incident can burn a week. Three smaller ones can do the same while looking less serious on paper.

Tool choices can create a quieter problem. A startup picks a hosted backend, a no code stack, or an AI vendor because it helps the team ship early. Later, pricing changes, export limits, missing features, or strict API rules start deciding what the product can do. At that point, the company is not making product decisions freely anymore.

You probably need an audit when several of these signals show up at once: dates keep slipping without a clear reason, founders and staff tell different stories about progress, production work eats planned feature time, and tools or vendors start boxing the team in.

Run the audit while you still have room to act. Do it before you hire more people to fix a process problem, before you promise a date you cannot hit, and before one more rushed tool choice makes the mess harder to unwind.

How to run the audit in one week

Keep the audit to one calendar week and put one person in charge. If nobody owns it, it turns into side chatter and dies in chat. The owner does not need to fix everything. They need to collect answers, keep people on schedule, and stop the scope from growing.

Ask the same questions separately to the founder, the product lead, and the engineering lead. Do not merge their answers too early. The gaps tell you a lot. If the founder says a feature ships in two weeks and engineering says the billing rewrite still blocks it, you just found something worth checking.

A simple five day pace works well:

1. Day 1: lock the scope, the owner, and the ten questions.
2. Day 2: talk with the founder and product team.
3. Day 3: talk with engineering and whoever handles production.
4. Day 4: gather proof from docs, metrics, tickets, contracts, and incident notes.
5. Day 5: rank the problems and decide what needs action first.

Proof matters more than confidence. When someone makes a claim, ask what backs it up. Good proof is simple: a roadmap with dates, a backlog that shows what slipped, recent incident logs, uptime reports, cloud bills, vendor terms, and cycle time from idea to release.

Some teams talk a lot and show very little. Treat that as a warning, not a style difference. Opinions can point you somewhere useful, but they should not decide the result.

Rank problems by business damage, not by how loud they feel. A checkout bug that stops revenue matters more than twenty minor UI issues. A vendor contract that can double costs next quarter matters more than a noisy internal complaint. End the week with one short list: what can hurt revenue, delivery, or uptime first, and what can wait.

If the team is small, this whole week can fit into a few focused sessions. What matters is discipline, not ceremony.

Questions 1 and 2: is the roadmap real?

Pull the last 90 days onto one page. If the team says it shipped a lot, you should see dated releases, visible customer changes, bug fixes that stayed fixed, and work that moved a business number. A long project board is not proof. A busy chat thread is not proof either.

Question 1: What actually shipped in the last 90 days?

Ask for the exact items that reached users, not work that is "almost done." For each item, compare the original estimate, the actual ship date, and the final scope. Also note who approved any change along the way.

Patterns show up fast. Sometimes three closed tickets are really one delayed feature split into smaller pieces. Sometimes the team finished the code but never released it. That gap matters. Founders need shipped work, not internal progress.

A simple test works well: if nobody can explain in five minutes what changed for users in the last 90 days, the roadmap is already blurry.

Question 2: Why did roadmap items slip, and why is the next date believable?

Delays happen. Repeated delays with vague reasons usually point to a planning problem. "Unexpected complexity" often means the team started work before it broke the feature into smaller parts. "Priorities changed" often means people kept adding scope after work started.

Before you trust the next release date, look for plain evidence. One person should own scope and reject new requests. The team should have a short list of remaining tasks. Known blockers should have names, dates, and owners. Recent sprints should show that the team finishes work before pulling in more.

This part of the audit often exposes the real issue. Engineers may not be the bottleneck at all. The roadmap may keep slipping because founders, sales, or product keep moving the target. If nobody owns scope changes, the date is only a guess. If one owner holds the line and the release plan stays small, the date has a chance.

Questions 3 and 4: what can break in production?

Founders hear "production is fine" all the time. Ask for the last 30 days of incidents and the story usually changes fast. If the team cannot say what broke, when they noticed it, and how long recovery took, they do not control production.

Question 3 is simple: what broke in production this month? Ask for a plain log, not a polished summary. Include failed deploys, login errors, slow pages, missing emails, broken payment webhooks, expired certificates, and any outage that blocked users.

The count matters less than the pattern. One bug fixed in 10 minutes is annoying. A signup bug that sat unnoticed for six hours is a sales problem. A billing issue found by angry customers is worse because trust drops at the same time revenue does.

Question 4 goes after hidden single points of failure. Which part depends on one person? Many startups have one engineer who knows the cloud setup, one contractor who can fix billing, or one founder with access to DNS and payment accounts. If that person disappears for a week, you have a real production risk.

Ask to see four things: the incident log from the last month, who gets alerts and how fast they respond, the recovery steps for the most common failures, and which systems can stop sales, billing, or onboarding.

A small example makes this obvious. A team may blame weak conversion when the real issue is a checkout bug that fails for 8 percent of new users after a deploy. Another common one is onboarding: accounts get created, but provisioning fails in the background, so new customers think the product is broken.

If nobody clearly owns uptime, alerting, and access, the same truth usually appears: the product is not ready to grow yet. Fix the part that can stop money or stop new users first.

Questions 5 and 6: where does vendor lock hurt?

Question 5

Ask which vendor can hurt you fastest if prices jump, terms change, or service quality drops. Many founders look at total cloud spend first, but the real pain often sits elsewhere: a payment provider, a hosted database, an auth tool, or one AI API that the product depends on every hour.

The test is simple. If one bill doubled next month, which change would force you to rework pricing, pause growth, or cut features? That vendor has leverage over your roadmap.

A good example is an app that built chat, search, and support flows around one model provider. The team thinks it bought speed. In practice, it tied response format, prompt design, and product behavior to one API. If that provider changes limits or pricing, the problem is not only cost. Product choices shrink.

Question 6

Then ask what would take weeks to replace, not days. Look past infrastructure names on invoices and find the places where your business logic lives outside your codebase. That is where dependency gets expensive.

Watch for pricing rules living in a billing tool instead of your app, workflow steps hidden in a no code service, auth and permission rules stored in a vendor dashboard, reporting logic built inside a BI tool, or product behavior shaped around one vendor specific API.

Contracts matter too. A long notice period, usage minimum, data export limits, or rate caps can block a move even when the team wants to leave. Read the commercial terms and the technical terms together. Founders often read one and ignore the other.

If the team cannot explain how to move a service, where the data would go, and what code they would need to rewrite, you do not have flexibility. You have dependency. In rescue work, this often explains why costs stay high even when the product itself looks simple.

Questions 7 and 8: where does the team get stuck?

Teams usually slow down in the gaps between people, not inside the work itself. This part of the audit gets useful fast when you trace those gaps and name the exact step where work starts waiting.

Question 7 is about approvals and decision queues. Look at every place where work can pause: product changes, code review, release approval, incident response, legal checks, and even simple copy edits. If one person must approve most of it, that person sets the pace for the whole company.

Meetings often hide the same problem. A status call is annoying, but a decision meeting is worse when nothing can move until it happens. If pricing changes wait for the Tuesday leadership call, or a rollback needs three people on Zoom, the calendar becomes part of your delivery process.

The usual red flags are easy to spot. One person approves almost every release. Roadmap changes wait for a weekly meeting. Incidents stall until a manager joins. Senior engineers review all risky code by default. Founders step into routine product decisions every day.

Question 8 is about role load. Write down who reviews code, who ships releases, and who leads incidents. Then write down what else those same people do during a normal week.

This is where many teams get exposed. The strongest engineer often becomes reviewer, release manager, outage fixer, recruiter, vendor contact, and part time product owner. That may feel efficient for a while. In practice, it pulls senior people away from product work and makes the team nervous about acting without them.

A small team can move well with clear backup owners and fewer approval hops. A larger team can stay stuck if every serious decision climbs back to the same two people.

Questions 9 and 10: what drains time and cash?

Money problems often start as time problems. A team looks busy, tickets keep moving, and costs still climb because too much work does not change the product in a way customers feel.

These two questions usually expose the hidden leak: what work burns effort without moving the business, and what one change would give that effort back next month?

Question 9: What work costs money but changes nothing important?

Start with the last two to four weeks. Look for tasks that repeat, get undone, or exist only because the team made a promise too early. Common examples are manual QA on the same flows, last minute customer specific changes, meetings that end without a decision, and fixes for bugs that came from rushed releases.

Rework tells the truth fast. If engineers spend 30 percent of their week revisiting the same area, that is not normal wear and tear. It usually means the spec changed too late, ownership is fuzzy, or the release process lets bad code through.

Check where priorities bend. One loud customer, one custom deal, or one founder promise can pull a team away from the main product for weeks. Revenue can justify that sometimes. Habit never does.

A short review helps. Ask which tasks took more than one pass, which work served only one customer, which meetings blocked shipping, and which bugs came from rushed or unclear work.

Question 10: What single change frees the most time next month?

Do not make a long fix list. Pick one move with a clear payoff. That might mean cutting a custom feature, freezing roadmap changes after planning, adding one solid test around the area that breaks most, or naming one owner for release decisions.

For a small team, one good change can save 10 to 20 hours a week. That is often worth more than hiring another person. If you cannot name the one change that frees time next month, you still do not know where your cash leak starts.

A simple example from a stalled product

A founder says the product will launch in six weeks. On paper, that sounds tight but possible. The board sees a roadmap, the team gives weekly updates, and everyone acts like the date still works.

A short audit can change that picture fast. After a few interviews and a look at tickets, release notes, and incident history, the gap shows up. The team is not six weeks away. It is closer to fourteen.

Two months of delay already sit inside the plan. People hide it in soft language like "final polish," "last integrations," or "small stability fixes." Those words sound harmless, but they usually mean the product still breaks during deploys, bugs keep coming back, and testing is too thin for a safe launch.

The bigger issue is ownership. One engineer handles deploys and most incident fixes. That works until it doesn't. If that person gets sick, takes time off, or leaves, releases slow down at once and production problems stay open longer.

Most founders do not see this right away because the team still looks busy. Tickets move. Demos happen. The plan keeps its original date even when the work no longer fits inside it.

A good audit does not start with blame. It cuts scope, removes features that only add risk, and resets the launch around what the team can actually ship. It also spreads release work and incident response across more than one person, which lowers production risk on day one.

That is often enough to turn a vague promise into a plan the team can defend. This is the kind of review Oleg Sotnikov often helps founders with when a product is stuck between roadmap claims and production reality.

Mistakes that hide the real problem

An audit goes off course when founders hear only from managers. Managers usually give a clean summary. The people doing the work see the mess. An engineer knows releases fail every Friday. A support lead knows the same bug keeps coming back. A salesperson knows the roadmap promised features that still do not exist.

If you skip those voices, you get a polished story instead of the truth. A short call with the people closest to delivery often tells you more than a long slide deck.

Another common miss is blaming people for a tool problem. A team may look slow when the real issue is bad setup: five manual handoffs, weak test coverage, noisy alerts, or a vendor that blocks simple changes. Founders often call this an execution issue because that feels easier to fix. Usually, it is not.

Status updates can hide a lot too. Teams learn which numbers look healthy even when delivery is slipping. A board sees tickets closed, while the same bug keeps reopening. A founder hears that the sprint is on track, while the release still depends on one person being available at the right moment. That is why the audit needs proof, not polished summaries.

Quick checks before you act

Before you change the roadmap, cut tools, or replace people, test the story you are hearing. An audit goes wrong fast when each lead tells a different version of the same problem.

Ask every team lead two plain questions: what are we shipping next, and on what date? If product, engineering, and sales give three different answers, the issue is not effort. The plan is not shared, so deadlines will keep slipping.

Then check release safety. Pick one recent change and ask who can ship it without calling the same senior engineer. If only one person can build, approve, or deploy, you do not have a real release process. You have a single point of failure.

Now test outage tolerance. Imagine your main cloud service, auth provider, or model API goes down for half a day this week. Can the product still serve users, take payments, or at least fail in a controlled way? If nobody can answer that clearly, production risk is already higher than the team admits.

Last, ask the founder to name the top three blockers in plain words. Skip vague labels. Plain words sound like this:

• "Releases wait for one engineer."
• "We promised features the team cannot finish."
• "Our vendor bill is growing faster than usage."

If the founder's list does not match what team leads say, pause major decisions for a day. Do not jump into layoffs, rewrites, or a new vendor yet. First get one shared view of scope, release ownership, outage exposure, and the few blockers that keep burning time and cash.

That short check often tells you more than a week of status meetings.

What to do next

Your notes only matter if you turn them into a 30 day plan with names, deadlines, and a short list of tradeoffs. If the audit surfaced eight problems, do not start eight projects. Pick the few issues that change the company's odds in the next month.

Start with three areas first: roadmap truth, production safety, and blocked decisions. If the roadmap depends on work the team cannot finish, fix that before adding features. If production can fail in ways nobody can explain, reduce that risk before chasing growth. If the team waits days for product or technical calls, name the decision maker and shorten the path.

A simple 30 day rescue plan often looks like this:

1. Week 1: cut or delay roadmap items that have no clear owner, no estimate, or no business reason right now.
2. Week 2: fix the biggest production risks, such as weak monitoring, missing backups, or one person holding too much system knowledge.
3. Week 3: remove one or two team bottlenecks, like slow approvals or unclear handoffs.
4. Week 4: review what changed, what slipped, and what still blocks delivery.

Give each problem one owner. Not a team, not a chat channel, and not a committee. One person should be responsible for the result.

If you need an outside view, this is the kind of work Oleg Sotnikov does through oleg.is as a Fractional CTO and startup advisor. The goal is not a dramatic reset. It is a clear picture of what is real, what is risky, and what to fix first.