How should a SaaS startup run a UX teardown of an established competitor?

Illustrative situation: a founder demos an invoice-approval tool to a finance director. The director says it looks cleaner, then adds that her team already runs on a long-standing bookkeeping suite and knows where everything is. The founder goes home and writes down every screen the suite has. Six weeks later the roadmap is a copy of it, and the startup still has no answer to “why switch?” The scene is invented. It shows the mistake this guide helps avoid: a teardown that collects what the competitor has, not where a buyer would feel the difference.

Humbleteam, a digital product design agency, publishes this guide. It covers choosing journeys, getting honest access, reading public reviews, walking the tasks, scoring, choosing bets and testing them, with a worksheet and an invented worked example. Sources and product behavior are described as of November 6, 2026 and can change. This is not legal advice: read each product’s terms and ask a lawyer before you rely on any of this.

What is a teardown for?

A teardown is a competitive usability evaluation. Nielsen Norman Group defines that as comparing your product against several competing designs. It names two forms: an expert review, and a usability test where users do tasks on two or more designs. It also says the main goal is not to declare a winner. The goal is to improve your design, and to find opportunities beyond what competitors offer: “beat the competition, not copy them.”

So the output is a short list of places to differ and places to match, not a feature inventory.

Which journeys decide a switch?

Pick two to four. Our shortlist of five, drawn from what a buyer must believe before moving:

• First value: sign-up to the first useful result.
• The daily core task: the job the product exists to do, done repeatedly.
• Admin and setup: inviting people, setting roles, connecting other tools.
• Migration in: bringing existing data and habits across. Our guide to switching costs and migration UX covers designing this side.
• Pricing and upgrade: hitting a limit and paying.

Choose the journeys where a buyer compares you, not where the competitor is simply large. Nielsen Norman Group suggests 2 to 4 competitors and adds that smaller companies, or businesses only loosely related to yours, can teach you things too. We made a similar point in Sports apps copy the wrong competitors: look at similar behaviors, not only at direct competitors. If the first-value journey is your weak spot, this triage of onboarding fixes is the next read.

How do you get honest access?

Start with what the vendor publishes: documentation, a help center, release notes and a status page. GitHub, for example, publishes a changelog and a status page. Check whether your competitor publishes similar pages. Add a free trial or sandbox under your own name and work email, a demo request you book as yourself, and interviews with people who use the product and are free to talk about it.

Three limits apply.

1. No fake identity. Zoom’s terms of service have you warrant that registration information is accurate and complete, and G2’s guidelines bar reviews submitted under a false identity.
2. Read the terms before you sign up. Section 8 of Zoom’s terms (effective August 11, 2023) lists building or benchmarking a competitive product or service among prohibited uses. Other vendors may write something similar. If a clause bars you, use public sources, or test your own prototype against the same task.
3. Keep other people’s secrets out. Do not use screenshots from a former employee, a leaked deck or a customer’s private data.

How do you mine public reviews without fooling yourself?

Reviews can show repeated friction, but they are a self-selected pool. Use them to find questions, then check them in the walkthrough.

G2 says its guidelines also cover Capterra, Software Advice and GetApp. They require first-hand experience, ask reviewers to write only about experience from the past two years and note that trial reviews may be returned if the experience was too limited. So favor recent reviews and treat thin ones as thin. The same page says employees of a competitor may not review, which is another reason your team should not post.

To code them:

1. Read by hand and write each complaint in your own words. G2’s terms bar scrapers and other automated extraction, and Reddit’s user agreement bars scraping without written consent. Do not copy reviews in bulk.
2. Log one row per complaint: journey, theme, date, source, and reviewer role if shown.
3. Cluster rows into themes. Nielsen Norman Group’s affinity diagramming generates notes, clusters them into themes, then prioritizes. A theme becomes a lead when it appears in at least two sources and in a decisive journey. That threshold is our rule of thumb.
4. Report mentions, never “percent of users.”

App store pages and Reddit threads work the same way. Tag the source, because each audience differs.

How do you walk the tasks?

Write each task in the buyer’s words, such as “approve ten invoices that match a purchase order.” Use a fresh account and record the screen. For each task, log clicks, minutes, wrong turns, every error state you can trigger with honest input, and the empty states. Nielsen Norman Group lists success rate, time on task, error rate and satisfaction as the basic measures. Your walkthrough gives clicks and time from expert runs, which is not user performance. Label it that way.

Use two or more evaluators who work separately. Nielsen Norman Group says three to five people should evaluate independently, reserving about 1-2 hours per pass, then merge findings. It also warns that heuristics are guidelines, not laws, and that such a review cannot replace user research. Its ten heuristics, such as error prevention and recovery from errors, are a useful lens for the notes.

Which fields does the scoring sheet need?

Score key: 1 blocks or confuses the task, 2 works with friction, 3 clear and fast. Add the evidence link and capture date to every row.

Illustrative worked example: Tallyfold and Ledgerholm

Everything here is invented. Tallyfold is a fictional invoice-approval startup. Ledgerholm is a fictional established bookkeeping suite. Tallyfold’s two evaluators chose three journeys and gave pricing a quick look.

• First value: 14 clicks and 11 minutes to the first approved invoice, 2 wrong turns. Score 2.
• Daily core task: 63 clicks and 6 minutes to approve ten invoices, no batch action. Score 2.
• Migration in: importing 200 vendors failed on 3 rows with the message “Import failed” and no row number. It took two attempts. Score 1.

The evaluators coded 40 review passages from the past two years. Nine mention approval routing, seven mention import errors, six mention price surprises, and the rest are scattered. Two themes, routing and imports, match the walkthrough.

Tallyfold picks two bets: a migration preview that lists failed rows and why, and a visible approval route before a batch is sent. It chooses parity on the plan page and on standard exports, because being equal there is enough. It drops “more integrations” because no evidence supports it.

How do you turn findings into two or three bets?

A bet needs three things: a repeated complaint or a measured gap in a decisive journey, something you can ship soon, and a test that can fail. Put everything else on a parity list: things buyers expect and cannot be sold on. Also study where the competitor is better than you, as Nielsen Norman Group advises. A teardown that finds only weakness has probably missed something.

How do you test the bets with your own target users?

Recruit people who match your buyer, not colleagues. For a competitive test, Nielsen Norman Group suggests at most 2 or 3 designs per participant, alternating order, focusing on key tasks and asking for a final comparison. For qualitative findings, five users is its standard answer. Measured comparisons need more: its usability metrics article recommends around 20 users per design, so start qualitative.

If the competitor’s terms bar benchmarking, do not put participants in its product. Test your prototype on the same task and compare with your walkthrough baseline, and say in the report that this is a weaker comparison.

When should you bring in an agency, and what should it deliver?

Bring one in when you cannot field independent evaluators, when the decision is expensive, such as a rebuild, or when your team is too close to the product to judge it. A good teardown deliverable contains:

• The scope: journeys, competitors and why.
• The access method and capture dates.
• An evidence log with dated screenshots.
• The filled scoring sheet and the review-coding table.
• Two or three bets, each with a test plan.
• The parity list and what the team could not see.

Where do these defaults stop working?

A teardown sees only the surface. It cannot show performance, data quality or what a customer pays after negotiation. Products change, so date every capture; G2 asks reviewers for experience from the past two years for the same reason. The Nielsen Norman Group pages we cite range from 2001 to 2024, and we found no number for how many journeys to cover in them, so “two to four” is our suggestion. Terms of service differ and change. We read Zoom’s and G2’s, not every vendor’s. Capterra’s own pages blocked automated reading, so we rely on G2’s statement that its guidelines cover Capterra. Your sample of reviews may be small and skewed, and a first run is likely to be rougher than the example.

What can you produce now?

Five things, in about a week:

1. A list of two to four journeys and two to four competitors, with a reason for each.
2. An access plan: public sources, your own trial account, and a check of each product’s terms.
3. A review log with themes, mentions and dates.
4. A filled scoring sheet with clicks, minutes, error states and evidence links.
5. Two or three bets, a parity list and a test plan for your target users.

If you want a design partner for the bets, our comparison of agencies that publish B2B SaaS platform cases shows what each one publishes.