The product is where every promise gets tested.

We design the flows and interfaces, build the internal tools your team keeps asking for, and engineer the systems underneath so the whole thing holds up once people rely on it. It sits at the centre because it’s where the other two get tested: brand makes the promise, marketing brings people in, and the product is where they find out if it was true.

Product and engineering sits inside Marketing and growth, which sits inside Brand and mission.

Brand and mission

Why the company exists, and how it sounds.

  • Naming and identity
  • Voice and narrative
  • Customer experience

Marketing and growth

Who hears about it, and how they find it.

  • Content and socials
  • Web
  • SEO / GEO

Product and engineering

What people actually use.

  • Product design
  • Internal tools
  • Engineering

How it meets the other two

  1. Product design – Customer experience

    People learn what a brand means inside the product, not on the homepage. So the onboarding, empty states and error messages get the campaign’s voice.

  2. Engineering – SEO / GEO

    Search engines and AI answers read your pages, not your pitch. Speed, structure and markup are engineering, so they go in from the first commit.

  3. Engineering – Web

    The site and the product usually drift apart. We build both from the same components, so when the product moves, the site keeps up.

Start with a product sprint.

One problem, a fixed length, and a working prototype in front of your users at the end. If it’s worth building, you’ll know. If it isn’t, you’ll know that cheaper.

Scope
One product, flow or internal tool
Length and price
Fixed, agreed before we start
Best for
A team that wants to see the fix before committing to it

How the sprint runs

  1. Audit

    We go through the product as it is today, with your team and your data, and find the places people slow down, work around it or give up.

    You getAn audit of the product or flow as it is

  2. Prototype

    We design the fix and build it far enough to click through. Not a deck: the real flow, in a browser, on your content.

    You getA clickable prototype of the fix

  3. Test

    It goes in front of your actual users. We watch what they do rather than what they say, and change it while we still can.

    You getWhat your users did with it, in their words

  4. Plan

    We write up what to build, in what order and roughly what it costs, whether or not we’re the ones who build it.

    You getA build plan and estimate, yours to keep

What we actually do.

The flows and screens people actually use, and the design system that keeps every one of them behaving like the same product.

  • Flows

    Who it’s for, what they came to do, and the shortest way there.

  • Screens and states

    Every screen, including the empty, loading and error ones people hit on a bad day.

  • Design system

    The components and rules your team builds new screens from once we’ve gone.

See the Keeyu case study

Tools for your own team, not your customers. Software shaped around how your company works, so the repetitive jobs get done without hiring more people for them.

  • Operations

    Tools that find, check and sort the work your team does by hand, from grading new sites to chasing leads.

  • Brand tools

    Generators for illustrations, assets and copy in your style, so anyone on the team can make something that looks like you.

  • Team dashboards

    One view of what needs a person today, pulled from the places your team checks every morning.

See the Lumos case study

The systems and integrations underneath, built to take the load once people depend on them, and easy for your team to build on.

  • Front end

    Built from the design system, so what ships is what was designed.

  • Back end and integrations

    Your data, your APIs and the services you already pay for, connected properly.

  • Handover

    Documented and readable, so your own team can keep building on it.

See the Managed case study

See what we’ve built

From the blog

All posts

Questions we get asked

If yours isn’t here, ask us. We’d rather answer it before you sign anything.

Ask us
  1. Yes, and we’d rather. We can design alongside your engineers, build with them, or take one piece of the product end to end and hand it back in a state they can keep building on.

  2. Usually. We look at what you run before we scope anything, and if something sits outside what we do well, we’ll say so rather than learn it on your time.

  3. No. A lot of our work starts with one flow, one internal tool or one integration. The product sprint exists for exactly that.

  4. Fixed, for a defined piece of work, or as a team over time for a product that keeps moving. We agree which before we start.

  5. You do. The designs, the code and the documentation are yours.

  6. We can stay on and keep improving it, or hand it over with what your team needs to run it. Your call either way.