Breakpoint Math on Small Screens: Table Stakes for Responsive Layouts

You'd think picking a few pixel widths for your responsive site would be simple. It's not. On small screens, the math gets messy fast, and if you get it wrong, you're not just losing style points—you're losing users.

So who actually needs to sweat this? Front-end devs, product managers, and anyone who's ever watched a client stare at a phone and ask, 'Why is this button so tiny?' If that's you, read on. We're cutting through the noise and getting to real breakpoint tactics that hold up.

Who Calls the Breakpoint Shot and When?

The decision owner: dev, designer, or PM?

Ask five teams who owns breakpoints and you will get five different shrugs. The designer says they handed over a Figma file with three frames. The developer says they “just made it work” during implementation. The PM assumes someone is tracking which devices actually show up in analytics. Nobody is wrong, exactly—but nobody is accountable either. That vagueness is where the layout starts to rot.

In practice, the developer becomes the de facto breakpoint authority by default. They're the one staring at the CSS at 2 a.m., squeezing a card grid into 360 pixels. But making that call in isolation means product decisions get baked into code without a conversation. The designer’s intent for “spacious, editorial” becomes a cramped two-column mess because no one checked whether the tablet portrait breakpoint ever gets hit.

What works better? A named owner who is not the PM. Someone with veto power over “just add another breakpoint” requests. I have seen teams rotate this role between a senior designer and a front-end lead, and the rotation forces both sides to learn the other’s constraints. The PM can advocate for business needs—conversion rate, ad visibility, signup friction—but should not pick pixel values.

Timing: before the first line of CSS or after user testing?

The tempting answer is “after testing, when we have real data.” That sounds responsible. The catch is you already wrote 4,000 lines of responsive CSS by then, and retrofitting a breakpoint strategy means touching every component. Most teams skip this step until the mobile layout breaks in a demo to a client. Wrong order.

Breakpoints should be chosen before the first layout is implemented, but not in a vacuum—you do a quick audit of your top 20 traffic sources, pull screen-size data from analytics, and map out a proposal. The decision is provisional, not final. You test it, you refine it, you move on. What you don’t do is “design fluid first, then add breakpoints later” and hope the seams line up.

“You can’t test your way into a breakpoint strategy if the first version was built without one. The refactor cost is always higher than the planning cost.”

— front-end architect, mid-size SaaS team

Why your analytics should have a say

Here is the uncomfortable truth: your most common screen size is probably not 375px or 768px. It's some oddball like 412×915 on a budget Android, or a desktop window at 1280×695 because your users keep their browser half-snapped. Cookie-cutter breakpoints from a framework ignore that reality.

Pull the data before you argue about pixel values. A five-minute analytics check will settle more meetings than any design principle. The trade-off is that data is descriptive, not prescriptive—just because most users are on 390px doesn’t mean you optimize only for that, because the 1024px tablet cluster might drive higher engagement per session.

That said, analytics should inform, not dictate. You still need design judgment about where content actually breaks. The numbers tell you where to look; your eyes tell you what to fix. One rhetorical question worth asking: what is the cost of being wrong here? If you miss a breakpoint, you get a layout that squishes awkwardly. If you add too many, you get maintenance bloat that slows every future change.

The real decision moment is earlier than most teams expect—before the first component is built, not after the first complaint lands in the bug tracker. Get the owner named, get the data pulled, get the provisional plan written. Then start the CSS. You can always adjust the math later, but you can't recreate the week you wasted rebuilding from scratch.

The Breakpoint Menu: What Are Your Options?

Fluid grids with no fixed breakpoints

Some teams swear off breakpoints entirely. Their layout uses percentage widths, clamp(), and vw units so everything stretches or squeezes continuously. No snap points, no media queries, just a layout that oozes from phone to ultrawide. The math is done once, then forgotten.

The appeal is real. You never argue about where 768px should live. You never wake up to a ticket saying "the sidebar looks odd on a Galaxy Fold." Everything just… works. But the cost is subtle. A fluid grid has no natural resting place. Text can hit uncomfortable line lengths at in-between widths, and component relationships — say, a thumbnail beside a headline — start to feel arbitrary when both are actively fighting for space. I have watched designers burn days trying to tune clamp() ranges to fix a problem that a single well-placed breakpoint would have solved in minutes.

That sounds fine until you need real hierarchy shifts. A fluid grid can resize a card, but it can't move that card from a two-column arrangement to a stacked one unless you declare one explicitly. Which means you're doing breakpoints anyway — just without admitting it.

Device-class breakpoints

This is the old standby: mobile, tablet, desktop. Usually 480, 768, and 1024 pixels. The logic feels safe — everyone owns these devices, right? Wrong, actually. That assumption breaks the moment someone pulls out a phone measuring 812, 896, or 932 points across. A 768px breakpoint is supposed to catch tablets, but it also catches large phones in landscape mode, and small tablets in portrait look identical to oversized phones.

Odd bit about html: the dull step fails first.

Odd bit about html: the dull step fails first.

Odd bit about html: the dull step fails first.

Odd bit about html: the dull step fails first.

Odd bit about html: the dull step fails first.

Device-class breakpoints also encourage a pernicious habit: designing for the category, not the content. You get a "tablet version" that's simply a slightly narrower desktop layout, with all the awkward whitespace and cramped three-column grids that implies. The catch is that device classes are a moving target. When I started doing responsive work, the common tablet width was 1024px. Now it's 1366 or even 1440 for many Android tablets. Your three-tier system is already outdated.

Worth flagging—this approach is not useless. For quick prototypes, or sites with genuinely simple layouts (a hero, one column of text, a footer), device-class breakpoints give you a skeleton you can ship fast. The problem is treating them as final tuning rather than a rough draft.

Content-first breakpoints

Here the layout decides the breakpoints, not the device. You let a component render naturally, watch where it breaks — where text starts to wrap awkwardly, where the spacing between elements gets visually dead — and you set your breakpoint at that exact width. No 480/768/1024 clichés. You're measuring your content's breaking points, not guessing at someone's hardware.

The practical upside is that every breakpoint has a visible reason for existing. That 620px threshold? It's the width where the author bio's two-column layout starts squeezing the avatar into an unrecognizable oval. The 980px threshold? That's where the four-card grid begins leaving a single orphan card on the last row with too much breathing room. These breakpoints make sense to anyone who ships code, and they're easier to defend in review meetings.

If a breakpoint can't answer "what exactly breaks here?" then it exists for decoration, not function.

— a rule of thumb I share with every team I have coached

The trade-off is effort. You have to build the thing first before you know where the seams live. That means more iterations, more resizing in the browser, more fiddling with real content rather than lorem ipsum. But the payoff is a layout that feels intentional at every width — not just at the three or four presets you happened to test.

The tricky part is that content-first breakpoints go stale. Your content changes, type scales grow, new sections get added, and suddenly that 620px beak point is 140px off. Device-class breakpoints at least have a certain fossilized stability. Content-first ones demand ownership. If nobody owns them, they rot quietly — and your site starts resembling a jagged staircase of oddly placed media queries.

How do you choose? Start by looking at your last month of analytics. Ignore the device names entirely. Look at the actual viewport-width buckets. If your visitors cluster hard at 360, 768, and 1366, device-class might behave identically to content-first. But my bet — and it's unfair how often this is true — is that your long-tail traffic spans everything from 344 to 2560, and only a content-first strategy covers that spread without bloat. That's the question worth asking before you write a single @media rule. What does your content actually need at this width, and where does it visibly fall over if you don't respond to it?

How to Judge Any Breakpoint Strategy

Does It Match Your Content’s Natural Break Points?

Start with the content, not the device. A strategy that looks elegant on paper fails the moment your text starts wrapping awkwardly at 768px. Pull up your longest headlines, your widest tables, your most cramped form fields. Where do they physically break? That’s your real breakpoint map, and it rarely aligns with Apple’s or Google’s defaults.

The tricky part is that this changes as content evolves. A breakpoint that worked for last quarter’s pricing page might choke on this quarter’s new feature grid. So ask: does this strategy bend when your content does? Fixed pixel targets are brittle here. Fluid-ish approaches—percentage-based columns, clamp() for type—absorb small shifts without a redesign.

If your breakpoints serve the layout instead of the content, you’re designing for screenshots, not for readers.

— noted by a front-end lead after a client demo went sideways

Is It Easy for Your Team to Maintain?

I have seen teams inherit a 14-breakpoint system held together by comments like “// don’t touch this.” That hurts. Every change requires a archaeology dig through nested media queries. A better test: can a new developer open your CSS and explain the breakpoint logic in under ten minutes? If not, you’re paying technical debt every sprint.

Maintainability also means naming things for intent, not size. “Stack on mobile” beats “max-width: 767px” because it survives when the breakpoint shifts. And limit the number of places you define breakpoints—one SCSS map, one CSS custom property set, not five scattered files. Teams abandon strategies that feel like chores.

Does It Play Nice With Your Analytics and Testing?

Most teams skip this and regret it later. Your breakpoint strategy should map cleanly to the viewport ranges you’re tracking in analytics—otherwise you can’t tell whether the mobile layout is actually helping conversion or hurting it. If your data only reports “mobile” vs. “desktop,” you’re blind to the messy middle where tablets and small laptops live.

Reality check: name the html owner or stop.

Testing compounds the problem. A strategy that seems logical in a responsive preview tool can behave differently in real browsers with scrollbars, zoom settings, or device pixel ratios. The catch is that some tactics—like fluid grids with min-widths—are easier to test across weird sizes than rigid breakpoints that snap at arbitrary values.

One practical signal: does the strategy let you set up visual regression tests without a roadmap? If you need a spreadsheet to know which breakpoints to screenshot, that’s overhead nobody budgets for. We fixed this by standardizing on three core widths for QA, then letting fluid behavior handle everything between them. That gave us coverage without a hundred test cases. Wrong order—analytics should drive the breakpoints, not the other way around.

Fixed vs. Fluid: The Trade-Offs Nobody Spells Out

Fixed breakpoints: predictable but brittle

Fixed breakpoints feel like a promise: at 768px, the layout snaps to a tablet grid; at 1024px, it stretches to desktop. Predictable, testable, easy to explain to a stakeholder who wants a screenshot at each size. That certainty evaporates the moment a phone in landscape mode lands awkwardly between your chosen widths. The 767px phone becomes a 768px tablet with one extra pixel of width, and suddenly your navigation is squeezed into a layout it was never meant for. I have debugged this exact scene more times than I care to count—the seam blows out, the hamburger icon overlaps the logo, and the fix takes longer than the original build. Fixed breakpoints are brittle because they assume the world sorts into tidy buckets. It doesn't.

Fluid grids: flexible but harder to control

Fluid grids, by contrast, stretch and shrink with every pixel. Content flows like water; no hard edges, no awkward gaps. That sounds fine until you realize water has no memory—it will happily stretch a headline to 120 characters wide on a 27-inch monitor, or compress a paragraph into unreadable slivers on a narrow fold. The trade-off is control. With fluid layouts, you trade the ability to say "this column is exactly 300px" for the ability to say "this column is 30% of whatever space you give it." That flexibility is liberating, but it pushes complexity into your CSS math, media queries still fire, and the edge cases multiply. What usually breaks first is the image—a fixed-width graphic inside a fluid container that distorts or overflows with no obvious culprit.

Choose fixed when you need certainty, fluid when you need survival, hybrid when you need both—but never pretend the middle is free.

— senior front-end engineer, post-mortem review

Hybrid approaches that combine both

The hybrid path is where most production layouts land, whether teams admit it or not. Start with a fluid base for text and gutters, then clamp sizes at specific breakpoints for components that can't survive distortion—tables, complex forms, multi-column card grids. The math gets messier, but the payoff is a layout that breathes on a 320px phone and still locks down at 1280px. One practical pattern: define a fluid scale for typography using relative units, then reserve fixed breakpoints strictly for layout shifts (one column to two, two to three). That way, text never breaks, and structural changes happen where the user actually notices them. The catch is that hybrid systems demand more discipline—you need a documented rule for what gets fluid treatment versus fixed treatment, otherwise future edits will blur the line. A simple heuristic: if a component's content can reflow naturally, make it fluid; if it can't (think a pricing table with five columns), pin it to a breakpoint and accept the jump. Test the seams on real devices, not just browser resizes—emulators lie about touch targets and scroll behavior. Start with the fluid base, then layer in breakpoints only where the layout visibly fails; you will cut your media query count by half and lose nothing.

From Math to Markup: Implementing Your Breakpoint Plan

Start With CSS Custom Properties, Not Hard-Coded Pixels

The quickest way to sabotage your own breakpoint strategy is to scatter raw media query values across a stylesheet like birdseed. Every time I audit someone's CSS and see `@media (max-width: 768px)` in eleven places, I know the layout is already fighting itself. The fix is boring but effective: define your breakpoint thresholds as custom properties on `:root`, then reference them in every media query. One source of truth, one place to adjust when the math changes — which it will, the moment a client shares a screenshot from a Samsung Galaxy Fold.

Here's the pattern that works in practice. Set your tokens like `--bp-sm: 30rem`, `--bp-md: 48rem`, `--bp-lg: 64rem`. Then write your queries as `@media (min-width: var(--bp-md))` — yes, that works in every modern browser, and yes, it feels awkward for the first week. The payoff arrives when you discover your true breakpoint should be 50rem instead of 48rem. That's one edit in the root, not a scavenger hunt through 400 lines of CSS. That said, keep the custom properties in a single `tokens.css` file, not scattered alongside component rules. I have seen teams bury `--bp-md` inside a button component and then wonder why their nav collapses at 47rem.

Wire Breakpoints Into Your Build Process, Not Just Your Browser

Your build pipeline is where breakpoint math either lives or dies. Most teams stop at the CSS and rely on DevTools emulation to "verify" responsive behavior — which catches about sixty percent of the real problems. The missing chunk shows up as layout seams on physical hardware, especially when browsers apply different default font sizes or when the viewport meta tag isn't playing nice. We fixed this by adding a post-build step that parses the CSS and flags any media query outside the accepted token list. Wrong order. That rule catches typos like `max-width: 480` before they ship, not after the producer's phone renders the hero section at half height.

The other piece is generating a static `breakpoints.json` from your build that maps each component's behavioral changes. Not a design-system luxury — a debugging necessity. When someone reports "the table squishes at 23rem," you can grep the JSON, find which component owns that range, and see whether it's using a fluid container or a fixed one. The output feels like overkill until you're chasing a bug at 2pm on a Friday; then it's the difference between a twenty-minute fix and an afternoon of resizing windows.

Emulators lie about touch targets, viewport scaling, and actual pixel density. Your phone tells the truth, whether you want to hear it or not.

— front-end engineer, responsive testing session

Test on Real Devices, Because Emulators Flatter

The hardest part of implementation isn't writing the media queries — it's verifying them against the mess of real-world hardware. Chrome DevTools' device toolbar is a starting point, not a finish line. It simulates pixel dimensions but not the subtle way an iPhone's safe area eats into your bottom padding, or how Android's dynamic font scaling can push a 16rem container past its parent. We keep a physical drawer with an older iPhone, a mid-range Android, and a small tablet; testing there catches more edge cases than any emulator preset.

One practical habit: set your testing viewport to the actual CSS width, not the device pixel ratio. A phone reporting 360px CSS width will render your `--bp-sm` query at 30rem? Only if the device's default font size is 16px. When a user bumps their system font to 20px for readability, "30rem" jumps to 37.5rem, and your carefully planned breakpoint no longer fires where you expected. That's the trade-off nobody spells out — rem-based breakpoints respect user settings but complicate your math. The fix is to test with an oversized root font during development, not just the default. It takes five extra minutes and saves you from shipping a layout that breaks for every visually impaired user with a preference.

When Breakpoints Go Wrong: The Costs of Skipping the Math

Overlapping Breakpoints That Cause Layout Jumps

The tricky part is that breakpoints don't fail loudly. They fail at 767 pixels, then again at 768, then again at 769. I have fixed the same mobile menu three times in one week because the CSS was tuned for a viewport that never existed in the wild. When two media queries overlap — say, one at max-width: 768px and another at min-width: 760px — the browser picks the winner by source order, not by your intent. That causes a jarring reflow as users rotate their phones or resize a split-screen window. Layout jumps feel like bugs, even when the math technically works.

Most teams skip the arithmetic and just stack breakpoints at "common device widths." Then a 390px iPhone and a 412px Android render completely different compositions, and neither matches the design mockup. Wrong order. A better approach is to define breakpoints where your content actually needs them — where the text starts wrapping awkwardly or the grid gets cramped — not where a marketing deck says "phones end here." The cost of skipping this is debug time. And debug time is expensive.

“A breakpoint is a promise that your layout won't lie to the user. Broken promises cost more than broken pixels.”

— front-end engineer, on a call about a collapsing checkout form

Ignoring Small-Screen Reality and Hurting Conversions

What usually breaks first is the checkout flow. If your breakpoint math forces a two-column form into a single column at exactly 600px, but your analytics show most mobile users at 360px, you're serving them a cramped, scroll-heavy experience. They abandon. Then you blame the traffic, not the CSS. That hurts.

Reality check: name the html owner or stop.

The catch is that conversion rates don't dip because the page is "mobile-friendly" — they dip when buttons shift mid-tap or images overflow viewport edges. Small screens amplify every spacing error. A 12px difference in padding that looks harmless on desktop becomes a misaligned call-to-action on a 5-inch display. We fixed this by testing at real widths, not simulated ones. Pull the browser window to 320px, 375px, and 414px. What you see is not optional polish; it's revenue discipline.

SEO Impact of a Poor Mobile Experience

Search engines don't read your CSS, but they do read the signals your layout sends. When breakpoint math is sloppy, mobile pages load slower because images sized for desktop are squeezed or hidden — not resized. Slow rendering means higher bounce rates, shorter dwell time, and lower rankings. That's not a myth; it's a compounding penalty that grows each week you ignore it.

Also consider this: a single misapplied breakpoint can push your content below the fold on mobile, making the visible text thin and incomplete. Google's mobile-first indexing treats that as a quality signal problem. You lose visibility, then you lose clicks, then you lose the argument for fixing it later. Every day you postpone the math, the debt accrues interest.

The fix is not elegant. Audit your current pages at three real widths, document where the seams blow out, and force a pause on new features until the breakpoint plan is explicit. Do that before the next sprint, or watch the metrics drift. Your choice.

Breakpoint FAQ: Answering the Questions Teams Actually Ask

How many breakpoints is enough?

Three, if you’re honest about your content. One for phones, one for tablets, one for desktops — and then you stop. The teams I see fail are the ones who add a breakpoint for every device in the QA matrix. That’s not engineering, it’s hoarding. Each new breakpoint doubles the number of layout states you have to test, and most of those states will never be seen by more than 0.2% of your visitors. The real question isn’t “how many can we justify?” but “how few can we survive with?” Start with three. Add a fourth only when a specific component — a data table, a nav bar — physically breaks at a measured width. Not when a designer feels nervous.

Should breakpoints be based on device or content?

Content. Every single time. Device-based breakpoints are a trap because devices keep multiplying — foldables, ultrawides, smart TVs, whatever ships next quarter. Your content doesn’t care about the device name; it cares about available space. A 320px phone and a 400px smartwatch face have different widths but similar constraints. A 768px tablet in portrait and a 1024px laptop window share more layout behavior than their labels suggest. I have seen teams hardcode breakpoints for “iPhone 14 Pro Max” and then scramble when Apple moved the notch. Measure your text, your images, your table columns — not the hardware. The breakpoint is where the content stops looking right, and that number is universal.

The pragmatic approach: set your base styles for the smallest screen you support (usually 320px). Then write one media query for the width where your headline starts wrapping awkwardly, another for when your sidebar starts hugging the main column, and a third for when your nav becomes usable as a horizontal bar. Those thresholds will be eerily close to 480px, 768px, and 1024px across most sites — not because of Apple or Samsung, but because human reading patterns and line lengths are fairly constant. That’s the math that matters.

What about high-DPI and foldable screens?

High-DPI is a red herring for breakpoints. DPI affects image sharpness and font rendering, not layout width. A 2x display still reports its CSS pixels to the browser, so your breakpoints fire at the same logical widths regardless of pixel density. What you should care about is viewport units — don’t confuse dpi with viewport size. The only exception is when you’re serving responsive images via srcset, and even then, that’s an asset strategy, not a breakpoint strategy.

Foldables mess with the assumption that width is linear. The Surface Duo’s hinge sits right in the middle of what would be a 684px viewport — your layout can’t just scale; it needs to account for a physical gap. The rough fix is to treat the hinge as a fixed gutter and test at both the folded width (360px) and the expanded width (720px). Most teams I talk to either ignore foldables entirely or add a hacky spanning CSS flag that breaks in Chrome. The honest answer: foldables are rare enough that you can deprioritize them, but if you want to future-proof, design your 700px–800px range with less density — avoid forcing content across the center seam.

The tricky bit is that foldables break your breakpoint math because the viewport jumps in discrete steps, not smoothly. One day a user is at 376px, the next they unfold to 714px. You can’t interpolate; you have to make both states work. That means your middle breakpoint needs to be forgiving — roughly 640px to 800px — and you should test with the device emulator turned on, not just resizing a browser window. A browser resize is continuous, but a foldable is binary, and layouts that survive a drag often fall apart on the seam.

We spent two weeks chasing a bug that only appeared on the foldable’s expanded view. Turned out the hinge offset pushed our grid into a 1px horizontal scroll. Fix was one line of CSS — but we never would have found it without testing on the actual device.

— frontend engineer, consumer app team

Should you use container queries instead?

Container queries are the future, but they’re not a drop-in replacement. They shift breakpoints from the viewport to the component’s parent, which is brilliant for reusable cards or sidebar widgets that live in wildly different contexts. The catch: browser support is still uneven, and polyfills are clunky. If you’re building a marketing site with a tight deadline, stick with viewport media queries. If you’re building a component library you’ll reuse across ten products, start with container queries for the small stuff — buttons, forms, code blocks — and keep viewport queries for the page-level grid. Mixing both is fine, as long as you don’t nest them in a way that turns debugging into archaeology.

One last thing — audit your breakpoint list quarterly. Old projects accumulate cruft: a 420px query that was added for a client’s test device, a 1366px rule that never matched anything. Delete them. A lean breakpoint set is easier to maintain, and the math you do upfront — measuring your content, not guessing at devices — will pay off every time a new phone ships. Your future self will thank you.

The Bottom Line: A No-Hype Recommendation

Start with Content, Not Devices

Stop counting pixels and start counting words. The breakpoint math that matters most is the line length at which your paragraphs turn into unreadable rivers. I have watched teams burn two weeks debating 768px versus 800px when the real problem was a 110-character headline that snapped awkwardly at every width between 600 and 900. Set your first breakpoints where text starts to hurt, not where a spreadsheet says a tablet ends. The device market shifts every year — your content doesn't.

That sounds obvious. Yet most breakpoint conversations begin with a designer's mockup at three fixed widths, and everyone pretends the world only exists at those sizes. The catch is that real users resize windows, rotate phones mid-scroll, and run browsers in split-screen. Content-first breakpoints absorb those edge cases because they react to layout pressure, not arbitrary device categories. Test your typography at 320px. Then stretch it until the line length exceeds 90 characters. That stretch point is your first breakpoint — not an iPad Pro's width.

Validate with Analytics, Adjust with Restraint

Analytics will tell you what people actually use. They won't tell you what to build. The distinction matters because raw numbers tempt you into chasing ghost devices — I once saw a team add a 375px breakpoint for a phone that represented 0.4% of sessions. Real user data helps you prioritize, but it should never overrule what your content needs structurally. Check your most common viewport widths, sure. Then check whether those users hit layout seams — via session recordings, not just scroll-depth charts.

Adjustments after launch should be surgical. Add a breakpoint, ship it, measure bounce rate on that range. Remove one, watch for layout artifacts on regression pages. The tricky part is knowing when to stop; every breakpoint you add multiplies the test matrix. That said, the greater risk is under-testing at odd widths like 667px or 896px, where Android keyboard overlays and browser chrome distort the viewport. I have debugged more layout explosions at 736px than at any round number.

The best breakpoint system is the one your team can explain from memory after six months.

— Frontend lead, mid-size SaaS product

Document the System, Not the Numbers

Write down why each breakpoint exists — the content constraint it solves, the edge case it guards against. A list of pixel values without rationale becomes archaeology within a quarter. New developers will "optimize" your breakpoints into chaos because nobody recorded that the 480px rule exists to keep the pricing table from collapsing. Keep the system flat. Nested breakpoints with overlapping media queries create bugs that only appear at 3am in production.

Worth flagging: simplicity outperforms cleverness every time. Two or three breakpoints, named by purpose rather than dimension — narrow, comfortable, wide — beat eight named after devices no one owns anymore. Document them in your style guide, reference them in component code, and resist the urge to add "one little extra" rule for a single component. That one rule is how your CSS file doubles in size and your render performance halves. Start there. Ship, measure, adjust.