Designer and developer collaborating over a laptop and paper prototype.
Services

Bring the idea to life.
Make it useful.

Connect brand, content and technology in a website or web application built around the people who use it.

Design & development

For a defined idea ready to build, an existing website ready for a redesign, or a workflow that needs a custom application.

01 /
A laptop displaying a ceramic lamp product page with product details and an Add to bag button.

Shape the experience

Plan the structure, content and key journeys. Review how people will find information and complete their most important tasks.

02 /
A laptop and keyboard arranged for software development.

Build the essentials

Bring the design and functionality together in manageable pieces. Use feedback to resolve unclear interactions before launch.

03 /
Connected web application icons for task management, messaging, analytics, client access and file sharing.

Prepare for release

Review responsive layouts, accessibility, performance and search continuity. Clarify content ownership and the next steps after launch.

A clear next step.

A release with an agreed scope, a launch checklist and a plan for ongoing improvements. Integrations and functionality follow the needs of the brief.

Explore growth & optimisation

How the work runs

Four stages.
One visible line.

Design and development is one continuous build, not a handover between two teams. Here is the order it happens in and what you receive at each point.

  1. 01

    UX architecture

    Agree what the site has to do before anything is drawn. Structure, journeys and the content each page owes its reader.

    • Sitemap and user journeys
    • Wireframes for key screens
    • Content model and ownership
  2. 02

    UI design

    Give the structure a voice. Type, colour, spacing and components, defined once and reused across every breakpoint.

    • Design system and tokens
    • Key screens, desktop to phone
    • Interaction and motion rules
  3. 03

    Frontend and backend

    Build it in reviewable pieces. Markup and styling first, then the data, the integrations and the editing experience.

    • Component build
    • CMS, data and integrations
    • Staging review at each slice
  4. 04

    QA and launch

    Check it the way the people who use it will. Devices, assistive technology, speed, and the search continuity of every old URL.

    • Cross-device and assistive QA
    • Performance and accessibility pass
    • Redirects, analytics and go-live

One layout, every screen

It does not
get narrower.
It gets rearranged.

A responsive build is not a desktop page squeezed down. Each breakpoint decides what leads, what folds away and what becomes a single column. Pick a width — or pull the frame's edge on a wider screen — and watch the same page re-lay itself.

You are reading this on the narrowest of them, which is exactly where most of these decisions get tested first.

Desktop
Full navigation in the header, the headline and its image side by side, services laid out in three columns so the whole offer reads at a glance.
Tablet
Secondary links step back, cards regroup into two columns and images shorten so the first call to action stays on the first screen.
Phone
The menu folds into a single button, the image moves above the headline, every block becomes one column and tap targets grow to thumb size.

Each of these is designed and checked on real devices before launch — not left to whatever the browser does when the screen runs out.

Preview width

Light and dark, side by side

The same layout.
A different light.

A light and a dark theme should be one design, not two. Drag the divider: every block keeps its place, size and order — only the palette changes, and the hierarchy reads the same on either side.

Light Dark
One layout in two palettes: the navigation, headline, call to action and cards sit in exactly the same place on both sides, so switching themes never moves what a visitor is looking for.

What ships, measured

Development sells
a result, not code.

A build is finished when it passes the same audits a search engine and an assistive technology run on it. Every Vermilio release has to clear them before it goes live — including this page, which you are welcome to audit yourself.

  • Pass Performance
  • Pass Accessibility
  • Pass Best practices
  • Pass SEO

Google Lighthouse, mobile and desktop profiles, run on every release. Core Web Vitals are part of the launch checklist, not a later fix. We publish no score here — run the audit on this page yourself and read your own.

A curve rising steadily from left to right, illustrating organic visibility compounding after a technically clean launch.
After launch. A clean technical base is what lets search visibility compound instead of resetting with every release. The shape is the pattern we build for — not a single client's numbers.

What we build with

Chosen for the job,
not for the habit.

A brochure site and a logged-in application do not deserve the same stack. These are the tools we reach for, and part of discovery is agreeing which of them your project actually needs — including the ones your team already runs.

  • Figma
  • Astro
  • React
  • TypeScript
  • Next.js
  • Tailwind CSS
  • Node.js
  • WordPress
  • Shopify
  • Webflow
  • PostgreSQL
  • Playwright
  • Cloudflare
  • Lighthouse
Laptop, tablet and phone arranged together on a dark desk.

Where are you
starting?

Share your goals, what you have today and the decisions you need help making. We can discuss the right starting point and scope.

Tell us about your project