DESIGN
APP DESIGN
- 30+ projects
- from 1 week
- ready for development
Interfaces for mobile, desktop and web apps: screen flows, states, errors, empty screens. We design what people use every day, so ease of use outranks the first-screen effect.
WHO IS IT FOR?
Three situations where the interface decides the fate of the product
- .01
THE PRODUCT EXISTS AND IS AWKWARD TO USE
The app works, the features are there, and people do not get as far as the second screen. Or they do and then do the wrong thing — while support explains the same point to every new user. The cause is almost never the features. It is that the interface was assembled as development went along: every screen was solved on its own and no shared logic ever emerged between them.
- .02
DEVELOPMENT IS UNDER WAY AND THERE ARE NO MOCKUPS
The team builds the product as it goes: a developer draws the screens, the buttons come from wherever, and every new feature is added wherever there was room. From there the arithmetic runs against you: reworking the interface inside a finished product costs several times more than designing it before development starts — and it almost always has to be done.
- .03
PEOPLE WORK IN IT ALL DAY
An internal system, an operator’s console, a working app for staff. A person spends eight hours in it, and every unnecessary action is multiplied by hundreds of repetitions a week. Different rules apply here: what matters is not the first impression but the density of the information, the speed of an action, and the fact that by the end of the day a person is not worn out by their own tool.
WHAT'S INCLUDED
We do not build below this line
- - A review of scenarios and roles.01
- - Screen structure and a prototype.02
- - Custom design, never a template.03
- - A design system and components.04
- - Every state: loading, error, empty.05
- - Platform rules: iOS, Android, desktop.06
- - Source files and handover to development.07
- - Revisions after delivery.08
- THIS IS THE FLOOR, NOT A PACKAGE
Everything listed ships in every project — even the simplest and cheapest one. There are no stripped-down versions.
- THERE ARE ALWAYS MORE SCREENS THAN YOU THINK
For every main screen there are three or four utility ones: loading, error, empty list, no connection, no permission. Products break on exactly those, so they get drawn rather than improvised by a developer along the way.
- A SYSTEM, NOT A PILE OF PICTURES
Components are built once and reused. A new screen is then assembled from parts that already exist — by you, by us, or by your own designer.
WHAT'S INSIDE
EVERY PROJECT LOOKS LIKE ITSELF
We do not take ready-made assemblies and we do not bend a business to fit somebody else’s grid. The design is built for the job from scratch: its own composition, its own typography, its own rhythm, its own motion. Which is why no two of our projects look alike — open the portfolio and compare them yourself. With studios that work from templates every project is recognisable from the first screen, and the client notices that too.
DESIGN THAT SURVIVES DEVELOPMENT
A beautiful mockup and a working site are not the same thing, and the difference surfaces during the build: what happens on hover, what on an error, what if there is three times more text, what on a tablet. We write the code ourselves — so we know where a mockup falls apart, and we describe it before a developer has to ask. Whether we build it or your team does, the result will match the picture rather than approximate it.
A SYSTEM, NOT A PILE OF PICTURES
Grid, typography, colour, states, components — built once and reused. A new page is then assembled from parts that already exist rather than drawn again: that is what separates a project you can keep developing from one you will be rebuilding in six months. Plus everything that usually gets forgotten: empty screens, loading, errors, long text, and how all of it looks on the smallest phone there is.
BEAUTIFUL AND FAST IS ONE JOB, NOT TWO
Heavy animation, 3D, a scroll-driven sequence — all easy to draw and hard to keep light. It is usually paid for in speed: the site impresses in a demo and takes four seconds to load for the client. We design the effect and its implementation together — what the browser has to compute, what loads later, what switches off on a weak device. A heavy scene and a slow site are not the same thing, and the second is not compulsory.
CATEGORIES
Three levels of scope. Yours is the one you recognise yourself in
AN APP FOR ONE JOB
WHEN IS THIS YOUR CASE?
One clear scenario and one kind of user: a catalogue with ordering, a booking flow, an account area, an app inside Telegram. The whole base build: a review of the scenarios, screen structure and a prototype, custom design, components, every state, the platform rules, source files and handover to development. Nothing stripped out — just without the extras you do not need yet.
A PRODUCT
WHEN IS THIS YOUR CASE?
The app is the product: many screens, several roles, regular use. A full design system with a component library, light and dark themes, adaptation to iOS and Android or to different screen sizes, motion and transitions, onboarding for new users, documentation for development. The design is put together so that new features can be added without rebuilding what is already there.
A WORKING SYSTEM
WHEN IS THIS YOUR CASE?
An interface people spend the working day in: an internal system, an operator’s console, a tool for staff. Design solves a different problem here — dense tables and lists, bulk actions, filters and search, keyboard shortcuts, separate interfaces for separate roles, large volumes of data on screen. The error paths get their own attention: where a person can slip on autopilot, and how the interface resists it.
FAQ
Answers to the most popular questions
From $1.000 for an app with one scenario to $5.000 and up for a working system with several roles. The figure depends on the number of unique screens and scenarios, on how many platforms are involved, and on whether it needs a full design system with components. After the first call you get a plan with the scope broken down by stage rather than a guess.
An app with one scenario takes 1–2 weeks. A product with several roles and a design system, 1–3 weeks. A working system, from 2 weeks. Planning before drawing is set aside separately: until it is written down who does what and in what order, it is too early to draw screens.
Not every screen, but some of them yes. The platforms navigate differently, their elements behave differently and their users expect different things: an app drawn entirely to one platform’s rules feels foreign on the other. We build one shared system and adapt what genuinely differs. That is cheaper than two sets of mockups and more honest than one set for both.
Yes, that is a normal arrangement — we do a share of projects exactly that way, for companies with their own team and for other studios. We build apps ourselves, and that changes the quality of the handover: the mockups are put together knowing how they will be implemented. None of which ties you to our development.
Yes, and it is a common request. First we look at what happens now: where people get stuck, what they never reach, what they contact support about. Then there are two routes — fix the problem areas one by one, or rebuild the interface on a design system. The first is cheaper and faster; the second makes sense if the product is going to keep growing.
The limit is settled before we start: usually two rounds at the direction stage and two on the final screens. Revisions inside the chosen direction are part of the work. Changing direction after it has been signed off is a new task with its own timeline and price.
We work in Figma. What you get is a file with the screens, the components, the styles and a description of the states, and access to it stays yours permanently. Plus everything development needs: icons and images exported at the right screen densities, fonts, a description of the animation and transitions. If your own team is building it, we hand over on a call and answer questions as they go.
You do. The files, the rights and every asset are handed over with the project. Any designer can carry on with them — we put the file together so that someone who did not draw it can find their way around.
Revisions after delivery are part of the work — they usually surface once development reaches the awkward parts. After that the app grows: new features, new screens. If the design system was built properly, your own team will assemble most of them. Whatever genuinely needs a designer we do separately, as it comes up.