Groundwork Shipped 2025

Every team wanted AI. Nobody could see what it cost, or which prompt actually worked

Groundwork is the platform a company's teams build AI apps on: one place to get access to models, write and test prompts, and see what it all costs. This case study follows a prompt from the playground into production.

Role: Product Designer (sole designer)
Timeline: Month to Month 2025
Team: N engineers, 1 PM, me
Skills: Platform design, Information architecture, Data visualisation, Design systems

My role

So my job was to give every AI app one approved way in, with its cost in plain view.

I designed the platform end to end: app onboarding and approvals, the model library, the prompt library, the playground and compare, and the analytics pages.

Problem: Each team wired up AI on its own, with its own keys and prompts kept in documents, and nobody could see the total cost.
What I did: Designed one platform where teams register apps, pick a tier, test prompts side by side and save the winner, while admins approve and finance sees the cost.
Result: Built so every AI app comes through one approved door, and its cost lands on the team that spends it.

Client work, shown with a new name, made-up data and a new visual identity. Views are my own.

Problem

Every team was building with AI on its own…

Each team got its own keys, kept prompts in documents and chat threads, and asked for access over email. Admins couldn't tell who used which model, and finance couldn't tell which team spent what.

…but nobody had the full picture: not the admins, and not finance.

The risks were spend nobody could trace, the same prompt written again in every team, and no single place to enforce safety checks like PII detection and prompt-injection screening.

Who it’s for

App teamsRegister an app, pick a tier, and test prompts before they ship.
Platform adminsApprove apps, manage models and keep endpoints healthy.
FinanceSee what each app costs, and charge it to the right business unit.

What had to change

From keys in email threads to one approved way in.

Before: Each team got its own keys and asked for access by email
After: Apps register, pick a tier and wait in one approval queue
Before: Prompts lived in documents and chat threads
After: The winning setup is saved to a shared prompt library
Before: Admins couldn’t tell who used which model
After: Every endpoint shows its configuration, provider and traffic
Before: Nobody could say which team spent what
After: Cost by app, model and team, charged to the business unit

Discovery

Who is the platform really for?

Three groups use the platform, and each needs a different answer from the same data.

Builders want access and a place to test. Admins want a queue they can clear. Finance wants cost per app and per team. Add how you learned this: interviews, tickets, workshops.

Providers: Several model providers behind one front door, each with its own configuration and limits.
Cost: Every token is charged back to a business unit through an internal cross-charge.
Governance: Every app goes through approval, and its tier sets its quotas, support and available models.

Core idea

Every test in the playground turns the same three dials.

Compare runs one user prompt through up to three setups side by side, and the one that wins is saved whole, with its version and variables.

The setup formula

System promptModelParametersA setup

System prompt: The instructions and variables the app sends every time.
Model: Which provider and version answers the prompt.
Parameters: Settings like temperature that shape how it answers.
A setup: Tested side by side, then saved to the prompt library.

Exploration

The first compare view tested one prompt at a time. Side by side won.

The earlier compare view: one prompt with its response, and two empty slots asking you to add a comparison — Before: one prompt, then empty slots

Dropped: One at a time

Run a prompt, then add each comparison in an empty slot.

Why not: Every comparison started from an empty slot, so testing three setups meant building each one by hand before seeing any difference.

Compare view: one user prompt run against three prompt setups, each with its model, parameters and response — After: three setups side by side

Chosen: Side by side

One user prompt, up to three setups, each with its own export to the library.

Why it won: Differences between setups show at a glance, and the winner goes to the library in one step.

Along the way

The theme and the compare view each went through a few rounds.

01
Four themes for one page
The cost page, tried in four themes: two violets, a teal and an orange.
02
A history of past comparisons
An earlier compare view kept past comparisons in a side panel, next to the setups and the app’s credit balance.

Decisions

Three calls shaped the platform.

Decision 1: Testing and saving are one flow
Compare runs one user prompt across up to three setups (prompt, model and parameters) side by side. The setup that wins goes straight into the prompt library with its version and variables, so nothing is copied by hand. The cost: three columns of output is a dense screen on a laptop, so each column keeps only the essentials.
Decision 2: Show the cost where the decision is made
The playground shows the credit balance of the app being billed, and the tier picker shows quotas and models before a team commits. People see the price while they can still change course, not in a report a month later.
Credit balance, inside the playground
Decision 3: Approvals are a queue, not an inbox
Requests sit in tabs by status (all, approved, pending, rejected), with the tier, models and environment on each row. Rejecting needs a comment, so a team always learns why and what to change.
The app request queue

Solution

A team can get access, find the right prompt and ship it, while admins and finance see the same picture.

Here is the playground where prompts are tested, then the pages admins and finance work from.

End to end

How an app gets from an idea to production.

1
Register the appEach app is onboarded once, with the business unit its cost goes to.
2
Pick a tierToken quotas, support hours, retrieval and models, compared up front.
3
Get approvedAdmins approve or reject from one queue, with a comment.
4
Test and saveCompare setups on one prompt, with the credit balance in view.
5
Run in productionAdmins watch endpoint health, traffic and safety checks.

Prompt playground: session history, the system prompt, the conversation, and a side panel with credit balance and settings — The prompt playground

1History of every playground session, so a good run is never lost.
2The system prompt, editable in place, with variables for the parts that change.
3The conversation, with actions to copy or edit each message.
4Credit balance for the app being billed, with its index, tuning and variables.

Model library

Each endpoint shows where its traffic goes

An endpoint lists its active configuration, provider and traffic split, so admins can move traffic between model versions and see the result in one place.

Model endpoint page: ready status, invocation URL, and two configurations each taking half the traffic — A model endpoint and its configuration

Analytics

Cost by app, model and team

Cost over time and by internal cross-charge, with averages per app, per model and per token. Finance can trace a spike to the app behind it.

Cost analytics: total cost and averages per app, model, retrieval and token, cost over time, and cost by cross-charge — Cost analytics

Governance

Safety checks, reported across every app

Ethics and compliance analytics count what the guardrails caught (personal data, prompt injection, unsafe content) per app, so admins see risk across the platform instead of app by app.

Ethics and compliance analytics: compliant requests, policy violations, harmful content, jailbreak attempts and personal data detected, by category and by app — Ethics and compliance analytics

More screens

Around the playground

Model leaderboard: provider, modality, context window, latency, cost, toxicity and personal-data detection — Comparing models on latency, cost and safety

My RAG apps: versions of each index with billing status, sync status and actions — Retrieval apps and their indexes

API health analytics: endpoints monitored and down, lowest latency, and health by region — API health by region and environment

Outcome

Built so AI spend has an owner and good prompts get reused.

These are the effects the design was built for, not measured results. Next to each is the signal that would show it.

One approved way in for every AI app
What would show it: Apps onboarded through Groundwork, against model keys requested outside it.
Cost lands on the team that spends it
What would show it: Share of AI spend tagged to a business unit through cross-charge.
Prompts get reused instead of rewritten
What would show it: Prompts saved to the library and used by more than one app.

Reflection

What did I learn?

A platform has three audiences reading the same numbers. Designing around one shared object, the app, with its tier, prompts and cost attached, kept builders, admins and finance talking about the same thing.

What would I change?

I'd bring the safety checks into the playground itself, so builders see them while they test, not only in the compliance analytics afterwards.

Next case study

Logic.dev