SaaS website and web app design
A marketing site shows what a product promises. Below is the product itself: a working issue tracker with a dashboard, a board, full settings and a workflow you can finish yourself. That's our web app UI design, running, and the same team designs the SaaS landing page that sells it.
Start a projectQuenlo, an issue tracker with a live dashboard, list and board views, a command menu and complete workspace settings.
We built this app to show what we build. Quenlo is an invented brand, like every brand in our demos, and none of them is a client.
What a web app has to get right
A trial user decides in the first session whether a product is worth learning. That decision happens on the dashboard, in the core workflow and inside the settings, long before anyone reads the pricing page.
Dashboards that answer "where are we?"
SaaS dashboard design starts with the few numbers a team checks every morning, and every number traces back to real records. In the demo, 29 open issues means 29 rows you can open.
Keyboard first, mouse welcome.
A command menu and single-key shortcuts cover the common actions, and every drag has a menu alternative, so the product works for people who never touch a trackpad.
Settings people can find.
Members and roles, billing, notifications, integrations and API keys, organised the way an admin goes looking for them.
States written with care.
Empty lists tell people the next keystroke. Errors say what went wrong and how to fix it. Product UI design lives in these small screens as much as in the big ones.
Try this in the demo
Press Ctrl K to open the command menu, then open API-96 from My work to see its side panel.
Create an issue with New issue, or press C. It lands at the top of the list as WEB-186.
Switch to the board and move WEB-137 from Todo to In progress with its Status menu instead of dragging.
Open Settings, then Billing and plan: 8 of 10 seats, $80 a month.
Each of those details was a decision, and in your product every one follows your own users and data.
Marketing site and product, one team
Startup website design usually splits across two teams: one for the site that sells, another for the app that delivers. The seams show, from mismatched type to a sign-up flow that feels like a different company. We design both together, so the promise on the landing page and the first screen after sign-up are clearly the same product.
Web apps rarely stand alone. At the very least they have to connect to billing and sign-in. We build and run business systems as well as websites, so those connections are designed alongside the screens instead of bolted on afterwards. Every demo we've built sits on our web design page. When the product itself needs building, beyond the design, that work sits with our custom software development team.
How a project starts
- 01
Discover.
A call about your product: who uses it, and where new users get stuck today.
- 02
Design.
We map the dashboard and a core workflow against your real data, and you click through them before anything is built.
- 03
Build.
Engineered to load fast and stay maintainable as the product grows, delivered in working increments.
- 04
Launch, and after.
We ship it, and we stay on for the next features and the fixes that follow.
FAQ
Do you design the product, or only the marketing site?
Both. The demo is a product: dashboard, board, settings and a complete workflow. We design the marketing site in the same system, so the two feel like one company.
Can you work inside our existing design system?
Yes. We extend what you have and document new components as we add them, keeping tokens and naming consistent with your codebase.
Do you build the front end too?
Yes. We design and build, so what you click through in the design stage is what ships, with accessible markup and real states for every screen.