Frontend developers for fast, accessible interfaces

Our frontend developers build user interfaces in React, Vue and TypeScript, and every one of them has more than ten years of experience. We stick to established technology, so other developers can keep working on the code five years from now.

The frontend is where your customers deal with you. It's where they order, sign in and decide whether they trust you. Behind the colours and animations there's performance, accessibility and code that has to survive years of changes.

What does a frontend developer do?

A frontend developer builds the part of a system that users see and click on, such as forms, menus, tables and checkout steps. The job is to turn the design into code that loads quickly on a slow phone, works with a keyboard and a screen reader, and behaves the same in every browser.

This is where experience shows. An experienced frontend developer can tell when a form will cause trouble on mobile, when a page fetches more data than it needs, and when a component can't be used without a mouse. Those problems get fixed before users run into them.

Frontend, backend or full-stack?

The frontend is what runs in the browser. The backend is what runs on the server: business logic, databases, APIs and integrations. A full-stack developer works in both.

If you need help with the interface for a system you already have, a frontend developer is what you need. If you're building something new from the database up, full-stack development is often the better choice, because one team then owns the whole flow. We do both, and we also have dedicated backend developers.

Why accessibility pays off

Accessibility is a legal requirement, and it also makes business sense. Roughly 15 to 20 percent of people in Norway have a permanent disability. On top of that, there's everyone using your service one-handed on the bus or reading the screen in bright sunlight.

When we build with good contrast, screen reader support and clear keyboard navigation, the interface works better for everyone:

• Better SEO: Google reads your site much like a screen reader does, so code that works for screen readers also helps your search rankings.
• A bigger market: you don't shut out customers who want to buy from you.
• Staying within the law: accessibility requirements already apply to Norwegian websites, and the European Accessibility Act (EAA) makes them stricter.

We build to WCAG 2.2 AA from the first component. If you need a full audit or an accessibility statement, we have dedicated accessibility services.

Performance and Core Web Vitals

Google measures user experience with three numbers called the Core Web Vitals. They are how quickly the main content appears (LCP), how quickly the page responds when someone clicks (INP), and how much the content jumps around while loading (CLS). Slow pages rank lower and make ads more expensive, and more visitors give up before they buy.

Performance mostly comes down to how much JavaScript the browser has to download and run. We split the code so each page only fetches what it needs, and load images and heavy components only when they're needed. Where it makes pages appear sooner, we render them on the server. Tailwind CSS strips out unused CSS automatically, so the files stay small.

The site you're reading scores 100 in all four Lighthouse categories. Read how we went from 90 to 100.

Choosing frontend tools that last

Frontend tooling changes quickly. Yesterday it was Redux, today it's Zustand or Signals. We spend time working out what will last and what will fade, and we pick tools you can live with for years.

• TypeScript: the foundation. Types describe what the data looks like, so the application doesn't crash because it got text where it expected a number.
• React or Vue: the most widely used frameworks in the world. It's easy to find people who can maintain the code later, and you aren't locked into a niche tool.
• Tailwind CSS: styling that's easy to maintain, with small files in production.

For state management we use the simplest thing that works. React Query handles data from the server, and we only bring in Zustand or Redux when the interface has a lot of shared state. If you already have a stack, we're happy to keep working in it.

Next.js, Inertia or a plain SPA?

A classic single-page application (SPA) with its own API is often more complicated than it needs to be. You have to build and maintain an API, handle tokens and write much of the same logic twice.

That's why we often use Inertia.js for internal business systems, customer portals and B2B applications. We build the interface in React or Vue, but the pages get their data directly from the backend, usually Laravel. In our experience we build features 30 to 40 percent faster this way, with fewer sources of bugs and lower maintenance costs.

When a site depends on search traffic and has a lot of public content, we use Next.js with server rendering or pre-built pages. When a mobile app or other systems need the same data, we build the frontend against a separate API.

From Figma to code

A common problem in IT projects is the gap between what the designer draws and what the developer builds. Our frontend developers work directly in Figma. We learn the design system, the variables and the interactions behind each screen, and we use design tokens for colours, spacing and font sizes directly in the code.

When the designer changes the brand colour, the change goes through the whole interface at once. Your brand looks the same everywhere, and less time goes into nudging pixels. If you don't have a design system yet, we can build one with you.

When senior frontend developers are worth it

Senior frontend developers pay for themselves when the interface matters to the business. Examples are a customer portal your customers use every day, or a business system your staff work in all day. They're also worth it when accessibility or performance requirements are strict, or when your frontend has become too expensive to change.

If you need a simple website with lots of editorial content, a custom React interface is often more than you need. WordPress is usually a better fit then, and we're happy to help with that too.

What does a frontend developer cost?

Our hourly rate starts at NOK 1,500. You can hire us by the hour for ongoing development, or we can take on a defined project at a fixed price when the scope is clear.

The cost of a frontend project depends mostly on three things: how many different screens and components there are, whether a finished design and design system already exist, and how much has to connect to the backend and other systems. After a short discovery phase you get an estimate, so you know what you're getting before we start.

Taking over and modernising a frontend

Many companies have a frontend that's a few years old, where every change takes longer than it should. We start with a review. We measure performance and accessibility, read the code and check the dependencies, and then give you a prioritised list of what needs doing. The list is yours to use, whoever ends up doing the work.

We rarely rewrite everything. Usually we replace one part of the interface at a time, with tests around the parts that matter most. That way users get the improvements as we go, instead of waiting a year for one big launch.

How we keep the quality up

Code should be as easy to change in five years as it is today, so we stick to a few habits:

• Tests: Jest and React Testing Library for components, and Playwright for end-to-end tests of the most important flows.
• Consistent code style: ESLint and Prettier, so the code looks the same whoever wrote it.
• Mobile first: everything is built for small screens first and tested across devices and browsers.
• Code review: another senior developer reads the code before it goes to production.

Everyone on our team has more than ten years of experience. You won't get juniors on the project, and you won't lose time to handovers along the way.

Our stack

These are the tools we use in most frontend projects, layer by layer.