Development
UX/UI design
A Figma prototype, the states of every screen and a design system — before development starts. If you already have a mock-up, the work starts straight from it.
- Reply to your brief
- within 24 hours
- First call
- 30 minutes, no commitment
- First working version
- in 2 weeks
Process
What happens, and when
The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.
Days 1–3
The screen list
The first days go into a conversation and a list, not into layouts: how many screens there are, which of them do the job and which merely serve it. This is also where the person who signs layouts off is named, along with how long that takes them — without it, design circles for longer than it draws.
You get — A screen list and a named approver
Days 4–10
Screens in grey
Screens are assembled in grey first: structure, real copy, what sits where, no colour and no typefaces. That way the argument is about what a person does on the screen rather than the shade of a button. A change costs an hour at this stage and a day once the visual layer is on, which is the only reason we do not start with the pretty version.
You get — Screen structure with the real copy in place
While the build runs
Support during the build
Handing over a file is not where design ends. While the screens are being written, questions arrive daily: what to do with a very long name, what an empty list shows, how a button looks while it is submitting. We answer as they come and check each built screen against the layout right away, rather than a month later when redoing it is expensive.
You get — Answers as they come and screens checked
Before sign-off
The real-data pass
We walk the interface on real data rather than tidy samples: long titles, empty states, a failed request, a narrow screen, a thumb instead of a cursor. What this pass turns up is almost never about beauty — text that does not fit, a control out of thumb reach, an error that does not say what to do next.
You get — Findings from long titles and empty states
After launch
Keeping the design system
A design system lives only while someone keeps it. A new screen is assembled from existing components, and a component itself changes in one place — otherwise, six months on, the product has three kinds of button and nobody remembers which one is right. From there we keep it, or your designer does, with the rules handed over alongside it.
You get — Components and the rules for using them
What the work covers
Understanding the job
who the user is, what they come to do, what they use today
Structure
a map of screens, the flows between them, and the states — empty, loading, error, at the limit
A prototype in Figma
clickable, showing behaviour rather than appearance alone
The visual layer
type scale, palette, grid, hover and focus states
A design system
components with variants and rules, so a new screen is assembled rather than drawn again
Handover
layouts with sizes and tokens, assets, and answers to questions while it is built
What we need from you
- What the product is and who needs it, briefly and in your own words
- Access to the current version, or to the products you take as reference
- Who signs off on layouts, and by when
Projects in this area
Logistics
Reista
A client portal for a haulier: consignment status, route and paperwork for every delivery, with no call to the dispatch desk. The portal was the smaller half of the job — before it, no system held a status at all: it lived in drivers’ messages and in a dispatcher’s memory.
−70%
calls to the dispatch desk
Next.js · TypeScript · PostgreSQL
Medtech
Anamna
A patient app for a clinic: appointments, test results and reminders on one screen. The work underneath that screen was proving a patient is the person the record belongs to, and deciding what a notification is allowed to say.
18,000
active patients in the first year
React Native · Expo · Node.js
Fintech
Splitta
Instalments for online stores: buyer checks, a payment schedule and refunds — on real payments from day one.
7 weeks
from first call to production
Next.js · Node.js · Docker
What people usually ask
Contact
Send a description of the task
A reply with the scope, the timeline and a budget estimate comes within 24 hours.
The first call is 30 minutes, with no commitment on your side.
01
You describe the task
Five questions in the form, or a plain email — whichever suits you.
02
We answer within a day
With the scope, the timeline and a budget estimate, based on what you told us.
03
We talk for 30 minutes
To clear up whatever is unclear. It commits you to nothing.