Most Irish SaaS teams treat design as something you do twice — once for the marketing site at launch and once for the product UI when the founders can no longer pretend it is fine. By then both have drifted apart visually and the brand experience breaks at the login wall. The fix is not a third redesign. The fix is to treat marketing site, product UI and brand as one design problem with the same vocabulary.
What's Different About Designing for SaaS
Activation is the conversion
In SaaS the form-fill is the start, not the end. A signed-up user who never activates is worse than a lost visitor — they cost support time and skew the metrics. The activation flow is the conversion screen that matters.
The dashboard is the brand
Customers spend a hundred times more minutes in the product than on the website. The product UI is what the brand actually feels like once the marketing copy stops.
Engineering owns half the design
SaaS design that ignores the build pipeline produces beautiful Figma files that ship as something else. The component library and the dev relationship are part of the deliverable, not after-thoughts.
Pricing is a design problem
Plans, feature gates, upgrade flows, billing screens — these decide expansion revenue. They are usually under-designed compared to the marketing pages and under-tested compared to the product features.
The Five Surfaces That Carry the Weight
Marketing site & pricing page
Positioning, proof, plans. The first hundred seconds where prospects decide whether to sign up or close the tab.
Sign-up & first-run
From the moment they click "Start free" to the moment they do the first useful thing in the product. The single most under-designed flow in most SaaS products.
Core product UI
Whatever the customer does on day 30. The screen they will look at thousands of times. Tiny improvements compound here.
Billing & account
Plan changes, seat management, invoices, payment retries. Usually inherited from the billing provider and rarely styled. Designed properly, it reduces involuntary churn.
Empty & error states
The forgotten quartile of the product. New workspace with nothing in it, integration that broke, search that returned no results. The states that decide whether new users persist or quit.
Patterns We Use Repeatedly in SaaS
- Activation milestone, not feature tour. First-run experiences that get the user to the first useful outcome ("you sent your first invoice", "you imported your first contact"), not first-run experiences that introduce every feature.
- Documented empty states. Every list, table and chart needs a designed empty state that explains what it will look like with data and how to get data into it.
- Component library as the deliverable. Not Figma frames — a real, documented, dev-shippable library. The system survives launch; the launch screens age out within months.
- Inline upgrade prompts. Feature-gate moments designed as helpful boundaries, not blocking walls. The upgrade prompt that explains why and what changes converts better than the one that just blocks.
- Settings that respect hierarchy. Most SaaS settings pages become a graveyard. Grouped, searchable, deep-linked settings are a 3x usability lift for a 1-week design exercise.
What We Have Shipped
The closest comparable engagement on the portfolio is Emerald Tech Solutions — a B2B technology business with the same mix of trust-heavy marketing site and signed-up-user dashboard work. The SaaS variant adds activation flows, billing and a shared component library to the same playbook.
We are not a product-led growth consultancy. We do not run experiments on your funnel for you, and we will not pretend to be a fractional CPO. We design the screens; you decide the strategy. Where the strategy needs help, we partner with people whose actual job that is.
The Three Decisions That Most Affect a SaaS Project
Self-serve, sales-led, or both?
A pure self-serve product needs different sign-up, activation and pricing surfaces from a sales-led one. Most growing SaaS companies are both — and that is harder to design well than either pure mode.
Component library — own, fork, or off-the-shelf?
Building from scratch is slow; relying on Tailwind UI is fast but generic; forking Shadcn or Radix sits in the middle. The choice shapes how fast the team can ship after launch.
Single workspace or multi-tenant from day one?
Workspace switching, seats, roles and permissions are very different to design at three users vs three hundred. Building for the later state on day one is expensive but cheaper than retrofitting.
Frequently Asked Questions
Do you work with pre-funding SaaS teams?
Yes — particularly the brand-and-marketing-site phase ahead of a funding round. Product-UI engagement usually waits until there is enough product to design around.
Can you design inside our existing component library?
Yes. If you are on Shadcn, Radix, Mantine, MUI or a custom system, we design within it and contribute back to it.
Do you do mobile apps?
Native app design — yes, where it sits inside a wider SaaS engagement. Standalone native-only app projects are not our sweet spot.
How do you price ongoing design support?
Day rates or sprint blocks, depending on cadence. No open-ended retainers without a defined outcome.
Have a SaaS product where the design is starting to hold the business back?
The free audit looks at marketing site, activation flow, and the highest-traffic product screen and tells you which one to fix first.
Request the free audit