What is frontend development?
Frontend development is building everything a visitor sees, clicks and types. The work is deciding how a design behaves when conditions are not ideal: the request that fails, the name too long for its box, the list that arrives empty. Which framework it is written in comes later. A picture only has to be right once. A front end has to be right every time.
What does a frontend engineer own?
The design is approved, everybody is happy with it, and there is still a job to do. A competent design team has already predicted a great deal of what can go wrong, empty and error states included, and drawn the screen at the widths that matter. What no design file can settle is the set of decisions that only exist once the thing runs: how a layout holds at every width between the ones that were drawn, what real content does to a box that was filled with a plausible length, what the keyboard order turns out to be once the markup exists, and how the whole of it behaves on a device slower than anyone's in the room. None of that is a gap in the design. It is the half of the work a browser has to answer.
Those decisions land in a few places. Markup is the structure underneath a page, and it is what screen readers and search engines actually read, whatever the page looks like. State is what the screen remembers: what you typed, what you opened, what has already been sent. Routing is what the back button does. A component is a piece of interface defined once and used in every place it appears, so changing one affects all of them. Behind all of that sits the back end, which is where the data lives.
What frontend stack should I use?
It is the question people ask first, but several others should be settled beforehand as they shape the answer: who will be changing pages after launch, how long the thing has to last, and what it already runs on. The fact that decides it is usually one the brief did not mention. Finding it is a conversation, not a checklist.
- What the project needs
- A small site where motion is part of the point, that your designers will keep changing after launch
- What that points to
- Framer
- The trade
React's component model inside a design tool, so a designer can change a page without waiting for a developer, and motion that would take real time to build by hand.
Framer hosts it and nothing else can. When the CMS stops doing what you need, there is no code to reach into.
- What the project needs
- A content operation that needs more than a standard editor, and someone technical to maintain the site
- What that points to
- Webflow
- The trade
A CMS you can shape to your content rather than the other way round, and visual control with no house style imposed on you.
Webflow hosts it and nothing else can. Design changes outside the CMS need someone who thinks like a front-end developer.
- What the project needs
- A design system that has to stay in step with the code, and a codebase people will keep adding to for years
- What that points to
- React
- The trade
One component described the same way in Figma and in code, and a change that breaks something three files away caught by a check rather than by a visitor.
More to build than a hosted platform, and every change to a page needs a developer.
- What the project needs
- A build that should carry as little code as it can, on connections and devices that will not forgive it
- What that points to
- Svelte
- The trade
Less code reaching the browser, so it loads faster on a phone and a slow network.
Fewer developers work in it than in React, and less is written about it, so both a new hire and an AI assistant have less to go on.
- What the project needs
- A product that already exists, with a team already working in it
- What that points to
- Whatever it already runs on
- The trade
No rewrite, and your developers keep working in what they know.
We work to conventions we did not choose, so some things cost more than they would in a stack picked for the job.
| What the project needs | What that points to | The trade |
|---|---|---|
| A small site where motion is part of the point, that your designers will keep changing after launch | Framer | React's component model inside a design tool, so a designer can change a page without waiting for a developer, and motion that would take real time to build by hand. Framer hosts it and nothing else can. When the CMS stops doing what you need, there is no code to reach into. |
| A content operation that needs more than a standard editor, and someone technical to maintain the site | Webflow | A CMS you can shape to your content rather than the other way round, and visual control with no house style imposed on you. Webflow hosts it and nothing else can. Design changes outside the CMS need someone who thinks like a front-end developer. |
| A design system that has to stay in step with the code, and a codebase people will keep adding to for years | React | One component described the same way in Figma and in code, and a change that breaks something three files away caught by a check rather than by a visitor. More to build than a hosted platform, and every change to a page needs a developer. |
| A build that should carry as little code as it can, on connections and devices that will not forgive it | Svelte | Less code reaching the browser, so it loads faster on a phone and a slow network. Fewer developers work in it than in React, and less is written about it, so both a new hire and an AI assistant have less to go on. |
| A product that already exists, with a team already working in it | Whatever it already runs on | No rewrite, and your developers keep working in what they know. We work to conventions we did not choose, so some things cost more than they would in a stack picked for the job. |
How is a frontend build judged?
Accessibility is the first, and we aim for WCAG 2.2 Level AA. That is the level European procurement asks for, and in plain terms it covers contrast somebody can read, a page that can be operated from the keyboard alone, and markup a screen reader can announce in an order that makes sense.
Speed is the second. Core Web Vitals are Google's three measures of how quickly a page shows up, how quickly it answers, and how much it shifts while it loads. While performance benchmarking gives numbers to aim for, we adjust our goals according to the needs of the project. For example, this site has two jobs that pull against each other. It has to demonstrate best practice on accessibility, performance and SEO, and it has to be an expressive showcase of the work, which means hundreds of images and a great deal of animation and effects. To perform well as an interactive showcase, it sacrifices some performance on lower-end devices, and that is a choice rather than an oversight.
Working inside an existing codebase
There are two ways we work, and which one mostly depends on your existing team of developers. On projects we start, we take the front-end role. On projects that already have code and a dev team, we come in as UX & design and contribute to the front end, working alongside the developers who are already there.
On Vault22 we joined as designers and took on work that usually sits with engineering. We catalogued the components in Storybook, which runs each interface component on its own so it can be looked at and tested away from the product, and that let design carry more of what usually stops at the handover: the component library, part of the state management, and the token definitions. Storybook is an engineering tool and a design studio brought it in. The point was to move the boundary rather than to sit behind it.
Most studios that call themselves design-led mean they draw first. We mean design stays answerable once there is code, at the seams where a drawing and a built component come apart. What a client keeps at the end says the same thing: the repository, the component library, Storybook and the Figma design system, handed over as one thing rather than as design and then code.
Where we stand on Frontend Development
- 01A design is a picture of the product at rest. In the browser it is seen at every other moment, and no file can hold them all.
- 02There is no such thing as accessible. There is WCAG 2.2 Level AA, tested on a date, with the exceptions written down.
- 03Two browsers can run different code from the same source. Whether that matters depends on which one your visitors use, never on which one your developers do.
- 04We have no single house stack. A studio that builds everything in one thing will always find that your project needs that thing.
- 05When design and engineering are different suppliers, the gap between them becomes your problem. Here it is ours.
What’s included in Frontend Development?
- Component architecture
- How an interface is arranged in code: what each component knows, where state sits, and how they compose.
- Component catalogues
- A browsable catalogue of every component and each of its states, versioned with the code, in Storybook or its equivalent.
- Design system implementation
- Your design system built as the components a page is made from, and kept in step as both change.
- Accessibility engineering
- The code half of accessibility: semantics, focus order, keyboard routes and screen-reader announcements, built to a named version of WCAG.
- Performance engineering
- Measuring what a page spends its time on, then reducing it: images, fonts, scripts and render cost.
- Testing and browser support
- Automated checks on every change, and a stated set of browsers, engines and screen sizes the build answers for.
What is the difference between frontend and backend development?
Front-end development is everything a visitor touches: what is on the screen, what happens when they use it, and how it behaves on the device in their hand. Back-end development is what holds the data and the rules about it, so accounts, payments, permissions, and anything that has to still be true tomorrow. The two meet at an agreed set of requests, one side asking and the other answering.Which frameworks do you build in?
We do not rely on a single stack. Many of our projects are built in React, some in Svelte, and we spec each one on what the project calls for. React is the more common answer because its component model lines up with the way components work in Figma, which makes a design system cheaper to keep in step as both sides change. This site runs on Next.js and React, which is an example of what we build in rather than a recommendation of what you should.Can you work with our designers, or do you need finished files?
Your designers, gladly, and that is a different thing from being handed the files and left to build them. Hominum is a design-led studio rather than a development shop, so a front-end engagement with us always carries design input: we say when a layout will not survive a narrow screen, when a state has not been drawn, and when what is being asked for costs more than it returns. That input sits alongside your designers rather than over them, and wanting it is why we would decline a brief that leaves design out altogether.Can you work on the site we have, or does it need rebuilding?
Usually it can be worked on, and we will say so even though the rebuild is the bigger job for us. Most sites that feel wrong are not wrong underneath: the navigation is in the way, a couple of templates are carrying work they were never designed for, or the pages got slower with everything added after launch. Those are changes. A rebuild earns its cost when what is underneath cannot carry what you want next, when nobody left can read the code, or when the accessibility problems are in the foundations rather than on the surface. Looking at what you have costs a fraction of replacing it, so that is the order we do it in.How do you keep the designs and the code from drifting apart?
By making the two describe the same thing, so a change has one place to land on each side. A component in Figma carries properties, the same component in React carries props, and where those lists agree a designer and an engineer are looking at one part rather than at two versions of it. Holding that agreement is what a design system is for, and it is why we build in both places at once rather than drawing first and translating afterwards.How much does frontend development cost, and how long does it take?
Complexity moves the number, so the useful answer is by example. A static one-page marketing site can be designed and built in about two weeks, with roughly half of that being development. Add more page types and some forms and you are approaching four weeks, again with about half of it front-end. Add a content management system, user accounts or a shopping cart and we scope it before we quote, because anything else would be a guess made with your money.