Front-end development
Front-end projects rarely fail at the framework. They fail above it: where the pages are built, what the browser is asked to keep track of, and who is allowed to change a shared component. This page is about owning those three decisions.
01Capabilities
What sits inside the scope, whichever framework wins
This is the engineering offer rather than a technology index. Four things are ours whichever framework we end up on, and they are the four that decide whether the codebase is still pleasant in year three.
- Architecture
Where the pages come from, and where state lives
Rendering strategy first, then the boundary between server data and browser state, the module boundaries, the build, and a dependency policy somebody actually owns. These are cheap to decide at the start and expensive to change once three teams depend on them, which is why we write them down.
- Performance
Performance as a budget, not an audit
Measured on the routes users actually hit and the devices they actually own, then held to a number that is checked on every change. Performance work driven by intuition reliably optimises the parts that were already fast.
- Accessibility
Accessibility decided when a component is designed
Keyboard interaction, focus management and semantics get settled at design time, because retrofitting them into a shipped library costs several times as much. Where you have a formal conformance target, say so early: it changes component design, not just testing. Our UI and UX design team works to the same rule.
- System
A component library with real consumers
Turning a design language into a versioned library with a breaking-change policy and one source of truth for tokens. That is a product, not a folder of components, and it is what our design systems service covers. We build it under an ISO 27001:2022 certified information-security management system.
02Fit
Which framework we would put you on, including plain HTML
If you came to browse the tools rather than the offer, the front-end technologies index is the list of what we work in. What follows is how we choose between them, one situation at a time. Three of the six rows name a framework, and the other three name the lighter build that fits, down to a single page a template handles. For a sense of the shape of the work, our SaaS for Digital Researches study describes a research product built as a web workspace paired with a browser extension.
| Your situation | What we recommend |
|---|---|
| An application behind a login, heavy state in the browser, several teams on one component surface | Use ReactOur React page. This is the case it genuinely earns, and the hiring pool will still be deep in three years. |
| A large estate of applications, several teams over several years, one upgrade path wanted | Use AngularOur Angular page. Router, forms, HTTP layer and dependency injection decided once beats every team assembling its own. |
| A server-rendered application you are not going to replace, and one screen has to get better | Use VueOur Vue page. It mounts into a page you already have, which is the cheapest honest route to a better interface. |
| Mostly content, where search visibility and first paint decide the outcome | Rendering, not libraryStatic or server-rendered, with interactivity as the exception. If it has to be a component framework, then Next.js, because the real question is where the HTML comes from. |
| An internal screen a handful of people use, on an application you already render on the server | Keep it plainPlain HTML with a little JavaScript. A framework here buys a build step, a dependency tree and an upgrade you will owe every year, for a screen that will not change. |
| One marketing page that changes twice a year and has no product behind it | Use a templateA site builder or a template covers one page that changes twice a year, and the budget goes into whatever the page is meant to sell. |
Scope
What we own on front-end work is the recommendation and what follows from it. Where the pages are built, what the browser keeps track of, what a shared component promises, and whether your own team can still change the code afterwards. Accessibility and performance targets are written into the component contract rather than checked at the end. unicrew has been building interfaces since 2012, with 100+ senior in-house engineers across six countries. When building less than you planned serves the product better, that is the plan you get.
A fast front end starts with deciding what each page has to do before it can be useful. That part loads first, and everything else comes after it. We then set a performance budget and check it on every change.
Andrii BurdaSenior Engineering Manager, unicrew03Delivery
The order that keeps the later decisions reversible
The same four steps whether the codebase exists or not. Taken out of order, each one quietly constrains the next.
- Decide where the HTML comes fromServer-rendered, statically generated, client-rendered, or a deliberate mix per route. This single decision constrains performance, search visibility and hosting cost more than the framework choice does, and it is the one most often inherited from a starter template by accident.
- Draw the state boundary and write it downWhere server data ends and browser state begins, whether data fetching is colocated or centralised, and what the screen shows when a request fails. Skipping this is the most common reason a front end becomes unpredictable at about the eighteen-month mark.
- Put the budgets in the pipelinePerformance and accessibility thresholds checked on every change rather than audited at the end. A budget that only exists in a report is a budget that gets negotiated away in the week before a release. Every change runs through the same QA and test automation practice we use on our own builds.
- Ship one real surface end to endA single route in production with real data, real authentication and real error states before broad feature work begins. It surfaces the integration problems while they are still cheap, and it gives you something to judge us on early.
React
Angular
Vue.js
Next.js
TypeScript
Storybook05Questions
What buyers ask before handing over the front end
Answered the way we would answer them on a call. If yours is not here, it is a good first message.
Yes, and it is a reasonable way to start. Our developers own the architecture along with the code, because the rendering strategy and the state boundary get set early and are expensive to change later. An architect outside the delivery team reviews the design, the code goes through the same QA practice as our own projects, and handing over the whole outcome is web development.
The answer starts with what the application does and who will maintain it. Broadly: React for heavy browser state and several teams, Angular for a large estate that benefits from one upgrade path, Vue when you are improving an application you are not replacing. Sometimes the answer is none of them, because the product is mostly content.
Both, though they are separate services. UI and UX design covers the interface work and design systems covers the component library and tokens. When our designers are involved, the design system and the code library are one artifact rather than two that drift apart within a year. Where you already have designers, we work to their system and push back when a component contract is ambiguous.
With measurement on the routes users actually hit, on the devices they actually have, before anyone proposes a fix. Slowness usually resolves into a bundle carrying something it does not need, a render path running far more often than intended, an API chatty enough that no client work will save it, or images and fonts nobody has looked at. Those are different problems with different costs.
A scoping call with an engineer rather than a sales conversation. If a front end already exists we ask for repository access beforehand, because half an hour in the code answers more than an hour of description. You get back a written read: where the pages should be built, which framework we would choose and why, and what can stay as it is. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Need someone to own the front end?
Tell us what the interface has to do and what exists today. You get an engineer's read on where the pages should be built, which framework we would choose, and which parts a template or site builder already covers.