Discovery
We read the product before we form opinions about it. A login, a walkthrough, the tickets and the analytics.
Products
SaaS platforms, dashboards and internal tools, designed so the value is visible without a walkthrough.




What we do
What the product should be, ranked against what it can be this year, and research to prove it.
See the WHMCS conceptThe process
We read the product before we form opinions about it. A login, a walkthrough, the tickets and the analytics.
Interviews with the daily users and with whoever signed the invoice, plus a pass through your own support calls.
The information model, navigation, object relationships, permissions and states. We settle this layer before any screen is drawn.
Clickable prototypes, tested with real users before anyone writes a line of production code. Freelogo alone needed 38 of them.
Production-quality UI across the flows that matter, every state included. Your own engineers review the work with us weekly.
The component library, tokens, documentation, usage rules and versioning, plus a written rationale for every structural decision we made.
Our work
“The work speaks for itself.”
FAQs
A full engagement, from discovery through research, architecture, prototypes, interface and design system, is a twelve-week project priced as a fixed scope. A design system on its own is closer to five weeks. We give you the number at proposal stage, before you commit to anything.
UX is the structure: what the product does, in what order, for whom. UI is what each screen looks like. Agencies that sell them separately usually do one badly. We do the architecture first, every state and every flow, and only then the visual layer, so engineers get a structure they can extend, with the screens built on it.
Yes, and it is most of our product work. TSRGD, SolusVM and the hosting control panels we design are all live products with real users. We rebuild the architecture underneath the screens so the team can ship the new version in stages while the old version keeps running for its users.
That’s the normal experience, because most handovers are a Figma link and a phone number. Ours is a documented library with tokens named against your code, every state specified, and time booked in during your build.
Yes, and it’s usually the best version of this. We define who owns what in week one, in writing, because that’s what slips.
Then buy part of it. Plenty of engagements are a design system on its own, or just architecture and prototypes alone.
Research with real users, an information architecture, prototypes tested before code, production-ready UI for every state, and a documented design system with tokens and governance rules. Front-end development if you want us to build it. One named senior designer throughout.
Twelve weeks for a full engagement: discovery, research, architecture, prototypes, interface and system. A design system on its own is closer to five weeks. You get the date at proposal stage, before you commit to anything at all, and we hold to it.
We’ve designed control panels, server virtualisation, hosting infrastructure and statutory compliance tools. cPanel, Plesk, WHMCS, CloudLinux, HostPapa, Servebolt, SolusVM. If your product needs a glossary before a designer is any use, that’s our normal starting position.
A component library with tokens, documentation, usage rules and a version history, so a new screen is assembled rather than drawn. You need one when your engineers start inventing components.
Related reading
Almost right is the expensive kind of wrong. It moves the work from doing the task to checking whether the machine did it, and most products have not designed that part at all.
Since 2 August 2026 the EU AI Act requires you to tell people when they are dealing with a machine. Most teams will answer that with a footer, which is the one place nobody looks.
Most case studies are written as a record of what the supplier did. Buyers are scanning for a situation that looks like their own, and most case studies never describe one.