Mobile App Design Services

Screen count is the obvious answer and the wrong one. What you pay for is the shared set of buttons, forms and headers every screen is built from, and the awkward states nobody sketches: empty lists, slow connections, error messages, the longest name in your database. Get those right and the twentieth screen is nearly free.

Four to eight weeks is normal for a first full set of screens, less if the app is small. What moves the date is almost never drawing: it is how many people have to approve. Two named decision-makers can turn a round around in days. A committee of eight turns the same round into two weeks.

Yes. We start by opening the existing file and looking for one thing: whether the screens are built from reusable components or drawn one by one. Reusable components mean we can pick up where you left off. Loose screens with the spacing typed in by hand usually mean rebuilding the foundations, which we would say before quoting.

Yes, though we would rather not put names on a public page without asking them first. What transfers is the method: a component library that designers and engineers read the same way, and short rounds of testing with real users, run unmoderated through Maze, before anything reaches a developer. On a call we can show the closest example to your product.

The working file, not a flat export. You get the Figma project with the components still editable, every icon and image exported at the sizes each screen needs, and the colour, spacing and type values written down so developers build from the same numbers we did. Any animation comes as a Lottie file a developer can drop straight into the build.

Because we design for the phone the app will actually run on. Text has to pass the contrast levels in the accessibility standard, WCAG 2.2 AA, touch targets have to be big enough for a thumb, and reviewers at the app stores do read their own guidelines. We also draw the states that break handsome prototypes.