The pass where nothing gets to guess.
Here is the failure everyone has lived through. The site looks perfect on the laptop it was built on. It ships. Then a customer opens it on a three-year-old phone in a parking lot, and the hero text runs off the right edge, a button sits half a shade too light to read in the sun, and the page hangs for four seconds on a slow connection before anything appears. The build was never wrong on the builder's screen. It was only ever tested on the builder's screen.
Quality assurance is the cure for that. It is the pass where every claim about your site gets checked against a number instead of an opinion. Not "looks fine to me." Measured. On the widths your visitors actually hold, in the light and dark both, on the finished files a real server hands over, with the page source read the way an engine reads it.
- Contrast checked by number, against accessibility standards, in both light and dark themes, on every text-and-background pair on the page.
- Overflow audited at real phone widths, 360, 390, and 402 pixels, both edges, so nothing clips off the side and nothing drags into a dead sideways gutter.
- Speed measured on the production build, the actual files that go live, not the developer's warmed-up preview.
- Rendered HTML inspected, so we can prove a search engine or an AI answer engine sees your full content and not an empty shell.
- Forms, phone links, and analytics exercised, so the contact form reaches the inbox, the number dials on tap, and the tracking lands in your account.
- Every breakpoint walked, phone, tablet, and desktop, in the order a visitor's eye actually reads them.
What you will not find here is the thing most shops mean when they say "we tested it": a glance at the homepage on one screen, a nod, and a deploy. That is not testing. That is hope with a spell-check.
"Looks fine on my screen" is how sites break in public.
The most expensive two words in web work are "looks fine." They feel like a verdict. They are actually a blind spot with good posture.
Your builder has a big monitor, fast internet, and fresh eyes on a design they have stared at for a week. Your customer has a cracked phone, one bar of signal, and three seconds of patience. When the only test is "does it look fine to the person who made it," you are not testing the site. You are testing the most forgiving conditions the site will ever face, and then shipping it into the least forgiving ones.
The second villain is quieter: ship it and hope. Push it live, watch the analytics, and wait for a customer to email that the checkout is broken on their phone. By then the damage is done in the one place it counts, in front of a buyer who was ready to act and left instead. A bug found in QA costs you an hour. The same bug found by a customer costs you the customer, and you never even learn their name.
“A visitor who cannot read your button does not squint harder. They leave, and they do not tell you why.”
We name these villains because they are so ordinary. Nobody sets out to ship a broken page. It happens because the test was too easy, run once, by the one person least able to see the flaw. QA exists to make the test hard on purpose, run on the conditions that actually decide whether your site works: not the screen it was born on, but the hundred screens it has to live on.
The eye is a generous, unreliable judge.
Your eye wants the page to work. It fills in gaps, forgives a little low contrast, and reads text it already knows the words to. A first-time visitor's eye does none of that. So we take the judgment away from the eye and hand it to a number.
Take contrast, the single most common failure on the web. Text needs a measurable ratio against its background to stay readable, a real threshold set by accessibility standards, not a vibe. A brand color that looks crisp on a white page often drops below that line the moment it lands on a dark surface, or as pale text on a photo. By eye, it "looks okay." By number, it fails, and the visitor reading in sunlight proves the number right. So we measure every pair, in both themes, and fix anything under the line before it ships. Not the ones that look bad. Every one.
Overflow works the same way. A page can look clean and still drag sideways into an invisible gutter, or hide a button a few pixels off the right edge of a narrow phone. The eye scrolling a screenshot misses it. The measurement does not: we check every element's edges against the real viewport width, flag anything that crosses the line, and contain it.
This is the difference between QA that has a spine and QA that has a shrug. "It looks accessible" is a shrug. "Every text pair clears the contrast threshold in both themes, here are the numbers" is a spine. One of those survives a customer on a hard device. The other survives only until the first one shows up.
Four proofs. Each one measured, each one re-run until clean.
Every page goes through the same loop before it earns a launch. This is not a checklist we tick from memory. It is four proofs, each with a number attached, each re-run after any fix until it comes back clean. Open each one.
STEP 1Contrast, by number+
Every text-and-background pair on the page is measured against the accessibility contrast threshold, in the light theme and the dark theme both. Buttons, body copy, captions, links, text sitting over an image, all of it. Anything under the line gets its color adjusted and re-measured, not softened by eye until it "looks better." A pale outline button on a dark surface is the usual culprit, and it gets fixed specifically. We do this on the finished build, so the numbers we report are the numbers a visitor gets.
STEP 2Overflow, at real phone widths+
The page is audited at 360, 390, and 402 pixels wide, the widths of the phones people actually hold, in both themes, after a clean reload scrolled to the top. Every element's left and right edges are checked against the viewport. Two failures get caught here: content wider than the screen that clips or shifts, and the sneakier one, a page that looks correct but drags sideways into empty dead space. Both are failures. The offending element gets contained and the audit re-runs until it returns nothing.
STEP 3Speed, on the production build+
Loading is measured on the actual files that go live, not a warmed-up developer preview that flatters the result. Because the site is hand-built and served as finished static files, there is rarely heavy machinery to unwind, so we build to pass the speed standards outright rather than sprint to repair a slow page at the end. If a measurement comes back soft, we find the weight, usually an oversized image, and cut it before launch.
STEP 4Rendered HTML, read like an engine+
We inspect the page source the way a crawler or an AI answer engine sees it, and confirm the headline, the body copy, and the key content are present in the raw HTML, not painted in afterward by scripts. Real links with real destinations. A unique title and description on every page, not the homepage's copied down the line. If an engine would see an empty shell, the page fails, because a page engines cannot read is a page customers will never find.
When any proof fails, the fix goes in and the whole affected proof runs again. Nothing gets waved through on a "close enough." The page is done when all four come back clean, on the build that ships, and not a moment before.
A page has two audiences, and both get tested.
There are two kinds of visitor now, and a page has to satisfy both. The human, on whatever device is in their hand. And the engine, deciding whether to show your page at all, or to read it aloud as the answer when a buyer asks who to hire.
The human side is the part you can feel. Text at a size a real person can read, on a real phone, in real light. Contrast that holds when the sun hits the screen. A layout that stacks in a sensible order on a narrow width instead of scattering. Buttons big enough to hit with a thumb. Tap targets that respond, forms that submit, a phone number that dials the instant it is touched. We test the site the way a tired customer uses it, not the way a proud builder demos it.
The engine side is the part you cannot see but cannot afford to skip. A search engine builds its map from real links and real HTML. An AI answer engine cites sources it can read cleanly, structured, fast, and factual. If your content only appears after a pile of scripts runs, the engine may see nothing worth citing, and your next customer gets someone else's name as the answer. So the rendered-HTML proof is not a technicality. It is the difference between being found and being invisible, and it belongs to the same foundation as search engine optimization built in from the first commit.
“Half your audience never sees the page. It reads the code. QA is where you make sure the code says something worth repeating.”
Both audiences get the same treatment on every page: measured, re-run, proven. The human should never have to fight the layout to reach the point. The engine should never have to guess what the page is about. When both are true, the page is doing its job for everyone who arrives, on a screen or through an answer.
This isn't a phase you buy. It's how we ship.
Most shops treat QA as a line item, or worse, as a phase they skip when the calendar gets tight. Testing is the first thing cut under deadline pressure, which is exactly backward, because the deadline is when a rushed build most needs a check. That is how "we'll test it after launch" becomes "the customer tested it for us."
We do it the other direction. Quality by numbers is wired into how every site gets built, laid in as the work happens rather than bolted on at the end. It is baked into the custom web design and development that every project starts from, so there is no version of a Web Leveling build that ships untested. You do not buy QA. You get it, because a page that has not been proven is not finished, and we do not hand over unfinished work.
That has a plain consequence for what a launch means here. Launch day is not the day we cross our fingers. It is the day four proofs already came back clean on the build that went live. The contrast passed by number in both themes. Nothing clipped or dragged at real phone widths. The page loaded fast on the production files. Engines could read the whole thing. All of that happened before the domain ever pointed at the site.
And because your site is yours, the standard travels with it. The clean, static, engine-readable shape that made your pages easy to prove is the same shape that keeps them fast and findable for years. QA is not a service that ends when we hand you the keys. It is a property of the thing you own.
Asked and answered, before the call.
Q1What does QA cost?+
Nothing extra, and here is the honest version. Quality assurance is built into every build we do, not sold as an add-on or an upsell. There is no separate QA invoice, no "testing package" priced on top, no line item you can decline. The setup fee and flat project number you see before we start already include it, because we don't ship a page we haven't proven. If a shop is quoting QA as its own charge, ask what their untested version looks like.
Q2Can you guarantee my site will be bug-free?+
No, and be wary of anyone who says yes. Testing lowers risk and catches what matters before a customer does, but no honest process proves zero defects exist. What we can promise is method: contrast measured by number, overflow checked at real phone widths, speed audited on the production build, and rendered HTML an engine can read, all re-run until clean. That is real protection, stated without the fantasy attached.
Q3What exactly do you test?+
Contrast against accessibility thresholds in both light and dark themes. Overflow at real phone widths, both edges, so nothing clips or drags sideways. Load speed on the production build. The rendered HTML, so engines see your full content. Plus the working plumbing: contact forms reaching the inbox, phone numbers dialing on tap, analytics landing in your account, and the layout holding at every screen size. Facts, not a fog of jargon.
Q4Why measure contrast instead of just looking?+
Because the eye is generous and unreliable, and your first-time visitor's eye is not. A color that looks readable on the builder's screen can fail the accessibility threshold in sunlight or in the other theme. Measuring removes the guesswork: every text pair either clears the number or gets fixed until it does. "It looks fine" has shipped more broken pages than any other sentence in this business.
Q5Do you test on real phones, or just shrink the browser?+
We audit at the actual widths real phones use, in both themes, after a clean reload, checking both edges of every element, and confirm on a real device where it counts. A quick browser resize misses the two failures that matter most: content that clips off the side, and a page that looks right but drags into an empty sideways gutter. Both get caught and contained before launch.
Q6Does QA slow the project down?+
No. Because the site is hand-built to be clean and static from the start, most of what heavier builds have to repair at the end simply isn't there to fix. The proofs run as the work happens, not as a scramble before launch. What actually stretches a timeline is waiting on photos and approvals, never the testing. Proving the page is the fast part.
That is quality assurance, told straight: measured, re-run, and already done before your site goes live. If your current site has never been checked by anything harder than the screen it was built on, that is the crack worth closing first. Tell us what feels off and we will reply in plain English, within one business day.