Deciding what to fix first when everything is broken

When everything is broken, bug prioritisation in a business comes down to one question: which issue is losing you the most money or blocking the most people right now? Rank each bug by revenue impact, data-loss risk, and the number of users or internal teams it stalls, then fix in that order before touching anything cosmetic.

Key Takeaways

• Separate severity from priority: a severe bug in an unused feature ranks below a medium one that blocks checkout.
• Score every issue on three signals: hourly revenue at risk, data loss or corruption, and the number of people blocked.
• Write down the error message, screenshot, and reproduction steps before anyone touches the code, so the evidence survives.
• Fix the cause, not the symptom; a restart or cache clear without a root cause returns within days.
• One shared ranked list beats scattered chats, tickets and verbal reports.
• During a live incident, ship small reversible fixes, not one big "fix everything" change.
• After the crisis, run a blameless review and schedule the slow-burn fixes you deferred.

What bug prioritisation actually means

Bug prioritisation is the process of ranking defects by the damage they cause rather than the order in which they were reported. A business-grade approach weighs three signals per issue: hourly revenue at risk, potential for data loss or corruption, and how many customers or internal teams are blocked from working.

The word "priority" gets misused constantly. Severity describes the defect itself — how badly the software misbehaves. Priority describes when you fix it, and that depends on your context. A crash that wipes a local cache is severe but low priority if nobody uses that cache. A typo that breaks the main call-to-action is trivial but urgent. Keeping those two words separate is the whole discipline.

In practice, teams that skip this distinction end up in a loop: they fix the most dramatic bug, the loudest customer complains again, and the quiet revenue leak keeps running. The ranking step forces the conversation back to money and blockage, which is where a business decision belongs.

Why bad prioritisation costs more than the bugs themselves

A team that fixes the loudest bug first while the checkout silently fails loses revenue every minute it spends elsewhere. Mis-prioritisation compounds because urgent cosmetic fixes get shipped, real blockers fester, and customers churn without the team noticing.

The cost shows up in three places. First, direct revenue: an unprocessed order, a failed payment, or a form that silently drops leads. Second, engineering time: every hour spent on a low-impact fix is an hour the revenue bug stays live. Third, trust: a customer who hits the same error twice assumes you don't care, even if you were busy fixing something else.

There's also a hidden tax on the team itself. Context switching between unrelated bugs, re-testing the same failure after a bad fix, and arguing about what "critical" means all drag the response out. A ranked list removes the argument. The order is the order.

When you need a formal triage process (and when you don't)

You need formal bug prioritisation when a single person cannot hold the whole defect list in their head, or when two stakeholders disagree about what "critical" means. Below roughly twenty open issues and one product owner, a simple ranked list in a shared spreadsheet is enough.

Small teams often over-engineer this. A solo founder with eight bugs doesn't need a scoring model; she needs a quiet hour and a notepad. The trigger for formality is ambiguity: multiple reporters, multiple products, or bugs that span a website, a mobile app, and a server. At that point, an agreed ranking prevents the person with the strongest voice from setting the order by accident.

We see this pattern with clients who run a UAT phase before launch and then drown in the resulting defect list. The process isn't the goal. The goal is that everyone agrees which three bugs get fixed before Friday.

How to rank bugs without a fancy tool

Ranking works by scoring each bug on impact and urgency, then dividing by rough effort. Impact is money, data or people; urgency is how fast it worsens; effort is engineer-hours. A one-line entry with those three numbers beats any tool you don't update.

You don't need a product. A spreadsheet with columns for description, reproduction steps, impact (1–5), urgency (1–5), effort (S/M/L), and owner is enough. Sort by impact times urgency, then break ties by effort — smallest first. The formula is deliberately crude because the inputs are estimates. Precision here is theatre.

The key is that every bug gets a score the moment it's reported, not after a week of debate. A rough score today beats a perfect score never. If two bugs tie, fix the one that blocks the other work first.

Step-by-step: running a fix-first triage

A triage session takes thirty minutes if you prepare the right inputs first. The steps below assume the incident is live and you need a list of what to fix today; they work equally well for a backlog sweep at the start of a sprint.

1. Collect every known failure into one place — chats, tickets, verbal reports, and your own observations. If it isn't written down, it doesn't exist.
2. Capture evidence for each one: the exact error message, a screenshot, the URL or screen, and the steps to reproduce. Do this before anyone changes anything.
3. Score impact by asking three questions: does it lose revenue, can it lose or corrupt data, and how many people does it block? Give each a number from 1 to 5.
4. Score urgency: is it getting worse by the hour, stable, or already contained?
5. Sort the list by impact times urgency, then by smallest effort first. That's the fix order.
6. Assign owners and a time box for the top three. One person owns the fix; one person owns the verification.
7. Write the deferred items down with a reason, so they don't get silently dropped when the pressure eases.

Severity, priority, and who owns each

Severity describes the defect itself — a security hole is always severe. Priority describes when you fix it, and that depends on your business context. The same bug can be high severity but low priority if it lives in a feature nobody uses.

Define your levels once and write them down. A workable scale is: P1 — revenue blocked or data at risk, fix now. P2 — significant degradation, fix this week. P3 — annoying but workable, fix this sprint. P4 — cosmetic or edge case, backlog. The words matter less than the agreement.

Ownership has to be explicit too. One person — usually the product owner or the founder — gets the final call on P1 versus P2. Engineers estimate effort; they don't set business priority. That split keeps the loudest voice from becoming the de facto triage lead.

How to verify the fix actually worked

A fix is not verified until you can show the failure no longer reproduces and the original symptom stayed gone for a full business day. Verification starts with the reproduction steps you wrote down during triage, not with the developer's assurance that "it should work now".

Run the reproduction steps on the live or staging environment. Check the logs for the same error string. Watch the metric that matters — failed checkouts, bounce rate, queue depth, whatever first signalled the problem. If you use an error tracker like Sentry's error monitoring, confirm no new events of that type arrive after deploy.

Then wait. A fix that holds for one hour often breaks at 9 a.m. when traffic arrives. Verify during a full business cycle, not just in the quiet hour after the deploy.

Failure modes and how to debug them

The most common failure mode in bug prioritisation is fixing the symptom instead of the cause, so the same error returns within a week. When a fix recurs, stop patching and re-run triage: check whether you captured the root cause or only masked it.

If you're debugging on a server, start with the system error log before touching application code:

journalctl -p err -n 50 --since "1 hour ago"

That shows the highest-severity system events from the last hour. If the error is in the application layer, grep the app log for the exact string from the customer report. The sequence is: reproduce, isolate, fix, verify, then write down why it happened so the next incident goes faster.

Another failure mode is the "one big fix" attempt. A team under pressure bundles five changes into one deploy, something breaks, and now there are six bugs. Ship one fix, verify, then ship the next. The discipline feels slow but it's always faster than a second incident.

Cost and operational overhead

Prioritisation itself costs almost nothing in tooling — a spreadsheet is free — but every hour of mis-prioritised engineering time is expensive because it delays the fixes that protect revenue. The real overhead is the discipline of keeping the list current and the post-mortem honest.

The biggest cost driver is not the triage meeting; it's the rework from fixing the wrong thing first. A well-ranked list saves engineer time because there's no debate and no double-handling. A badly-ranked list burns time on cosmetic work while the business bleeds.

Ongoing maintenance also matters. If your team is small, this is exactly the kind of work a website maintenance arrangement can absorb without pulling your own people off other tasks. The list stays ranked, the fixes get made, and you don't carry the overhead alone.

Security considerations during triage

Security bugs always outrank cosmetic ones, but not every security finding needs an immediate production change. Triage security issues by exploitability — is it reachable without authentication? — and containment cost, then fix the exploitable ones before announcing anything publicly.

One practical rule: before any destructive or state-changing fix — a database migration, a DNS change, an IAM policy edit, a DROP or a force push — take a backup and say plainly what the command changes. A rushed security fix that locks you out of your own server is a second incident, and often worse than the first.

Also check who has the keys. In a crisis, people share credentials to move fast, and those shares are never revoked. Make sure the accounts and permissions are still in the right hands after the dust settles.

Common mistakes teams make

The three mistakes we see most are fixing the loudest reporter's bug first, confusing severity with priority, and shipping a large risky "fix everything" change during an active incident. Each one makes the situation worse while feeling productive.

Other classics: marking a bug fixed before verifying it on the live environment, dropping the reproduction steps once the pressure lifts, and treating a workaround as a fix. A workaround buys time; it does not close the issue. Write the workaround down, keep the ticket open, and schedule the real fix.

Finally, teams forget to close the loop. After the incident, write a short note on what broke, what you fixed, and what you deferred. It doesn't need to be formal; it needs to exist. That note is what turns a painful week into a faster response next time.

A concrete scenario: the checkout that stopped charging

A small e-commerce shop notices orders arriving with zero totals while admin pages throw intermittent 500 errors and the contact form silently drops messages. The owner feels everything is broken. Triage finds the checkout failure first because it loses revenue every minute; the 500s are second; the contact form is third.

The checkout bug is high impact, high urgency — P1. The 500s on admin pages block staff but don't lose customer money directly, so they're P2. The contact form is frustrating but leads can still reach the business by phone or email, so it's P3. That order feels obvious in hindsight, but under pressure the loudest complaint — the contact form — often jumps the queue.

The likely root cause is infrastructure, not code: a hosting tier that can't handle the traffic or a cache misconfiguration. Or the checkout was broken by a recent change and slow pages are masking the real failure. The triage order stays the same regardless: fix the revenue blocker, verify it, then work down the list.

Alternatives compared

Different teams use different prioritisation models, and each has a place. The table below compares the main approaches so you can pick the one that fits your team size and the kind of bugs you actually see.

Model	What it optimises	Best for	Watch out for
Impact × urgency ranking	Money and blockage first	Live incidents, small teams	Needs someone to score honestly
MoSCoW	Must / Should / Could / Won't buckets	Release planning, stakeholder buy-in	Tends to overfill "Must"
RICE / ICE scoring	Reach, impact, confidence, effort	Product roadmap, not live incidents	Too slow for an active outage
Severity only	Technical severity of the defect	Compliance or security-first contexts	Ignores business context and usage
Ranked backlog	One ordered list, no tiers	Solo founders, very small teams	Breaks down past ~20 open items

In short

When everything is broken, don't fix everything at once. Write down every failure, score it by revenue impact, data risk and blocked people, and fix in that order. Small reversible changes beat one big risky fix. Verify on live traffic, keep a ranked list current, and run a blameless review afterwards. The order you fix things in is a business decision, not a technical one — and getting it right is what keeps the business alive while the bugs get closed.

People also search for

• How to run UAT without slowing a small business down
• What a slow site is actually costing you
• When a website outgrows shared hosting
• Which accounts your business should own outright
• What to check in the first month after launch
• How a web development quote breaks down

If your defect list has outgrown a spreadsheet and the fixes keep slipping, talk to our team. We can run the triage with you, fix the top issues in order, and set up the ongoing maintenance so you're not carrying the pager alone. The accounts, code and credentials stay yours — we just bring the process and the hands.