• Дизайн-системи · Next.js

A design system: so the tenth screen does not take as long as the first and looks like it belongs beside it

A product grows unevenly. The first screen was thought through for weeks; the tenth was assembled in an evening out of whatever was at hand. A year later it holds four different buttons, three shades of the same grey and two dissimilar forms that do the same thing. This is not a matter of taste: every new screen has to be invented from scratch, and every correction has to be hunted through all the places where something similar already exists. A design system reduces the interface to a set of parts that are already decided.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
Focus
interfaces of products and stores
after a free audit
Price
30
Guarantee

days after project sign-off

interfaces of products and stores
Focus
15
Timeline

to 45 working days

free review of the interface
Start
30
Warranty

days from the date the acceptance act is signed

within 2 hours
Reply
under a written contract
Terms
What's included

Complete list of work and what you get as a result

  • a set of repeating interface parts with rules for when to use which
  • single values for colours, spacing, sizes and fonts instead of numbers scattered through the code
  • every state of every part: resting, hover, pressed, error, waiting, empty
  • narrow-screen behaviour built into the part itself rather than bolted on separately
  • a live page with all the components, where they are seen working rather than drawn
  • naming rules, so that a year from now it is clear what a part is and what it is for
  • a procedure for adding a new component, so the system does not sprawl
  • moving a few real screens onto the system as proof that it works
When this service isn't right

What's not included — so there are no surprises at delivery

  • rebuilding the whole product onto the new system in one go
  • a design system for its own sake, with no near-term tasks to use it
  • a guarantee that users will like the new look more
  • supporting and developing the system after handover, unless agreed separately
  • promises of conversion growth from consistency
Who it's for

Situations where this service delivers results

Scenario 1 of 4

A product that has been growing for a few years

The inconsistency here comes not from carelessness but from history: each screen was built for its own task at its own time. Products like this gain the most.

We'll review your situation in a free audit
Free review of the interface

We look at how much inconsistency you actually have and whether a system is justified at your scale.

What we measure

  • How many different variants of the same thingWe count buttons, fields, cards, messages. The figure usually impresses the owner more than any argument.
  • How many values of one colourThe simplest measure of accumulated chaos. Five shades of grey instead of two is not aesthetics, it is five places to correct.
  • What will be built nextThe system pays for itself with future screens. If nothing is planned ahead, it becomes a handsome document with no use.
  • Who will use itIf the same person designs and assembles the interface, the benefit is smaller. If there are two or more, the benefit starts immediately.
  • What the product is built onComponents in React and Twig templates are different stories in effort. This is the main technical driver of scope.
  • Whether there is anything worth keepingSome of your decisions are already right and recognisable. We build the system out of them rather than against them.

What you get

  • the inconsistency counted: how many variants of the same thing
  • a list of the parts the system will consist of
  • an estimate of the work broken down by stage
  • an honest answer if the system will not pay for itself at your scale

Timeline: 3–5 working days

Why is it free

A design system pays for itself through the number of future screens. Until you look at how many there will be and how much inconsistency already exists, any estimate would be invention.

What's next

You get the list of parts and an estimate. Then you decide for yourself — the document stays with you.

Short form: your contact and site URL

  • Contract, act and 30-day warranty

    Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.

  • Sole proprietor & bank transfer

    The contractor is a registered sole proprietor. Payment by invoice with closing documents.

  • Rights & access — yours

    Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.

  • Client portal instead of email chains

    During the project you get access to a portal: contracts, invoices, acts and project status in one place.

  • European clients

    Among our work — projects for Norway, Bulgaria, Moldova and Spain.

  • Verifiable numbers

    Every case in the portfolio comes with a link to a live site and a technical measurement.

  • Audit first, then pricing

    There is no price list on the site intentionally: the scope of the same work differs multiples between clients.

  • We say "no" when unsure

    If the task isn't ours or the deadline is unrealistic — we tell you upfront.

What affects the price

Why two seemingly identical tasks are priced differently

  • Number of partsTwenty components and a hundred are different jobs. But the number is set not by wishes but by what your screens are actually made of.
  • How many states each hasA button is six states, not one. A form with validation is more than a dozen. It is the states, not the looks, that take the time.
  • Technical baseComponents in React assemble faster than templates in an old theme where markup and logic are intertwined. This is the main multiplier of scope.
  • State of the existing codeIf styles were written for years on top of one another, you first have to work out what affects what. Sometimes that is more work than the system itself.
  • Moving screensA system with no screen moved onto it is theory. We always move a few real ones, and how many directly affects the sum.
  • Who will maintain itIf your own people will develop the system, written rules for adding to it are needed. That adds work and removes dependence on us.
Cases

Tasks and results in numbers — all metrics measured by us

our own premium theme and module set for OpenCart 4, adapted to the Ukrainian market

Task
Make an OpenCart 4 store with a large catalogue open quickly and support out of the box what Ukraine always needs: Nova Poshta with waybills, Ukrainian payment systems, decent search and structured data — instead of assembling all of it each time from third-party modules of varying quality.
Solution
A theme for OpenCart 4.1+ on PHP 8.1+ with its own caching layer (APCu for the object cache, OPcache with JIT, nginx fastcgi_cache, scheduled warm-up of top categories) and a fix for the N+1 problem in categories, where native OpenCart issued 200+ COUNT queries. On top of that a Theme Engine with 10 ready design presets and 200+ options, FULLTEXT search with synonyms and autocomplete, back-in-stock notifications with recovery by email and SMS, reviews with AggregateRating markup, a set of JSON-LD schemas (Organization, WebSite, Product, Breadcrumb, Article, FAQ), and a Ukrainian layer: Nova Poshta with automatic waybills, registers and webhooks, Ukrposhta, LiqPay, monobank, WayForPay. Separately, an order-tracking page and a printable invoice protected by a token. Shipped as five archives: a full installer, a marketplace theme and three standalone modules.
Result
An internal test rig on a 14 thousand product catalogue: native OpenCart 4 returns a cold category in 8–17 seconds, with our theme it is 0.18 s from cache and 0.8 s without it — that is 30–95 times faster. The codebase holds 8,157 PHP files, 718 Twig templates and 726 JavaScript files; the feature list runs to 167 items in 16 sections. Version 1.1.0; the product is being prepared for launch and has not been released publicly yet.

Did not find your case?

Describe how it works on your side — we will tell you whether “A design system for a product” fits and what it means in your situation. No brief and no call: one question, one answer.

Process steps

Transparent stages with approval at every step

Total duration:15–45 days

  1. Auditing the inconsistency

    3–5 working days

    We collect every variant of button, field, card and message in the product. We count colours and spacings. This is where the real scale becomes visible.

  2. The foundation

    3–6 working days

    We agree the base values: colours, spacing, sizes, fonts, corner radii. This is the foundation — everything else rests on it.

  3. The parts

    7–20 working days

    We build components with all their states and narrow-screen behaviour. Not drawings but working parts you can drop straight in.

  4. The live page

    2–5 working days

    We assemble a page where every component is seen working. It doubles as the documentation: the rules are written beside the part rather than in a separate file.

  5. Moving real screens

    4–10 working days

    We move a few actual pages onto the system. This is where what is missing comes to light — and it is the most useful stage of the whole job.

  6. Rules and handover

    2–4 working days

    We write down how to add new things without breaking existing ones and hand the system to your people. Then the 30-day warranty from the date the acceptance act is signed applies.

Technologies & integrations

What we build on and what it connects to

Stack

  • Next.js
  • React
  • TypeScript
  • JavaScript
  • Tailwind CSS
  • Radix UI
  • shadcn/ui
  • Twig
  • PHP
  • HTML
  • CSS
  • Storybook
  • Figma
  • Git

Integrations

  • Figma
  • Storybook
  • Git
  • GitHub
A component system or mock-ups for every screen

How this option differs from the alternative

The tenth screenassembled from what exists
Correcting a shared elementin one place
Working with two people or morethe rules are the same for everyone
Upfront costnoticeable, pays back later
When mock-ups are betteroverkill for three pages and one person
What we need from you

We can't start without this — best to prepare in advance

  1. access to the existing product or to its screens
  2. who decides how it looks and who will assemble screens from here on
  3. whether any style rules already exist, even unwritten ones
  4. which screens are planned in the near term
  5. what the interface is built on technically
  6. who on your side accepts the work

If something is missing — let us know, we'll help you gather it or do it as a separate task.

FAQ

Most frequently asked questions — with concrete answers

Will this not become a handsome file nobody uses?

The risk is real, and that is exactly why we do not build the system as a separate document. The components live in the product's code, not in a mock-up, and we always move a few actual screens onto them. If the system did not survive meeting a real page, it is not ready — and it is better to learn that during the work.

Will the whole product have to be rebuilt?

No, and we are against it. Rebuilding everything in one go is a long period during which nothing works better while everything risks breaking. The right path is new screens on the system immediately, and old ones moved over when they have to be touched anyway.

How many components should there be?

As many as there are different parts in your screens, and not one more. The temptation to build «for the future» is strong, but a component nobody uses is cost without return. We derive the list from what you have, not from other people's examples.

We have an OpenCart store with an old theme. Is this possible here?

Yes, but it costs more than in a React product. In old themes markup and logic are often intertwined, and you first have to work out what affects what. We built our own OpenCart theme precisely as a system with a set of options, so we have a fair idea where it hurts.

Will this improve conversion?

We do not promise figures and consider such promises dishonest. A design system affects the speed of your work and the consistency of the interface, not sales directly. If conversion is the actual goal, something else needs discussing — and we will say so during the review.

Who will develop the system afterwards?

That is decided before the start. If your people will, we write down rules for adding new things so the system does not sprawl within six months. If nobody will, it is better to build a smaller system of a dozen genuinely needed parts than a large one that will go stale.

How long does it take?

15 to 45 working days. The foundation and the first components go quickly; the time goes on states, narrow-screen behaviour and moving real pages. If the product is large, it is wiser to start with a portion of the screens rather than cover everything at once.

Can a system be built before the product exists?

It can, but it is not worth it. A system built from imagination rather than real screens almost always turns out to be about something else. If the product does not exist yet, it is more honest to start with a first version and derive the system from it, once it is clear what repeats.

Let us count how much inconsistency you have

We will look at the interface and say which parts the system will consist of and whether it pays for itself at your scale. The review is free, we reply within 2 hours.

View cases
  • Reply within 2 hours
  • No commitment
  • We work under a contract

There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.