Mobile-First, Fluid by Default
We write base styles for small screens and layer enhancements upward with media queries — the approach the industry settled on for good reasons: it produces simpler CSS, faster mobile rendering, and far fewer override bugs. Between breakpoints, layouts scale fluidly using relative units, flexible grids and clamp-based typography, so the design never sits awkwardly at the in-between widths real users actually have. The foundational thinking behind this approach was laid out in Ethan Marcotte's landmark Responsive Web Design article in A List Apart, and it has only grown more relevant since.
How Many Designs Do You Need to Provide?
Ideally two or three: desktop plus mobile, and tablet if the design departs meaningfully from a simple interpolation. But we regularly work from a desktop-only PSD — in that case we propose the responsive behavior ourselves (stacking order, navigation pattern, type scale) and confirm it with you in an early review before building it out. You stay in control of the design decisions; we just save you the work of drawing every state.
What We Test On
- Real devices — current and previous-generation iPhones and Android phones, plus a tablet in both orientations. Emulators lie about touch targets and scroll behavior; hardware does not.
- Awkward widths — we drag the viewport through every pixel from 320 to 2560 and fix anything that jumps, overlaps or orphans.
- Content stress — long headlines, missing images, translated strings half again as long as the English, and user font-size overrides.
- Input modes — touch, mouse and keyboard, because responsive means responding to more than width.
Navigation Is the Hard Part
Most responsive defects cluster in the navigation, because it is the one component that must transform completely between widths. We build navigation patterns that stay usable at every size — visible menus where space allows, accessible disclosure menus where it does not, and a tested keyboard and screen-reader experience in both states. The collapse point comes from your menu's actual content, not from a device list: a five-item menu and a nine-item menu should not break at the same width, and in our builds they do not.
Performance Is Part of Responsive
A responsive site that ships desktop-sized images to a phone has failed at its one job. Our builds use responsive image markup (srcset and sizes, with art-directed picture elements where the design crops differently per breakpoint) following the patterns documented on MDN, lazy-load below-the-fold media, and keep CSS lean enough that mid-range phones render the first screen without jank. We sanity-check against the Core Web Vitals guidance published on web.dev before delivery.
Retrofitting an Existing Site
Not every responsive project starts from a fresh PSD. If you have an older fixed-width site that needs to become responsive, we can often rework the existing front-end rather than rebuilding from zero — we audit the markup first and tell you honestly which approach is cheaper. Sometimes the answer is a clean rebuild via our standard PSD to HTML service; sometimes a focused retrofit saves you most of the budget. We quote both ways when it is a close call.
Start with a Conversation
Responsive scope varies more than any other service we offer, so the quickest path to an accurate quote is to show us what you have. Send the design files or a live URL and tell us your target devices, and we will come back with a fixed price, a breakpoint plan, and a delivery date.