Responsive web design that starts on the phone, not the desktop

What responsive web design actually means

Responsive web design means one build that works at any screen width, rather than a desktop layout with a phone version bolted on. Done properly it is not a stage at the end of a project — it is the order the design is done in, starting at the narrowest screen and widening from there.

The reason the order matters is that constraint forces priority. Designing at 1440px and shrinking produces a phone layout full of things nobody chose to keep; designing at 360px and expanding produces a phone layout where every element earned its place. The second one converts better, and the difference shows up in enquiries rather than in a testing tool.

Who this is for

• Businesses whose analytics show most sessions on phones and most conversions on desktop — a gap that is almost always a layout problem
• Sites that pass a mobile-friendly test but are visibly awkward to use one-handed
• Companies with an older fixed-width site built before phones were the majority
• Anyone whose site fails Core Web Vitals specifically on mobile
• Businesses whose customers search outdoors, in a hurry, on a mid-range Android

Who it is not for

Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.

• Sites where the markup is so tangled that retrofitting costs more than rebuilding. I will tell you which one you are
• Applications with genuinely desktop-only workflows, where a separate interface is the honest answer
• Businesses whose real problem is content or offer rather than layout
• Anyone expecting a separate m-dot mobile site, which has been the wrong answer for over a decade

The problems it solves

Mobile traffic that does not convert

The layout is designed at phone width first, so the action is reachable rather than buried under a hero image.

Content jumping as the page loads

Every image carries width and height, embeds get reserved space, and fonts use metric-matched fallbacks.

Buttons and links too close to tap

Tap targets at 24px minimum with real spacing, which is a WCAG 2.2 requirement rather than a preference.

Forms that fight the phone keyboard

Correct input types and autocomplete attributes, so the right keyboard appears and autofill works.

Tables and code blocks breaking the layout

Wide content scrolls inside its own container instead of forcing the whole page sideways.

Looks right in a resized browser, wrong on a handset

Tested on real hardware over mobile data, where the bugs that matter actually reproduce.

What you get

• Mobile-first layouts designed at 360px and widened, rather than desktop layouts compressed
• Fluid type and spacing scales so nothing is pinned to a handful of arbitrary breakpoints
• Tap targets at 24px minimum with real spacing between them, per WCAG 2.2
• Images served as AVIF and WebP with correct srcset and explicit width and height attributes
• Forms with correct input types and autocomplete, so phone keyboards behave
• Tables and wide content that scroll inside their own container instead of breaking the page
• Tested on a real handset over mobile data, not only in a resized desktop browser
• Core Web Vitals verified in the field after launch, including Cumulative Layout Shift

What is included in the starting price

Everything below is in the $80 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.

• Mobile-first layouts designed at 360px and widened, not desktop layouts compressed
• Fluid type and spacing scales, so the design works between breakpoints rather than only at them
• Tap targets meeting WCAG 2.2 minimum size and spacing
• Images as AVIF and WebP with correct srcset, sizes, and explicit dimensions
• Forms with correct input types, autocomplete and visible labels
• Wide content contained in its own scroll region
• Keyboard and screen reader pass, because responsive and accessible fail together
• Testing on a real handset over mobile data, plus throttled lab testing
• Core Web Vitals verified in the field after launch, Cumulative Layout Shift in particular

What costs extra, and why

A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.

Retrofitting a legacy stylesheet

Sometimes cheaper than rebuilding, sometimes not. The audit decides it and you see the reasoning.

Design work from scratch

Where there is no existing design to make responsive, that is a design project rather than a conversion.

Component library or design system

Worth it for a large site with several people building pages. Overkill for eight pages.

Dark mode

A real amount of work to do properly across every component, and worth deciding on deliberately.

Legacy browser support

Anything below current-generation browsers is scoped separately, because it costs real time.

How the work runs

1. Design at 360px. The narrowest realistic screen first. Anything that does not fit there is a priority decision you make deliberately rather than a casualty of the fold.
2. Widen. Layouts expand into the space available using fluid scales, so a 390px phone and a 412px phone both look intentional.
3. Build. Semantic HTML, Tailwind for layout, and no JavaScript required to render content. Staging URL from day one.
4. Test on hardware. A real phone, on mobile data, with one thumb. The bugs that matter do not reproduce in a desktop emulator.
5. Measure. Field Core Web Vitals after launch. Layout shift in particular only shows up on real devices with real network conditions.

Day by day

3 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.

The technology

Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.

Layout

CSS grid and flexbox with fluid clamp-based type and spacing scales

Framework

Tailwind CSS, compiled and purged so the stylesheet contains only what is used

Images

AVIF and WebP with a PNG or JPEG fallback, correct srcset and sizes, dimensions always present

Fonts

Subset, preloaded, with metric-matched fallbacks so swapping does not shift the layout

Testing

Real handsets over mobile data, plus throttled lab runs and field Core Web Vitals afterwards

What it integrates with

• Chrome UX Report field data, where your traffic volume supports it
• Lighthouse in CI, as a regression guard rather than a score to chase
• Google Search Console mobile usability reporting
• Analytics segmented by device, which is where the conversion gap becomes visible
• Any existing component library or brand tokens you already maintain

What I need from you

Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.

• Access to the current site and its stylesheet, or the design files if it is a new build
• Analytics access, so the device split and the real conversion gap can be seen rather than assumed
• A decision on which browsers and devices genuinely matter to your customers
• Brand assets: fonts, colours and logo in usable formats
• One person who can approve layout decisions, especially about what is cut on small screens

Content and photography

Responsive design forces content decisions and most projects avoid them until the last moment. A phone screen holds roughly one idea above the fold. Deciding which idea that is, per page, is content work rather than design work, and doing it properly is most of what separates a mobile layout that converts from one that merely fits.

Long paragraphs are the other common casualty. Text that reads fine at 900px wide becomes a wall at 360px. Shorter paragraphs, real subheadings and lists are not a stylistic preference on mobile — they are what makes the page readable one-handed on a bus.

Performance standards

Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.

Accessibility standards

This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.

Security practices

The SEO included in every build

Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.

Ownership and handover

You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.

A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.

Aftercare and what happens after launch

Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.

You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.

Ongoing maintenance

Optional, monthly, cancellable. Nothing here is required to keep what you paid for.

Payment terms

How this compares to the alternatives

Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.

What could go wrong, and how it is handled

The existing markup will not retrofit cleanly

Found during the audit and reported before you commit, not discovered halfway through.

Stakeholders want desktop parity on phones

A design conversation, held on day one. Everything cannot be above the fold at 360px.

Brand fonts are heavy

Weighed against the speed cost explicitly, with the numbers, so the trade is a decision rather than an accident.

Third-party embeds break the layout

Audited during the build. Some widgets cannot be made responsive and the honest answer is to replace them.