Doow

Every finance lead at a 500 person company has an annual software number. Most of them hold it loosely, because the figures behind it sit in systems that were never built to reconcile.

That is not carelessness. The contract sits in a PDF in someone's inbox. The charge lands on a card under a merchant name that looks nothing like the product. The seat count lives in an admin panel only one person in Engineering can open. The usage data, if it exists, is in a dashboard nobody checks between renewals.

So you get the classic pattern. A tool is bought for a six person pilot, the pilot ends, the contract auto renews at 60 seats for three years, and nobody notices until someone exports the card statement into a spreadsheet and starts squinting.

Doow exists to make that invisible spend visible. It maps contracts, corporate cards and bank transactions automatically, then layers on seats, usage, prepaid credits and token burn, so you see not just what you pay but what you get.

The category is crowded, so it is worth saying where this sits. Zluri and Torii come at it from IT, and they are good at discovery and licence hygiene: what is installed, who has access, what to switch off when somebody leaves. Ramp comes from the opposite end, out of corporate cards, so it is strong on money that has already moved. Cledara works that same payments side, issuing a virtual card per subscription so every charge is tied to a named tool, with renewal dates tracked next to it.

Doow sits in the space between. Discovery covers what is installed and card data covers what has already been charged, and between them they still leave out the agreement itself: the rate, the terms, the date it ends. The contract is the third thing, and it decides whether a renewal is a negotiation or a surprise.

The category already had companies in it, which is either a warning or a map depending on how you read it. So I went through them properly. Zluri, Torii, Ramp and Cledara, plus the smaller tools that surface when a finance team starts searching for this. Marketing sites, pricing pages, product tours, help centres and every demo recording I could find.

The help centre is the useful one. Documentation is written against what actually shipped, so it exposes what a data model can and cannot express, and which edge cases generate enough support tickets to have earned their own page.

Desk research maps the category and says nothing about whether anybody is in pain, so we spoke to the three groups who touch this from different sides: finance, procurement, and the department managers who ask for the software in the first place.

I went in trying to find out how they cope today rather than whether they liked our idea. The workarounds people have already built are the evidence worth collecting, because they cost somebody real effort and would exist whether or not we ever shipped anything.

That is three different jobs sitting on one dataset, and it is the single most useful thing the research gave me. It is why the product is not one spend dashboard with three tabs bolted onto it, and when a screen later in this case study looks like it is carefully trying to serve two audiences at once, that is usually what is going on.

It also settled an argument we could otherwise have had for months. Visibility was never the binding constraint. Everyone we spoke to could already produce a spend figure. What none of them could do was stand behind it, or reach it while there was still time to act on what it said. That is a product about trust and timing rather than one about display, and we stopped debating which we were building.

I joined to lead design on a product that had a strong thesis and very little interface. There was no design system, no component library, no established patterns, and a data model that was still being argued about.

The work that followed was mostly definition: working out what the product actually is, screen by screen, alongside the founders and engineers, and then building the machinery that lets it keep growing without falling apart.

I also wrote a lot of the interface copy, because on a product like this the copy is the design. Choosing between "Add Subscription" and "Add Plan" commits you to a position on the data model, and getting those words wrong costs you a support ticket every single day afterwards.

Eight months. Four engineers. One founder I worked with closely enough that most decisions happened in conversation rather than in a document. One designer, which was me.

That headcount decides more about a product than any process does. The research at the top of this case study was the whole of it, front loaded into the first few weeks and never repeated as a formal phase. After that there was no discovery sprint and no stretch where design ran ahead and engineering caught up. Design and build happened on the same features, in the same weeks, for eight months.

So the process had to buy certainty cheaply. At every feature stage I built a working prototype, put it in front of a few selected users, and iterated on what came back before the real version got built.

Doing that with LLMs is what made it viable at this size. A prototype that once cost a week costs an afternoon, which changes what is worth testing. You stop reserving prototypes for the big risky flows and start using them on anything you are unsure about, which here was most things.

The visible cost is the design system, which I built after the screens rather than before them. That was not an oversight. It is what eight months with one designer buys you.

That pairing of spent against utilised is the whole product in one column group. A cost is only actionable next to what it bought, so the two sit in adjacent columns rather than on separate screens.

Scale decides whether a table like this survives a real company. A 500 person business can be running several thousand applications once everything discovered is counted, and a table that is pleasant at 50 rows is unusable at 5,000.

So it is paginated, with both a search and a full filter set rather than either alone. Search is for when you know the name. Filters are for describing a shape: unowned apps above a threshold, anything renewing this quarter, discovered but never mapped to a subscription.

Columns are yours to pick, twelve available, because the columns a procurement lead wants are not the ones an IT admin wants. If your selection runs wider than the viewport the table scrolls sideways rather than crushing everything to fit. A column too narrow to show its value is worse than one you scrolled to.

Most tools that suggest cheaper alternatives show you a price comparison, you notice the cheaper option is missing the one feature your team lives in, and you close the tab.

A price comparison leaves out the cost of moving, which is usually the number that decides it. So this view prices the whole switch: the migration effort, the productivity dip, and the capability you would be giving up, alongside the difference in list price.

Every recommendation carries five things most comparisons leave out.

This distinction sounds pedantic until you try to build the product. Your HRIS knows about employees. Your SaaS tools know about users, identified by email. Those two sets overlap but never match.

Contractors have tool access and no HRIS record. Leavers keep licences for months after their last day, which is both a cost problem and a security problem. Shared accounts belong to nobody. Service accounts look like people. Someone's personal Gmail is on a licence because they signed up before the company had SSO.

So Users and Employees is one surface that holds both realities and shows you where they disagree.

I also designed three separate paths for getting people into the system, because the real world does not hand you clean data.

A card transaction shows up as something like "MSFT * E0800ABCD". A human can eventually work out that this is Microsoft. A system needs to map it to a specific subscription, on a specific plan, owned by a specific department, and it needs to be honest when it cannot.

The expenses surface is built around that matching problem, with the unmatched transactions treated as the important ones rather than swept aside.

This is the chapter I would most want a hiring manager to read, because it is the part of AI product design currently being skipped almost everywhere.

Getting a chat panel approved for use on real financial data is mostly a design problem, and it arrives well before the engineering one. The questions are: who is using this, what is it costing, what did it do, what is it allowed to do, and where can people reach it.

I designed a full admin console around those five questions.

Adoption answers "is this worth what we pay for it". It shows 11 of 12 members active, sessions per week trending, and a per department table you can expand to individual people, their session counts, which persona they prefer and which channel they use.

That last column matters more than it looks. If Finance reaches Derek through Telegram and Engineering uses the web app, that is a real signal about where to invest.

There is a personal side too. Individuals get their own surface: session and action history, files shared with the agents, saved commands, the tools the agents may use on their behalf, connected channels.

The two scopes stay on separate surfaces. An admin setting policy for the company and a person managing their own history are doing unrelated jobs, and one settings page holding both would have served each of them badly.

Global search had to span applications, vendors, people, subscriptions and expenses, with results grouped by type and keyboard driven throughout. On a product with this much data, search carries more of the navigation than the sidebar does for anyone who is in it daily.

I use AI tools heavily. Claude Code, Codex, Cursor, Antigravity, and the Figma MCP to move between design and code in both directions. But I want to be precise about what that buys, because there is a lot of noise on the subject.

The decisions in this case study came from understanding the problem and holding a position on it. No model produced the Alternative Applications screen, or the choice to treat unmatched transactions as the important ones rather than the mess to sweep aside, or the argument for modelling switching cost instead of comparing prices.

Where the tooling earns its place is in the distance between an idea and something real. I can take a flow from Figma and have a working prototype the same afternoon, which means testing whether a subscription panel feels manageable rather than arguing about it in a review.

The pricing and billing chapter earlier is the clearest example. Almost everything I know about that state machine, I know because I built a working model of it and then went looking for the states that could not be reached.

That is the actual value: finding the logic problems while they are still cheap to fix.

The link back into the design system is more prosaic than people assume. The colour ramps and the rest of the tokens live as Figma variables, and I export them as JSON for the engineers to work from.

I over-engineered the first subscription panel. The version showing every contract type at once was me demonstrating that I understood the complexity rather than solving it. The redesign put most of it behind a short sequence of questions, which is what I should have drawn first.

I under-invested in empty and error states. They arrived as a late pass rather than being designed alongside the happy path. On a product whose entire premise is incomplete data, the empty state is the more important screen, and it should have been drawn first.

The immediate work is reach rather than more product. Doow solves a problem plenty of finance teams currently solve with a spreadsheet and a bad afternoon, and most of them do not know it exists. Getting it in front of those teams, then watching how they actually use it rather than how we assumed they would, matters more than adding to it. Interfaces that survive contact with real users need sanding down in places nobody predicted, and I would rather spend the next stretch there than on new surface area.

After that, and only after measuring how the current product lands, there is a layer to put on top: banking, payments and accounting. Each of those turns Doow into a system of record rather than a system of insight, which is not a move you make on a hunch. You make it once you know which parts people genuinely rely on, because those are the parts worth building on.