Case Study: Turning an Internal Tool into a Commercial Product

How we transformed an internal enterprise tool into a market-ready product by clarifying value, reshaping workflows, and aligning strategy, design, and delivery.

True VROOM started its life as a spreadsheet. A complicated, multi-tab, deeply colour-coded spreadsheet that one of the operations leaders at True Digital had built to manage vehicle leasing for the company's fleet. It was an act of pure heroism: the kind of internal artefact that holds an entire business process together, maintained by one person who hopes nobody asks them to take a holiday. Everyone knew the spreadsheet was unsustainable. Everyone also knew it worked, and the cost of replacing it felt enormous.

Two years later, the spreadsheet had become a commercial platform with paying external customers, an award sitting on the shelf, and a P&L of its own. The journey from internal hack to market product is one of the most instructive case studies I've ever been involved in, partly because almost every decision could have gone wrong, and partly because the design choices that mattered most weren't the ones I expected at the start.

The brief we were given vs. the brief we wrote

The original brief was modest. "Build a web app version of the spreadsheet." If we'd taken that brief at face value, we would have shipped a serviceable internal tool, retired the spreadsheet, and called it a quarter. Instead, we spent the first three weeks doing something the brief didn't ask for: interviewing not just internal users, but the customers of those users. The fleet managers who picked up the cars. The drivers who used them. The finance team who reconciled the bills. The dealers who supplied the inventory.

What we found in those interviews completely reframed the project. The spreadsheet wasn't a tool. It was a workflow stitching together five disconnected groups of people who didn't talk to each other. The business value wasn't in digitising the spreadsheet. It was in digitising the workflow. Once you saw it that way, the surface area of the opportunity went from "replace one tool" to "build a platform." That reframing was the single most important decision of the entire project, and it happened before a single screen was designed.

The bet that almost didn't get made

Pitching a platform when you've been asked for a tool is risky. It costs more, takes longer, and gives the CFO an obvious reason to say no. The way we framed the bet was deliberate. We didn't ask for a bigger budget upfront. We asked for the same budget, with a different scope: build the internal tool first, but architect it as a platform from day one. If the internal product worked, we had a clear runway to commercialise. If it didn't, we'd shipped exactly what the brief asked for and learned a lot.

That framing gave the CFO an asymmetric bet: small downside, huge upside. We got approval inside two weeks. The lesson I take from this everywhere I go: when you're proposing more than the brief asked for, never frame it as "more." Frame it as "same investment, more optionality." Executives respond to optionality the way designers respond to a great brief.

The five design decisions that mattered most

Looking back at two years of work, five design decisions stand out as the ones that made the difference between a competent internal tool and a commercial product. None of them are visible in the final UI. All of them shaped everything that is.

1. We built for the workflow, not the role

Most enterprise tools have a screen per role: admin view, manager view, driver view. We built screens per workflow stage, with the same screen showing different controls based on who was looking at it. This sounds like a small architectural choice. It was the foundation of everything else. It meant the platform could absorb a new user type without a new module. It meant handoffs between roles were silent and contextual instead of clunky and explicit. And it meant every new customer that followed, none of whom worked the same way as True Digital, could be onboarded with configuration instead of code.

2. We made the unhappy paths the priority

Most product designers obsess over the happy path. The booking flow. The successful transaction. The smooth onboarding. We deliberately gave equal weight to the unhappy paths from week one: the cancelled lease, the disputed bill, the damaged vehicle, the missing document. Those paths are where customers had been losing time, money, and trust with their old tools. Solving them well was where True VROOM could differentiate. Most of our competitor tools handled them as afterthoughts, often with a phone-call workaround. We made them first-class flows. That's where many of the strongest customer testimonials eventually came from.

3. We designed the data model before the screens

Two weeks were spent in a small room with our lead engineer mapping the data model: entities, relationships, lifecycle states. This was before any UI work began. It felt like a waste of time at the start. It saved us months later. When the second customer asked for a workflow we hadn't anticipated, the data model accommodated it natively. When we wanted to add fleet analytics in year two, the data was already structured to support it. Most of the technical pain on enterprise products comes from data models that calcified before they were thought through. We avoided most of ours by going slow at the beginning.

4. We invested in motion and feedback from day one

Enterprise tools are usually visually flat. They feel like spreadsheets with rounded corners. We deliberately invested in subtle motion, generous feedback, and a sense of liveness: buttons that responded, transitions that explained, empty states that taught. This is not decoration. It's the thing that made the product feel like a place to spend a workday rather than a database to wrestle with. The first time we demoed to an external customer, the motion was the thing they commented on within thirty seconds. They couldn't articulate why the product felt better than what they were using. They just felt it.

5. We built the admin tools as carefully as the customer tools

Most platform companies treat their internal admin tools as second-class: ugly, slow, designed by interns. We built them with the same care as the customer-facing surfaces. This paid back in three ways: our customer support team could resolve issues in half the time, our sales team could demo configurations live in pitches, and our own product team became the most informed users of the platform. Internal admin quality compounds, and most companies discover this far too late.

The commercial pivot, and what made it possible

About fourteen months after launch, the internal product had been live for nearly a year. The decision to commercialise wasn't a sudden one. It was the conclusion of a slow, deliberate process where we'd quietly proven, with a couple of friendly external pilots, that the platform could be configured for organisations that didn't share True Digital's exact workflow. Three choices from day one made this possible: workflow not role, configuration not code, careful data model. Those decisions meant the commercial pivot was a sales and packaging exercise, not a re-engineering one.

Within twelve months of going commercial, the product was generating meaningful external revenue, had won an industry award for innovation in fleet management, and had been positioned as a strategic asset on the company's balance sheet. The original spreadsheet was still in the operations manager's archive, untouched, as a kind of artefact of where it all started.

What I'd tell any team eyeing the same path

If you're inside a company that has an internal tool that's quietly carrying enormous value, here's the playbook in five lines.

1. Spend three weeks understanding the workflow, not the tool. The opportunity is bigger than the brief.
2. Pitch the bet as optionality, not as a bigger budget. Asymmetric upside is what gets approved.
3. Architect for the second customer from day one: workflow over role, configuration over code, careful data modelling.
4. Treat the unhappy paths as first-class. That's where you'll out-compete the incumbent.
5. Invest in motion, feedback, and admin quality. They look like polish; they're actually moats.

Internal-to-commercial pivots are some of the highest-return product moves a company can make, because the original validation has already happened. Your own people are using the thing, and you can see what works. The reason most companies miss it is that the brief always reads "replace the spreadsheet" instead of "build the platform." Your job, as the design lead in the room, is to ask the bigger question. Sometimes the answer is no, and you ship the better tool. Sometimes the answer is yes, and you ship a business. Either way, the question is the part that matters.

In short

Practical checklist

• Separate verifiable outcomes from directional observations.
• Keep customer-value statement explicit in every phase.
• Document key assumptions changed during the pivot.
• Confirm legal and confidentiality boundaries for public sharing.
• Tie lessons to repeatable process, not one-off heroics.

When to use this approach (and when not to)

• Use this approach when decisions carry customer, revenue, or delivery risk.
• Use it when multiple teams need consistent quality standards.
• Use it when you need repeatable outcomes, not one-off output.

• Do not reuse internal metrics or stories externally without clearing confidentiality and attribution.
• Do not imply causation where you only have directional lessons from one programme.
• Do not blend verified outcomes with anecdotal colour without labelling which is which.

Frequently asked questions

What changed most when the internal tool became a product?

The team had to design for repeatable customer value, not internal familiarity. That shifted priorities, workflow decisions, and go-to-market clarity.

What is the main lesson from this case study?

Commercial success requires re-framing assumptions, tightening value narrative, and aligning product decisions with real customer outcomes.

What should readers trust in a case study?

Clear outcomes and timelines, honest attribution of impact (what moved the needle vs what is directional), and boundaries around confidentiality. If those are vague or missing, treat the story as illustration—not proof.

How do we keep case studies credible?

Separate verified results from directional lessons and make assumptions explicit where evidence is partial.

Why include process lessons, not just outcomes?

Process lessons are what other teams can repeat; outcomes alone can look like luck or context-specific success.