Doow

Ask a finance lead at a 500 person company what they spend on software a year and you will get a number. Ask how confident they are in it and the number goes soft.

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 tells you the application exists. Card data tells you a charge cleared. Neither tells you what you agreed to pay, on what terms, until when. 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. A homepage tells you what a company wishes it were. The documentation tells you what they actually shipped, what their data model can and cannot express, and which edge cases generate enough support tickets to have earned their own page.

Desk research tells you what exists. It does not tell you 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. What people currently do badly is evidence. What they say about a product that does not exist yet mostly is not.

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. The pain people described was not "I cannot see my spend". It was "I cannot trust the number, and I find out too late". Those need different products, and we were now confident about which one 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.

So the job was not "make the screens look good". The job was closer to: work out what the product actually is, screen by screen, alongside the founders and engineers, and then build 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. "Add Subscription" versus "Add Plan" is not a wording preference, it is a statement about 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. Every other SaaS management tool will tell you what you spent. Showing what you got for it beside the number is what makes someone act.

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.

Doow discovers applications automatically, and automatic discovery is never complete. It can find that you pay for Slack without knowing who owns Slack internally, which subscription the charge belongs to, or which of your 456 people the licences map to.

The instinct is to hide that. Show the clean rows, ignore the messy ones, keep the product looking confident.

I argued for the opposite. Needs Attention is a working queue made of exactly the gaps. Every row is an application missing something, and every missing thing is an inline action: Add Subscription, Add Plan, Map Users, Add Manager.

The principle underneath reaches further than one screen. A product that admits what it does not know is more trustworthy than one projecting confidence it has not earned.

This is the cheap version of that argument, because here the unknown is a missing field, and a missing field is easy to draw. It gets much harder later, when the thing that might be wrong is not a blank cell but an answer an AI agent has already written up, formatted and handed to you.

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.

Switching cost is real and nobody models it. So this view answers the question a finance lead actually has, which is not "what is cheaper" but "what would this cost me all in, and what would I lose?"

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.

Everything in the last chapter assumes the answer coming back is correct. Sometimes it is not.

That is not a defect you can engineer away, it is a property of the thing. Any system that reads a contract and tells you the renewal date will occasionally be wrong about the renewal date. So the question is not how to stop it. It is what the product does about it, and who finds out.

The first answer is the least clever one. It sits under the chat box everywhere the agents appear: Derek and Mina are AI agents and can make mistakes. Please double check responses.

A permanent disclaimer is an admission, and there is a school of design that treats admissions as weakness. But the alternative is an interface projecting total confidence about a contract it parsed at three in the morning, and the first time that costs somebody a renewal date you have lost them for good.

So it stays. Same place, same quiet voice, every time, not a modal you dismiss once. Its job is to set the reading posture before the first answer arrives rather than apologise after a bad one.

The second answer has teeth. Every action needing a human goes through an approval dialog in the chat itself, at the moment the agent proposes it.

That placement is the point. The approval does not go to an inbox, a notification centre, or a queue somebody reviews on Friday. It appears inside the conversation that produced it, with the working still on screen above. You are approving something you can still see the reasoning for, which is the difference between review and rubber stamping.

The third answer is that what counts as needing approval was not mine to decide. An admin configures it once for the organisation, in the policies surface of the governance console.

A twelve person startup and a company with a real finance function do not agree about which actions are routine, and a product that hardcodes an answer is wrong for one of them. The job is to make the boundary configurable and legible, not to hold an opinion about where it sits.

There is a quieter failure worth designing for too, which is the agent stopping because the money ran out. Usage above your allowance draws against a prepaid balance, and when that balance is close to gone the product says so before a conversation dies halfway through an answer rather than after.

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.

Shipping a chat panel is easy now. Shipping one a CFO will approve for use on real financial data is a different problem, and a design problem before an 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.

Admins govern the organisation. Individuals govern themselves. Collapsing those into one settings page would have made both worse.

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 is not a convenience feature, it is the primary navigation for anyone who uses 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.

It does not design for me. The Alternative Applications screen, making Needs Attention a working queue, the argument for modelling switching cost rather than comparing prices: none of those came from a model. They came from understanding the problem and having a position on it.

What it does is collapse 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. Not faster pixels. 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.

That is a handoff, not a live sync. It is correct at the moment I export it and not afterwards, so keeping design and code in step is something a person remembers rather than something a pipeline guarantees. It holds at this size, and would not at three times the team.

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. Understanding complexity and exposing complexity are different skills, and only one of them is design.

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 not more product, it is reach. 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.