Key Takeaways
- A mobile-first developer should show how a page works on a small screen before relying on a polished desktop mock-up.
- Ask for evidence from live projects: real mobile journeys, performance data, accessibility checks and examples of content that stays complete on every device.
- Mobile-first is not the same as making a desktop layout narrower. It affects content order, navigation, forms, images, interaction and technical delivery.
- Judge the developer's process as carefully as their portfolio. Good discovery, testing and ownership usually matter more than a fashionable framework.
- Put mobile acceptance criteria in the proposal so everyone agrees what will be tested before launch.
Choosing a web developer with mobile-first design expertise is difficult because almost every supplier now says their websites are responsive. A portfolio can look tidy on a phone and still hide slow pages, awkward forms, tiny controls or important content that disappears on smaller screens.
The useful question is not, “Can you build a responsive website?” It is, “How do you decide what a customer needs first on a phone, and how do you prove that it works?” A credible developer should answer with a process, examples and test evidence rather than a string of technical terms.
This guide is written for UK business owners comparing freelancers, agencies or an internal hire. It gives you a practical way to check mobile-first ability before you commit to a project.
What Mobile-First Design Actually Means
Mobile-first design begins with the smallest useful experience. The team decides what a visitor must understand and do on a phone, then adds space and enhancements as the screen becomes larger. It is a design and content decision before it is a CSS technique.
A mobile-first developer thinks about:
- which message appears first;
- whether navigation works with one hand and a keyboard;
- how forms behave when the on-screen keyboard opens;
- whether images are appropriately sized rather than merely squeezed;
- how calls, maps, payments and account journeys work on a phone;
- what happens on slow or unreliable connections;
- whether the same meaningful content and metadata remain available to search engines.
Google's current mobile-first indexing guidance says it uses the mobile version of a site's content for indexing and ranking. It recommends responsive web design as the easiest pattern to implement and maintain, and advises keeping primary content, headings, metadata, structured data and image context equivalent across mobile and desktop.
That does not mean every layout must look identical. A long comparison can become an accordion on a phone, for example. The information should still be present, understandable and accessible.
Start with the Customer Journey, Not the Device List
Before speaking to developers, write down the two or three jobs the website must support. A local service company may need visitors to understand its coverage, trust its work and request a quote. A trade supplier may need approved customers to find stock, see account pricing and place a repeat order.
Then describe the mobile circumstances. Is someone searching from a van between appointments? Are they comparing a complicated service on a train? Do they need to upload a photo, use a postcode or complete a payment? These details shape the experience more usefully than asking for support for an arbitrary list of phones.
If you need help turning those journeys into a sensible brief, our responsive and mobile-first design service covers the planning as well as the interface. The broader guide to UX/UI design for service businesses also explains why the route to an enquiry matters more than decorative polish.
Ask to See Mobile Work in Context
Do not review a portfolio only through supplied screenshots. Open two or three live sites on your own phone and complete a real task. Rotate the device, increase the text size and try the main form. If the project is an online shop, add a product with options and move through the checkout without placing an order.
Ask the developer what they personally did on each project. A freelancer may show a site designed by another team. An agency may show a large project while the people assigned to your work had little involvement. Neither is automatically a problem, but the answer should be clear.
Useful follow-up questions include:
- What changed after mobile usability testing?
- Which mobile problem was hardest to solve?
- How did you decide the content order?
- What performance issue did you find after launch?
- How did the editor keep mobile content complete when updating the site?
Good answers are specific. “We moved the quote action nearer the service proof because users were losing it after opening the menu” is more valuable than “We use the latest responsive technology.”
Check How the Developer Works Before Design Starts
A capable process normally includes discovery, content structure, low-fidelity layouts, reusable components, development, testing and a controlled launch. The exact labels can differ. What matters is that important decisions happen before somebody spends days polishing the wrong screen.
Ask whether you will see mobile wireframes or prototypes early. Check who writes the content, who supplies images and who approves the order of information. Confirm how the developer handles a disagreement between a desktop visual idea and a usable phone journey.
For a completely new build, custom website design should connect those decisions to the wider brand and business goal. If the existing site already has traffic and useful pages, a website audit and consultation can show whether focused improvements are safer than a rebuild.
Look for Evidence of Performance Knowledge
Mobile performance is affected by much more than the chosen framework. Large hero images, web fonts, video, consent tools, chat widgets, advertising tags and poorly designed code can make any platform slow.
Ask the developer to explain how they control image dimensions and formats, font loading, third-party scripts, caching and JavaScript. They should be able to show a performance report and explain the cause of a weak metric. A score without diagnosis is not much use.
Google's Core Web Vitals guidance distinguishes loading performance, responsiveness and visual stability. Field data from real visits is more representative than one lab run, but lab tools are valuable during development because they make repeatable problems easier to investigate.
Do not demand a guaranteed score of 100 on every tool. Demand a sensible performance budget, representative test pages and an agreement about the third-party features that may affect the result. Our article on why INP is the Core Web Vital many websites fail explains why a page can appear loaded while still responding poorly.
If performance is already a known weakness, compare the developer's proposal with focused website speed optimisation. Removing a useful feature just to change a score is not automatically the right commercial decision.
Test Accessibility, Not Just Screen Width
Mobile-first work should include people who zoom, use a keyboard, rely on screen readers or have limited dexterity. A menu that fits a phone is not usable if its controls have vague labels, focus disappears or the close button cannot be reached.
The W3C's summary of what changed in WCAG 2.2 includes criteria covering target size, dragging movements, visible focus and accessible authentication. Ask which standard the developer works towards and which checks are manual. Automated scanners help, but they cannot complete a quote journey or judge whether an error message makes sense.
Try these simple portfolio checks:
- increase browser text size and check that content still reflows;
- move through links and controls with a keyboard;
- check that focus is visible and not hidden by a sticky bar;
- submit a form with a required field empty;
- use a screen reader to hear the menu and form labels;
- tap controls without accidentally triggering the one beside them.
The guide to website accessibility audits in the UK explains what a deeper review should contain. For implementation, compare the developer's approach with our accessibility and WCAG compliance service.
Ask What Happens in the CMS
A carefully designed mobile page can deteriorate when an editor uploads an enormous image, writes a vague heading or adds a table that cannot reflow. Ask to see the content-management experience and the controls that protect the design.
Useful safeguards include fixed image aspect ratios, meaningful field labels, preview options, reusable content blocks and validation for required alternative text. Editors should not need to create separate mobile copy that gradually drifts away from the desktop version.
Also ask who owns updates after launch. A reliable handover should cover image preparation, headings, links, forms and any component limitations. The developer should state what is maintained, how backups work and how faults are reported.
Put Mobile Requirements in the Proposal
Verbal promises are easy to interpret differently. The written scope should name the important mobile journeys, supported browser range, accessibility target, representative devices or viewport sizes, performance method and acceptance process.
It should also state:
- who supplies and approves content;
- which integrations and third-party scripts are included;
- how many rounds of testing and fixes are allowed;
- whether analytics and conversion events are tested;
- what training and post-launch support are provided;
- what counts as a change to the agreed scope.
Ask who will test the finished site. Ideally, the person who built a feature is not the only person checking it. Even a small project benefits from a written checklist and a named business owner completing the priority journeys.
A Simple Shortlisting Scorecard
Score each supplier from zero to three on the following areas:
| Area | What good evidence looks like |
|---|---|
| Mobile process | Phone layouts and content priorities are considered from the start |
| Live work | You can complete relevant journeys on real published sites |
| Performance | The developer explains metrics, causes and trade-offs |
| Accessibility | Manual checks support an identified WCAG target |
| Content | Mobile and desktop information stays equivalent and editable |
| Testing | Devices, browsers, errors and business journeys are documented |
| Ownership | Hosting, accounts, code, content and support are clearly assigned |
| Communication | Answers are specific, understandable and honest about limits |
Do not automatically choose the highest visual score. A developer who spots a weak requirement, explains a risk and proposes a smaller first release may be a safer partner than one who agrees to everything.
Frequently Asked Questions
What is a mobile-first web developer?
A mobile-first web developer plans the content, interface and technical delivery around small-screen journeys first, then enhances the experience for larger screens. They should also understand performance, accessibility, testing and mobile-first indexing.
Is responsive design the same as mobile-first design?
No. Responsive design means a layout adapts to available space. Mobile-first describes the order and priorities used to design it. A responsive site can still be desktop-led and awkward on a phone.
Should I ask a developer to guarantee a Lighthouse score?
Ask for an agreed testing method and performance budget, not an unconditional score. Results vary with pages, devices, networks and third-party tools, and real-user field data is different from a single lab test.
How can I test a developer's mobile portfolio?
Open live projects on your phone and complete relevant tasks. Test navigation, forms, validation, text enlargement, keyboard focus and slow-loading pages, then ask what the developer changed after testing.
Does mobile-first design help SEO?
It supports a complete, usable mobile experience, which matters because Google indexes the mobile version of content. It does not replace useful content, technical SEO, authority or links, and it cannot guarantee rankings.
Choose Evidence Over a Label
The right developer does not need to turn the meeting into a technical lecture. They should understand your customers, show what they have built, explain how they test it and put the important promises in writing.
If you want an honest review of a proposal or an existing mobile journey, contact MattDarm. We can start with an audit, focused UX/UI design or a complete mobile-first build, depending on what the evidence says you actually need.
