Pre-launch design QA checklist for startups: what to test before you ship

A pre-launch design QA pass checks that what shipped matches what was designed: every state, every breakpoint, real data, real copy, and the first-run path. Block one focused day, test on real devices, fix issues on the core flow first, and log the rest. Skip it and your users do the QA for you.

Why design QA is not the same as code QA

Your engineers test whether things work. Design QA tests whether things feel right and make sense to someone seeing them for the first time. A button can pass every automated test and still sit 6 pixels off from the rest of the row, say "Submit" where the flow needs "Create workspace", or disappear behind the keyboard on a phone.

None of that breaks the product. All of it tells a new user how much care went into it. Early users decide quickly whether your team sweats details, and they rarely tell you when the answer is no. They just leave.

That is why design QA needs its own pass, with its own checklist, before launch. It is not a replacement for the handoff, which we cover in our design handoff checklist for startups. Handoff is what you give engineers. QA is what you check after they build it.

Start with the path a new user takes

Before you look at any single screen, walk the whole first-run path as a stranger would. Use a fresh account, a private browser window, and no shortcuts.

Go from the landing page to signup, through any verification email, into the first screen of the product, and to the first moment the user gets real value. Time it. Write down every spot where you hesitated, even for a second. Those hesitations are what a real user will feel, only stronger.

Pay attention to the handoffs between surfaces. The marketing site, the signup form, the confirmation email, and the app often get built at different times, and they drift. Fonts differ, button styles differ, the product name is capitalized three ways. A visitor experiences those as one product, so check them as one product.

Check every state, not just the happy one

Designs usually show the happy path: a full dashboard, a completed form, a smooth success message. Real users spend a lot of time in the other states. Build a list per screen and tick each one off.

• Empty: what a new account sees before any data exists. This is the first screen most users meet, and it is often the one nobody designed.
• Loading: skeletons or spinners, and what happens when loading takes ten seconds instead of one.
• Error: failed requests, invalid input, expired sessions, lost connection. The message should say what happened and what to do next.
• Partial: one item instead of twenty, or a single-word name in a layout built for long names.
• Overflowing: a 60-character company name, a 400-item list, a table with a column that refuses to wrap.
• Disabled and hover and focus: every interactive element, including keyboard focus, which is the state teams skip most often.

If your product has AI features, add one more: the response that is slow, wrong, or empty. We wrote about this in how to design AI features your users actually trust, and it is where launch-day trust is won or lost.

Test with real data, not lorem ipsum

Design files run on perfect data. Production does not. Names have apostrophes, currencies have different formats, dates cross time zones, and one customer will upload a 14 MB logo.

Seed the product with messy but realistic content before you review it. Use long names, short names, missing fields, emoji, right-to-left text if you serve those markets, and the ugliest real record you can find. Then look at what breaks: truncation, collisions, layouts that stretch, charts with a single data point.

Do the same for images. A hero image that looks great in Figma can turn into a blurry smear on a high-density display or a 4 MB download on mobile data.

Check breakpoints on real devices

Resizing a desktop browser window is a start, but it is not a test. Pick three real devices: a recent iPhone, a mid-range Android phone, and a laptop with a smaller screen than yours. Open the product on each one.

Look for tap targets that are too small to hit with a thumb, sticky headers that eat a third of the screen, modals that cannot be dismissed, and forms where the keyboard covers the field you are typing in. Rotate the phone. Zoom the text up one notch, because plenty of people do.

If you are building the marketing site in Framer, also check the breakpoints between the standard ones. Layouts tend to hold at 390, 810, and 1200 pixels and wobble at the sizes in between.

Read the copy in context

Copy that looked fine in a doc often fails on the screen. Read every label, button, tooltip, error, and email as the user would, in the order they would see it.

Look for three things. First, consistency: does the same action have the same name everywhere? Second, tone: does the error message sound like the same company as the landing page? Third, clarity: could someone with no context tell what happens when they press the button?

This is also the best time to catch placeholder text that slipped through. "Lorem ipsum," "Button," "Title goes here," and "TODO" have all shipped in real products.

Review motion and speed

Animations that feel polished in a prototype can feel sluggish or janky in the real build. Check that transitions are quick, that nothing flashes or jumps when content loads, and that motion never blocks an action. If someone has reduced motion turned on in their system settings, the product should respect it.

Then check speed as a user feels it, not as a score. Open the product on a throttled connection. Watch what appears first. A page that shows nothing for three seconds feels broken even if the total load time is fine.

Triage: what blocks launch and what can wait

You will find more issues than you can fix. That is normal. The mistake is treating all of them equally, which either delays launch for weeks or ships with the wrong things broken. Sort every finding into one of three buckets.

Bucket	What goes in it	What you do
Blocks launch	Broken or confusing steps on the first-run path, unreadable text, anything that makes the product look unfinished on the first screen	Fix before launch
Fix this week	Visual inconsistencies on secondary screens, missing states in less-used areas, small copy issues	Schedule right after launch
Log it	Polish items, edge cases that affect very few users	Put in the backlog with a screenshot

The rule of thumb: if a new user would hit it in their first ten minutes, it blocks launch. If only a returning user would hit it, it can wait.

Every issue should have a screenshot, the device or browser, and one sentence on what is wrong. Vague notes like "spacing feels off" send engineers back to ask questions and cost you a day.

Who should run the pass

Not the person who built it. Builders see what they meant to build, not what is on the screen. If you are a founder, you are also too close to it. Ask someone who has never seen the product, or hire someone whose job is to look at it with fresh eyes and a trained eye for detail.

This is one place where the person reviewing needs product judgment, not just a good eye. A pixel-level audit is useful, but the harder question is "does this screen help the user get to value, or just look finished?" At Artone, Razvan reviews every deliverable before it ships, and that review is as much about whether the decision serves the business as whether the spacing is right. If you are building under a deadline, we can run that pass for you, before your launch rather than after your first support tickets.

A one-day schedule for the pass

If you only have a day, here is a split that works for most early-stage products.

1. First hour: walk the first-run path on a fresh account and note every hesitation.
2. Next two hours: go through each core screen and check every state against your list.
3. Next hour: load realistic, messy data and see what breaks.
4. Next two hours: test on real devices and a throttled connection.
5. Last hour: triage, write up the issues with screenshots, and agree on what blocks launch.

Fixing starts the next morning. Do not mix finding and fixing on the same day, because fixing as you go makes you stop looking.

What to do when you cannot fix everything

Sometimes launch day is fixed. A conference, an investor update, or a Product Hunt slot will not move. In that case, narrow the surface instead of shipping everything at lower quality. Hide the half-finished settings page. Cut the feature with three unresolved bugs. Launch the one flow you trust and keep the rest in private beta.

A smaller product that feels solid beats a bigger one that feels rushed. If you are weighing how much to build before you launch at all, our piece on how much design your MVP actually needs walks through where to draw the line.

After launch, keep the habit

The best teams do a lighter version of this pass on every release, not just the big one. Fifteen minutes on the new screens, on a real phone, with real data, catches most of what would otherwise reach users. If you are using AI tools to ship faster, the pass matters more, not less, because generated interfaces tend to look right at a glance and fail on states and edge cases. Our post on why AI-built products look vibe coded covers what to look for.

Get a second pair of eyes before you launch

If you have a launch coming and want a trained review of what you have built, we can walk through it with you, find what blocks launch, and fix it with you or hand you a clear list. Book a call or send us a message and tell us what you are shipping and when.