Keep sales moving while app is being fixed: simple playbook

What to do when the app breaks but sales cannot pause

Say it plainly. Customers can handle bad news. They lose trust when it sounds like you’re hiding it. Name what’s broken, what still works, and what users should avoid right now. “Login is failing for some users” beats “We’re having issues.”

This hits sales because early deals run on timing and confidence. A pilot customer is deciding whether to spend their team’s time on you. If your message is fuzzy or defensive, the deal slows down even if the bug is small. If you’re clear and calm, you can keep momentum while the fix is underway.

The goal is to keep deals moving without overpromising. Keep talking to prospects, keep scheduling demos, keep procurement moving, but add guardrails. Don’t promise dates you can’t hit. Don’t pretend the app is fine. Give a safe way to evaluate value today.

This is built for founders and small teams selling early (pre-seed to Series A), pilots, design partners, and agencies reselling your product. It also fits anyone who inherited an AI-generated prototype that worked in a demo and then fell apart in real use.

Before any customer call, write three lines:

• What’s impacted (one sentence)
• What still works (one sentence)
• What you’re doing now (one sentence)

Example: onboarding is broken, but existing users can still run reports. You tell prospects onboarding is temporarily guided, and you offer a white-glove setup call the same day. The evaluation keeps moving, and you learn what they truly need while engineering fixes the root cause.

Treat repair as a parallel workstream: one track is customer confidence, the other is code. If you need outside help, FixMyMess (fixmymess.ai) focuses on diagnosing and repairing AI-generated apps so critical paths like auth, data flows, and security are stable again while you keep deals active.

Decide your message before you talk to customers

Before you email prospects or hop on a call, decide what you will say and what you won’t. Uncertainty stops buying. Consistent messaging keeps you from sounding defensive and prevents “multiple versions of the truth” across sales, support, and engineering.

Write down what you can safely promise even on a bad week. Stick to things you control: response time, update cadence, temporary options, scope boundaries (what works vs. paused), and a clear next check-in with a date and time.

Then write a short “do not promise” list. Avoid exact fix dates unless you’re truly sure. Avoid claiming “everything is stable now” right after a patch. When you need a confident but honest line, use: “We’ve identified the cause, we’re fixing it now, and here’s how we’ll support you in the meantime.”

Decide roles before you talk to anyone. Pick one owner for customer communication and one owner for the fix. Customers don’t want a committee. They want one person who owns answers and one person who owns progress.

Finally, define “blocker” vs. “minor bug.” A simple rule: blockers stop money or data flow (login, payments, core actions). Minor bugs are annoying but have a workaround. If users can’t sign in, your message should reflect urgency and a temporary path forward.

Simple messaging templates you can copy and send

When part of your product is broken, people don’t need a long story. They need clarity, a safe workaround, and a firm time for the next update.

Use one pattern everywhere so you sound calm and consistent. Cover four points: what happened, who it affects, what they can do right now, and when you’ll report back.

Subject: Quick update on [Product] + workaround

Hi [Name] - quick heads-up.

What’s happening: We found an issue in [area: login/integration/reporting] that can cause [impact in plain words].
Who’s affected: [All users / some accounts / only new sign-ups].

Workaround (works today): [simple step-by-step in one sentence, or “reply with X and we’ll handle it manually”].

What we’re doing: We’re fixing the root cause and verifying it so it doesn’t repeat.
Next update: I’ll send you another update by [day, time, timezone], even if the fix isn’t done yet.

Sorry for the disruption. If you’re blocked on something specific, tell me what you’re trying to do and we’ll get you a safe path today.

- [Your name]

Here’s a one-line status line you can paste into any thread to reduce back-and-forth:

Status: [investigating/fixing/verifying]. Impact: [plain impact]. Workaround: [one-liner]. Next update by [time, timezone].

For a 3-minute check-in call, keep it repeatable:

1) “Quick update: we found [issue] and it affects [impact].”
2) “Today you can still [workaround/manual process].”
3) “We’re working on the fix now. Next update is by [time].”
4) “What’s the one thing you need to get done today? We’ll make that happen.”

When someone asks, “When will it be fixed?”, don’t guess. Give a confidence level and a checkpoint.

Example answer: “I don’t want to promise a time and miss it. Best estimate is [range], and we’ll confirm by [specific time]. If we’re not done by then, we’ll keep you moving with [workaround] until it’s resolved.”

Temporary workarounds that still feel professional

A workaround should reduce risk for the customer and reduce chaos for you. Aim for “reliable and boring,” not clever.

Option 1: A short-term concierge flow

If the core value is there but the workflow is failing, run the steps for the customer for a limited time. You’re not hiding the issue. You’re keeping their project moving.

Example: uploads work, but onboarding crashes. Ask them to email the file, import it on your side, then send back outputs on a schedule they can count on.

Option 2: A temporary system of record

When the app can’t be trusted as the source of truth, use a spreadsheet or shared doc as the official record for a week or two. This is especially effective in pilots because progress stays visible.

Keep it structured: one row per request, clear statuses, an owner, and timestamps. Tell customers that anything logged there will be honored, even if the app later shows something different.

Option 3: Email intake with clear rules

Email can be a professional intake channel if it’s predictable. Give customers a subject format, a response promise, and one owner to reply to. Add a daily cutoff time for same-day processing and define what “urgent” means.

Option 4: Limited access to only stable features

If only certain screens are safe, restrict the pilot to those and position it as a focused rollout: “These are the parts we are running live right now.” Most customers prefer a smaller, dependable experience over a full product that breaks.

To keep a workaround from feeling messy, do three things: name the temporary process, put it in writing in one short message, and stick to your promised timing.

How to set expectations with early customers

Early customers are usually fine with rough edges. What they hate is guessing. Your job is to make “early access” feel intentional, not chaotic.

Explain what early access means in plain terms: they get value early, and they help you validate the product. Keep it confident: “You’ll get hands-on support from us, and we’ll prioritize your feedback.” One clear apology is enough. Follow it with a plan.

Don’t promise a single date you might miss. Give a range tied to checkpoints. For example: “We expect the fix in 2 to 4 days. If we miss the 2-day mark, you’ll still get an update at the checkpoint with what’s done and what’s next.”

Define success before you talk timelines. Customers relax when “fixed” is testable. Use outcomes like these:

• Login and password reset work end to end
• The main workflow completes without errors (the one they pay for)
• Data is not lost or duplicated
• Basic security checks pass (no exposed keys, no obvious injection issues)
• You can deploy and monitor without manual hacks

Scenario: you’re running a pilot with a small agency. Onboarding breaks. Instead of “We’re working on it,” you say: “Today: we’ll restore onboarding for new users and verify it with three test signups. Tomorrow: we’ll add a regression test so it doesn’t return. If anything slips, we’ll extend your pilot by a week.” That turns anxiety into a plan.

If you offer refunds, credits, or extensions, keep the rules calm and simple and put them in writing (even if it’s an email). Focus discussions on blocked outcomes, not on every minor bug.

If you inherited an AI-generated prototype, name the extra risk without drama: “This codebase needs cleanup before it behaves like production.” Then translate it into checkpoints customers can track.

A simple update cadence customers can rely on

When your app is shaky, silence kills deals. People can handle issues if they know you’re on it and they know when they’ll hear from you again. A predictable rhythm also keeps your inbox from turning into one long status meeting.

A practical cadence for early-stage SaaS issues:

• Day 0 (as soon as you confirm impact): acknowledge, explain the workaround, set the next update time
• Day 1: progress update, confirm what is stable vs. affected
• Day 2: either a recovery update or a revised estimate with what changed
• Fix confirmed: what’s fixed, what to test, what you did to prevent repeats

Between those moments, only send an extra message if something materially changes: impact expands, the workaround fails, or the timeline shifts.

Use the same short format every time

Make updates skimmable in 10 seconds. Reuse a single structure so customers know where to look:

• Status (plain words, no blame)
• Customer impact (who is affected and what is blocked)
• Workaround (one clear action)
• Next checkpoint (exact time you’ll update again)
• Contact (one person to reply to)

Example: “Status: login is failing for some users. Impact: new accounts cannot sign in. Workaround: we can create accounts for you manually today. Next checkpoint: 3pm ET. Contact: reply to this email.”

Don’t miss anyone: track updates like a deliverable

Keep a simple log: customer name, primary contact, channel used, last update sent, and next promised checkpoint. This matters when pilots run in parallel, or when sales and support both touch the same account.

Common mistakes that slow sales even more

The biggest risk usually isn’t the bug. It’s how you communicate around it.

Mistake 1: Explaining the tech instead of the impact

Customers don’t need a play-by-play of your stack. They need to know what’s affected, what’s safe, and what happens next.

Talk in outcomes. “Sign-in is unstable for some users” is useful. “Our auth middleware is throwing 500s” is noise.

Mistake 2: Going silent while you wait

Silence forces customers to fill in the blanks, and they usually assume the worst. Even if you don’t have the full answer yet, send a short update confirming you’re on it and restate the next checkpoint.

If you’re waiting on someone else (an agency, contractor, or platform), say that clearly and keep your next update promise.

A few quick checks prevent most trust damage:

• Send a first update within 30 to 60 minutes of confirming the issue
• Give a next update time even if the fix isn’t ready
• Say what customers should do right now (workaround or pause)
• Confirm what is not affected (billing, data access, security) only if you’re sure
• Use one owner for outbound updates

Mistake 3: A workaround that creates data or privacy risk

A temporary workaround that causes lost records, shared passwords, or customer data in personal inboxes can turn one bug into a bigger problem. If the workaround touches customer data, treat it like a real feature: clear steps, limited access, and a plan to roll it back.

Mistake 4: Different people giving different ETAs

Nothing kills confidence faster than “today” from sales and “next week” from engineering. Write down one shared message: what’s broken, what’s the workaround, and the current ETA range.

If the code is messy and timelines are hard to predict, get a fast diagnosis first so you can message customers with real constraints instead of guesses.

Quick checks before you keep selling

Before you push more people into the product, do a fast safety scan. You’re not trying to fix everything today. You’re trying to avoid selling into a failure that creates refunds, angry emails, or lost trust.

Start with five risk areas that can turn a small bug into a deal-killer: login and access, payments and billing, data loss, security basics, and uptime/performance for demos.

If any of these are failing in a way that could harm customers, don’t push people through normal signup. Switch to a waitlist or guided onboarding where you control the experience.

A simple rule: if you can’t confidently support a new customer without heroics, pause self-serve signups. Keep selling the outcome, but control access until the basics are safe.

Create a one-page “current limitations” note internally so your whole team tells the same story: what’s broken, who it affects, the workaround you’ll offer, and what you won’t promise yet. Keep it plain and specific.

Then confirm you can actually run the workaround for the next 7 days. Make sure you have a person on point daily, you can deliver the workaround within one business day every time, and you have a rollback plan if the fix makes things worse.

Example scenario: saving a pilot deal during a critical bug

You’re mid-pilot with a 10-seat customer. They’re ready to start paying next week, but onboarding is broken: invited users can’t log in. The champion is supportive, but their manager wants proof the team can use it today.

You keep the pilot moving with a professional workaround and a checkpoint-based plan (not one big promise). Here’s the exact message you send:

Subject: Quick fix plan for the login issue (and a safe workaround today)

Hi Maya,

Thanks for flagging the invite/login problem. We reproduced it and it’s on us.

Workaround today (so your team can keep testing):
- I can create the 10 pilot accounts on our side and send you temporary login details within 60 minutes.
- We’ll reset those passwords once the fix ships.

Fix plan and checkpoints:
- Today 3:00 pm: confirm root cause and share what’s changing
- Tomorrow 12:00 pm: patched build ready for your verification
- Tomorrow 4:00 pm: deploy to production if you confirm it works

If we miss any checkpoint, I’ll tell you immediately and we’ll extend the pilot by a week at no cost.

Reply “OK” and the names/emails, and I’ll start the account setup now.

Thanks,
[Name]

The workaround keeps the pilot moving without asking the customer to “wait.” It also keeps risk lower because you control access and avoid telling them to bypass security.

The next day, you hit the first checkpoint but learn the fix needs more testing. You send a short update: what changed, what you tested, and the revised next checkpoint. The customer stays calm because they can see progress.

Outcome: the customer completes the pilot using temporary accounts, the fix ships within 48 hours, and the deal converts.

Next steps: stabilize the app and protect your pipeline

If you’ve been making quick fixes for days, the fastest way to protect sales is often to stop patching and run one focused repair sprint. Patches can keep demos alive, but they also create new bugs and make timelines harder to predict.

Keep patching only if it reduces risk. If each fix breaks something else, pause new changes and switch to a short, planned sprint with a clear goal (for example: “signups and billing are stable”).

When it’s time to stop patching

You likely need deeper repair if the same issue keeps returning (especially login and sessions), you find exposed secrets, core flows are fragile, fixes take longer each time because the code is tangled, or you’re afraid to deploy because you can’t predict what will break.

Treat that as a stability project, not a “small bug.” The goal is a version you can sell with confidence.

A simple 48-72 hour stabilization plan

Keep the scope tied to what customers touch:

• Freeze features and accept only fixes tied to revenue-critical flows
• Diagnose first: reproduce issues, map the flows, list root causes
• Repair foundations: auth, permissions, secrets, data validation
• Add basic guardrails: logging, error tracking, and a smoke test checklist
• Ship one clean release, then monitor and explain what improved

If your app was generated by tools like Lovable, Bolt, v0, Cursor, or Replit, hidden issues like tangled architecture, SQL injection risks, and broken auth are common. FixMyMess at fixmymess.ai offers a free code audit to surface the real blockers, then helps with repair, security hardening, refactoring, and deployment preparation.

Keep selling while you fix, but only promise what your stabilized version can reliably deliver. A tighter scope and one clean repair sprint usually protects your pipeline better than weeks of “just one more patch.”