What Web App Design Services Cover

Web app design services buy three things: the flows a user moves through, the full set of screens those flows need including the ones nobody demos, and a component system your engineers can build from without inventing anything. A marketing site is not part of it. The two are usually sold separately and priced very differently.

The confusion is worth clearing up before you brief anyone, because a studio that mostly builds websites will quote your app as a set of pages, and a web app is not a set of pages. Below is what the scope should contain, what usually gets left out, and how to tell which kind of studio you are talking to.

What is actually in scope

A serious web app engagement has four deliverables. Flows, which map what a user is trying to do and every route through it. A screen set, which is every state each screen can be in, not just the one that looks good in a deck. A component library, which is the buttons, tables, forms, and modals defined once so they behave the same everywhere. And a specification your engineers can read without asking questions.

Notice that three of those four are systems rather than pictures. That is the whole difference. Ten beautiful screens with no components behind them will produce an app that drifts within a quarter, because every new feature gets designed from scratch by whoever is free.

Four things that make a web app different

Authentication comes first. Sign up, log in, forgot password, expired session, invite a teammate, and the moment somebody lands on a link they do not have access to. None of it is interesting, all of it is used, and it is the part most often left to engineering to improvise.

Then data density. A marketing page has one message per screen. An app screen might show two hundred rows, twelve columns, and four filters, and it still has to be readable at a glance. Designing that well is a specific skill and it does not show up in a portfolio of landing pages.

Then permissions. An admin, a normal user, and a read-only viewer see different things, and every screen quietly has three versions. If permissions are not in the scope, they get decided by whoever writes the code that week.

And breakpoints. A web app on a laptop and the same app on a phone are not the same product. Decide early which parts have to work on a small screen and which do not, because designing everything twice is expensive and designing it once badly is worse.

What usually gets left out

Empty states, error states, and loading states are the three that vanish from scope most often, and together they are most of what a real user experiences. A new account has no data in it, so the first thing anybody sees is an empty screen. If that screen was never designed, your onboarding is a blank table.

Notifications and emails are the next gap. They are part of the product, they get written by nobody, and they end up sounding like a different company. Ask whether they are in scope. Usually they are not, and it is much cheaper to add them at the start than to fix them later.

Accessibility is the third. Contrast, focus order, keyboard navigation, and labels are cheap while the components are being made and expensive once the app is built. If you sell to any organisation with a procurement process, this will be asked about.

How to tell a web app team from a website team

Ask to see a table. It sounds trivial and it is the fastest test there is. A studio that designs apps will show you a dense data table with sorting, filtering, an empty state, and a loading state, and will have opinions about all four. A studio that designs websites will show you a pricing table.

Then ask how they hand work to engineers. The answer should include a component library with named states and a place where the rules live. If the answer is a Figma file and a call, the specification is going to be assembled by your developers as they go, and the design will be interpreted rather than implemented.

How it gets priced

Two shapes are common. A fixed scope, which works if you can list the flows today and nothing is likely to change under you. Or a monthly arrangement, which fits better when the product is still moving, because an app is never really finished and each new feature needs the same components extended rather than redrawn.

The number is driven by flow count more than screen count. Adding a screen to a flow you already designed is cheap. Adding a whole new flow, with its own permissions, states, and edge cases, is not. When you get a quote that feels high, count the flows rather than the screens and it usually explains itself.

Where to go next

If your product is native rather than browser based, the scope is different and what mobile app design services include covers what changes. If the specific screen you are worried about is the main data view, designing a SaaS dashboard goes deeper on density and hierarchy than this page can. For the size of the number rather than its shape, what design costs for a tech company breaks down what moves it.

And if you want names rather than principles, we keep a comparison of studios that design web apps, including which of them publish a starting figure.

Studio Maydit designs web apps and the sites that sell them, in fixed scope for teams with a date and on a monthly retainer for teams still shipping. If you want a straight answer on what your app actually needs designed, book a free 30-minute call.