Products

Software that stops needing a demo

SaaS platforms, dashboards and internal tools, designed so the value is visible without a walkthrough.

Brand identity templates displayed in a design software interface, showing business cards and stationery for Tradenest.
Two browser windows showing a project management interface with road sign diagrams and task lists.
Project management dashboard showing active projects, recent items, and pinned notes for a user named Richard.
A design interface showing text customisation options with font selection, styling controls, and a dark blue colour picker.

What we do

Strategy, interface and the system underneath

What the product should be, ranked against what it can be this year, and research to prove it.

See the WHMCS concept

The process

Six stages. A date we hold.

01

Discovery

We read the product before we form opinions about it. A login, a walkthrough, the tickets and the analytics.

02

Research

Interviews with the daily users and with whoever signed the invoice, plus a pass through your own support calls.

03

Architecture

The information model, navigation, object relationships, permissions and states. We settle this layer before any screen is drawn.

04

Prototypes

Clickable prototypes, tested with real users before anyone writes a line of production code. Freelogo alone needed 38 of them.

05

Interface

Production-quality UI across the flows that matter, every state included. Your own engineers review the work with us weekly.

06

Handover

The component library, tokens, documentation, usage rules and versioning, plus a written rationale for every structural decision we made.

“The work speaks for itself.”
Corey HammondGeneral Manager, HostPapa

FAQs

Questions we get

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

Worth reading before you call

Essay

Nobody uses AI they cannot check

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.

Essay

AI disclosure is a design problem

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.

Essay

Case studies are how buyers find you

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.

Connect

Hire us

Hire us

Brief writer

Write a brief

Email us

Email