GPU infrastructure
Two-sided platform
AI-native workflow

PeerShard

A managed GPU placement service in the UK, researched, designed and built as working code with Claude

Year: 2026
Role: Product Designer
Client: PeerShard, UK
Team: Me and Claude; the client's CEO and developer

The task. PeerShard places people's graphics cards in UK data centres and rents them to ML teams. It needed two portals, for owners and for renters, and an answer to whether the client's spec was enough to launch.

What I did. I built the project around Claude Code. Claude read the market, walked every flow and wrote the markup. I set the tasks and rules, decided what mattered and reviewed every page.

The result. Two portals, 100+ screens on one design system, handed to the developer as working HTML and CSS. The spec went into development with its launch blockers named. The product is in development.

Constraints

Code from day oneThe deadline was tight, and the client wanted a frontend built with AI rather than mockups. So I set up Claude Code and went straight to a working prototype in code.
A PHP developer on the other sideThe handoff had to go straight into their work, so it shipped as plain HTML and CSS.
Careful wordingSome financial words were off-limits, so every screen talks about earnings in neutral terms.
Estimates, not promisesIncome shows as an indicative range with a short disclaimer next to it.

The system

An owner hands over a card, a partner inspects it, PeerShard places it in a data centre, rents it to a Compute Partner and pays the owner rental fees.

The owner loses track of the cardThey shipped something valuable to a company they found online. One unexplained status, and they write to support.

The renter pays and can't workA team rents a machine and can't get into it, or loses the disk when the rental ends.

Spec vs market

Claude turned the public docs of RunPod, Vast.ai, Lambda, CoreWeave and Nebius into one table of 73 features, with a "?" wherever there was no data. I picked the rows that matter and checked each one that would change a screen.

	Client's spec	RunPod	Vast.ai	Lambda	CoreWeave	Nebius
Several users per company, roles
Persistent storage
Stop, keeping the disk
Restart a machine
Same-model replacement under SLA
Monthly postpaid invoice
Hard spending cap
Budget with threshold alerts
Features out of 73	38+29	53	45	40	52	58

has itnot in the spec, proposedno

8 of 73 rows. The spec covered 38 features; 29 proposals bring it to 67.

7launch blockers: access, disk, teams, replacement

26questions to NotebookLM about competitor walkthrough videos

1 wordto answer each gap: a proposal came with every question

Research questions

The Compute Partner research didn't start with features. It started with five questions, and every source, screen and finding had to answer one of them.

Q1Who rents, and which roles sit behind one company login?
Q2What is the main job a partner hires the portal for, and what are its steps?
Q3Which outcomes matter to a partner, and how well does the prototype deliver them today?
Q4Which use cases must the portal carry from sign-in to a paid invoice?
Q5What does the interface promise beyond what the client confirmed?

The five research questions.

1. Internal sourcesthe spec, 30 client answers, the demo, the audit, the video review
2. Every page, read in fullall visible text of 34 pages, every state and dialog
3. Market sourcessurveys, reviews, guides, data residency
4. Jobs to be donemain job, an 8-step job map, desired outcomes
5. Use casesactor, goal, trigger, main path by screen, extensions
6. Auditevery job and use case walked through the screens

The method. Claude did the reading and the walkthroughs; I set the questions and judged what each finding meant.

13511

Fact · the prototype itselfHigh · client answers, our plan, the hubMedium · the spec, the demo, market surveysLow–medium · reviewsLow · vendor guides

11 sources, each graded. Reliability is how far a source can be trusted as a spec, not how useful it is.

Insights and hypotheses

10 insights, each with its sources and what it changes on screen. Three of them:

I06“UK only” is asked, never applied→ country on every card, honest empty state

I07Big orders come in nodes, the form takes one card→ card count in the form

I09Running or Active? Three vocabularies→ the interface words become the contract

Compute Partner catalogue on a monitor: every card with its farm and country — The catalogue after the research: every card shows its farm and country. Names and figures on the screens are made up.

What only renters could answer became a hypothesis, each with a check and someone to ask.

H1Partners open the portal for the connect command and the spend so far, not for the catalogue.CheckPage visits on the client's demo, 3 renter interviews

H2A monthly rental that renews without a warning ends in a disputed invoice.CheckSupport tickets about invoices that mention auto-renewal

H3A finance team only needs the invoice PDF in its inbox, with no login.Check2 short interviews with renters' finance teams

H4A team renting a whole node needs a queue or an alert when the model is sold out.CheckBulk requests that left without a match, and what happened next

H5A real share of companies can only use cards hosted in the UK or the EU.Check“UK only” and “UK or EU” answers in the demo sign-up

H6Minimum term and hour rounding are what make a team pick RunPod or Lambda over us.CheckInterview question: “What decided your choice of cloud?”

Six hypotheses to check with renters before they shape a screen.

Jobs and routes

The table shows what's missing, not who gets hurt. So Claude walked every path from sign-up to a paid invoice as three kinds of customer and three roles behind one login.

11sources, each with a reliability grade

5 · 3segments and roles behind one login

20 · 27jobs and use cases against real screens

95problems in one registry, each with a source

20changes proposed to the client

From sources to proposals. 11 problems were already closed by the client's answers.

Client questions

Claude gathered every open question into one list. I set who answers what, and in which order.

All open questionsfrom the hub, the reports, the demo review and open fixes

14to the clientproduct logic, money, law, screens only the client knows

11to me as the designervisuals, copy, micro-UX

2to the project leadpriorities, what the prototype does

61removedanswered, duplicated or ours to decide

One list, four destinations. The client only gets what only the client can answer.

01Newest word winsa fresh answer beats the old spec
02Don't ask what's oursprototype prices and specs stay with us
03Blocking first9 questions, each with one line of why
04A default for every wait“unless you object, we do this”

Work with Claude

Speed came from a setup where Claude could work for hours without me catching the same mistake twice.

Me1. Task and ruleswhat to build, what it must not say
Claude2. Buildmarkup on the shared kit
Checks3. Kit checkstokens, links, boundaries, CI
Claude4. Self-checkskeleton, lint, shots at 3 widths
Me5. Reviewpage by page, one commit each
Client6. Live pageon Vercel, the CEO comments

One screen from task to the client. A failed check stops it before I see it.

CLAUDE.md · rules

2Colour only from a --ps-* token3Sizes in rem, not px4All code in English5Every control is a link or a form before any script runs10One design system: shared parts live in ds/14A screen is looked at first, read second# Banned wordsinvestment · returns · yield · passive income · ROI# The owner never seesthe real identity of a Compute Partner

An excerpt from the rules file Claude reads before every task.

01Skills from my rejectionsblur, greyscale and skeleton checks before I see a screen
02Agents with one jobscout, consolidator, flow walker, report builder
03One screen, one commita rejected screen comes off with one revert

Frontend in code

Figma held the visual system; the product lived in code. Untitled UI adapted through variables (472 of 477 values overridden) became tokens, a CSS kit and Storybook, then the screens. For the client's PHP developer, Claude moved everything from React to plain HTML and CSS.

Storybook with the Buttons page of the kit: primary, secondary, ghost, large, disabled and danger buttons — The system first, the screens second.

Storybook page GPU states: one template renders every state a card can be in — The system first, the screens second.

A variant cost minutes, so the client compared working pages instead of imagining them.

Owner dashboard, variant 1 Fleet first: counters, items that need the owner, money to settle and the farms where the cards are — Five owner dashboards, one hypothesis each. The first and the last of them.

Owner dashboard, variant 5 Dense: six figures in one row, rental fees over time, items that need the owner — Five owner dashboards, one hypothesis each. The first and the last of them.

Owner dashboard on a phone: money to settle and four counters — Every screen at 320, 360, 390 and 430. Here at 390.

A card that did not pass inspection on a phone: what the partner found and what happens next — Every screen at 320, 360, 390 and 430. Here at 390.

Owner portal

A card goes through 30 states. Each one answers: where the card is, who set this status, what happens next, and whether the owner needs to act.

Card page on a desktop monitor: journey, status source and next step — The card page during inspection.

Add GPUs page with three options: buy a GPU, add my own GPU, complete a node — Three ways to add a card and the failure state. After the CEO's “too much text”, the add-a-card flow went from 6,461 to 3,978 words.

A card page after a failed inspection: the finding, the recommendation and who moves next — Three ways to add a card and the failure state. After the CEO's “too much text”, the add-a-card flow went from 6,461 to 3,978 words.

Compute Partner portal

Here research came first: the launch blockers became a rental page with a ready-to-copy connect command, a plain answer about the disk and an invoice that matches the form.

Rental page on a laptop: time left, cost, auto-renew, disk and the connect command — The rental page: connect command, disk rule and cost in one place.

Rent form for an RTX 4090: the card, the image, the disk and the total for 24 hours — The rent form in the order competitors proved, and an invoice that can be checked and paid by bank transfer.

August invoice for a Compute Partner: how to pay by bank transfer, the total and one line per rental — The rent form in the order competitors proved, and an invoice that can be checked and paid by bank transfer.

AI workflow

100+screens in code, two portals, one system

731commits, one screen each, checked before review

95 → 20problems found and changes proposed

Requirements, system logic, review and the call on what ships were mine. Claude did the reading, the walkthroughs and the markup.

Results

Two portals, 100+ screens on one system, handed over as working code. The product is in development.

“Working with Vlad exceeded all my expectations. His exceptional attention to detail and ability to deeply understand the complex technical requirements for PeerShard made a massive difference. He doesn't just design interfaces; he thinks through the system architecture to ensure everything works flawlessly. I am extremely satisfied with the final result and highly recommend him as a top-tier Senior Product Designer.”

James Woodhead, CEO, PeerShard