Doow

Doow gives finance and procurement teams a single view of every software dollar. Contracts, corporate cards and bank transactions are mapped automatically, alongside seats, usage, prepaid credits and token burn.

Designed the platform end-to-end: the spend dashboard and SaaS intelligence views, applications and vendors, users and employees, subscriptions and renewals, expenses and virtual cards, the Derek & Mina AI finance agents, and the design system underneath it all.

Role
Product Designer, sole designer
Timeline
Six months
Team
Founder, 4 engineers, me
The problem
Finance teams could produce a software spend figure but could not stand behind it. A tool bought for a six-person pilot quietly renews at 60 seats for three years, and nobody notices until the card statement lands in a spreadsheet.
What I owned
Everything a user touches: research and competitive teardowns, the spend dashboard, contract modelling for seat, usage and credit billing, pricing and plan changes, the governance console for the Derek and Mina AI agents, and the design system under all of it.
View Live

Overview

Doow is a SaaS spend platform for finance teams. I was its only designer for six months, alongside the founder and four engineers. This covers getting a company's data in, modelling contracts when every vendor bills differently, and giving two AI finance agents real access to financial data with controls a finance team could sign off on.

Success metrics

What success looks like, and why I cannot show it yet

Doow shipped recently, so there are no outcome numbers yet, and I would rather show none than pass off screen counts as impact. These are the five I will measure.

  • Onboardings completed. Sign-ups that connect a bank or identity provider and see their spend mapped in the first sitting.

  • Contracts added. How many each account adds, and how quickly.

  • Waste cut. How far waste falls once a company's software spend sits in one view.

  • Duplicate apps down. Fewer overlapping tools and licences once teams manage them in Doow.

  • Recommendations acted on. How often teams use the alternative app recommendations to decide what stays.

The problem

Nobody knows what their software costs

Not because finance teams are careless. The information lives in about nine places, and none of them talk to each other.

The contract is a PDF in someone's inbox, and the charge lands on a card under a merchant name that looks nothing like the product. So a tool bought for a six person pilot renews at 60 seats for three years, and nobody notices until the card statement lands in a spreadsheet.

Zluri and Torii come at this from IT: what is installed and who has access. Ramp and Cledara come from cards: money that has already moved. Neither holds the agreement itself, the rate, the terms and the end date. The contract decides whether a renewal is a negotiation or a surprise, so Doow maps contracts alongside cards and bank transactions, then adds seats, usage and credits on top.

Research

Making sure this was somebody's problem, not just our idea

I took the competitors apart first, above all their help centres. Documentation is written against what shipped, so it shows what each data model can and cannot express.

Then we interviewed the three groups who touch this spend, asking how they cope today rather than whether they liked our idea. A workaround someone has already built is better evidence than an opinion.

What each group needed
  • Finance wanted one software number they could defend to the board. Every version they had was built by hand.

  • Procurement wanted lead time. Their leverage is in the weeks before a renewal, and they kept hearing about renewals after they had rolled.

  • Managers wanted to know who used a tool, without becoming the person who polices licences.

My role

Six months, four engineers, one designer

I joined to lead design on a product with a strong thesis and almost no interface: no design system, no components, and a data model still being argued about. I owned everything a user touches, from research to the design system.

After the first few weeks of research, design and build ran on the same features in the same weeks. Design never got to run ahead, so I bought certainty cheaply: each feature got a working prototype in code, tested with a few users before engineering built it. With Claude Code, Cursor and the Figma MCP, that takes an afternoon rather than a week.

Onboarding

The first hard question: how do you get the data in?

Doow is a shell until it can see your identity provider, bank, accounting system and HRIS. The order of the four steps was most of the design.

  • Identity and SSO first. It shows who works here and which apps they use, and is usually set up already.

  • Bank and cards second, because that is where the money moves.

  • HRIS third, to attach departments and managers to the people just found.

  • Company details last. It is the only pure data entry, so it comes with three real connections already behind it.

Doow onboarding step one, connecting an identity or SSO provider

Dashboard

What to show someone in the first four seconds

The obvious way to open a spend product is one giant number. I argued against it. A finance lead opening Doow on a Tuesday already knows roughly what their total is. What they cannot get anywhere else is what changed since last week, and what has a date on it.

So the dashboard opens on three task cards: what needs attention, what renews soon and what the system has noticed. The totals come after.

Recommendations

Should you replace Asana?

The most opinionated screen in the product, and the one most willing to tell you not to switch.

Design has Figma, product has Miro and marketing bought Canva: three bills for one capability. Doow groups tools by what they do, which surfaces the overlap. The harder question is whether to switch.

A price comparison leaves out the cost of moving, which usually decides it. So each recommendation shows year-one net savings, in red when negative, payback in months, the estimated switch cost, and a feature match that names what is missing.

Contracts

The hardest modelling problem in the product

Slack charges per seat. AWS charges for usage. OpenAI sells prepaid credits that burn down as tokens. Salesforce sells a negotiated contract with a floor and overage above it. Some vendors do two at once.

One screen has to hold all of it, because four separate flows would give four totals that do not reconcile, and a dashboard nobody trusts. The panel asks a few yes or no questions and opens only what the answers need, so a Slack plan takes twenty seconds and a hybrid enterprise contract still fits. A running total in the footer lets you check it against the invoice before saving.

Data matching

Real data never arrives clean

Contractors have tool access and no HRIS record, leavers keep licences for months, and service accounts belong to nobody. A card charge arrives as "MSFT * E0800ABCD" and has to be tied to a subscription, a plan and a department. In both cases the mismatches come first: users with no employee record, charges with no subscription. When Doow cannot match something it says so, rather than guessing.

AI agents

Derek and Mina, two agents that hand back finished work

Derek and Mina are Doow's AI finance agents. They audit filings, run analysis and produce board ready decks. Returning work someone will act on is a different design problem from returning text: it needs review, provenance and a way back.

Derek investigates, tracing a jump in spend to the vendors and contracts behind it. Mina packages, turning an analysis into something a CFO can read. Either can do either, as the replay shows, but the split gives each a default posture and a reason to ask which one you want before you start typing.

New chat

How can I help you today?

Ask Derek anything...

Smart

Responses stream as they are written. Forty seconds on a still screen looks broken. The same forty seconds with text arriving reads as work in progress.

AI governance

The part almost nobody designs: governing the agents

Give AI agents access to financial data and the power to act, and someone has to see what they did, cap what they cost and decide what they may touch.

Getting agents approved for real financial data is mostly a design problem. I designed an admin console around five questions: who uses it, what it costs, what it did, what it may do, and where people reach it.

Adoption breaks usage down by department, person and channel. If finance reaches Derek through Telegram and engineering uses the web app, that tells you where to invest. Personal settings live on a separate surface, because setting company rules and managing your own history are different jobs.

Pricing and billing

Pricing is a state machine

I designed the pricing page and every billing state behind it.

A trial with a card on file can never expire: the charge either succeeds or fails into dunning. I found that by building a working model of the billing states and finding no route into expiry. It removed a branch of the product and made dunning the main failure path, so that flow had to be good.

Doow prices on tracked spend, not seats, because three people managing twelve million dollars of software get far more from it than thirty managing two hundred thousand. Nobody can pick a tier before Doow knows their spend, so plan selection moved to the end of onboarding, and tiers below your spend show as disabled with the reason inline.

AI usage above the allowance is prepaid, so the balance is the cap, with no usage invoices and no limit buried in settings. Overage is billed at cost, which loses a little after card fees. We chose that over a margin hidden in the metering.

Design system

A design system the team could run without me

Close to four hundred screens only happens by composing from a system. I checked all 96 colour tokens against black and white text, and the point where a label flips from black to white falls between steps 500 and 700 on every ramp. That became a rule engineers could apply without me: lower steps are fills and borders, upper steps carry text. Focus states are designed into every button variant rather than left to the browser.

components in the library
668
variant sets
268
instances placed across the file
50,608
colour tokens across 8 ramps
96

Nearly the whole interface comes from the library, so a component change spreads everywhere instead of becoming a two week audit.

Reflection

What I would do differently, and what comes next

I over-engineered the first subscription panel. It showed every contract type at once, which proved I understood the complexity without solving it. The question-led version is what I should have drawn first.

I designed empty and error states too late. On a product whose premise is incomplete data, the empty state matters more than the full one.

Next is reach rather than more product. Banking, payments and accounting would make Doow a system of record rather than a system of insight, but only once we know which parts people rely on.

Fin