Can I build this?

Where a designer's tool stops being a prototype

Role: AI Lead, framework author
Audience: Designers, design leadership, IT
Output: Four gates, one decision, one escalation path

Context

Once designers can build working software, they do. The problem arrives the week after: a tool a colleague now depends on, holding real data, that nobody owns and nobody can hand over.

The reflex is to gate everything through approval, which kills the capability we had just built. The opposite reflex is to let it run, which quietly creates infrastructure nobody signed up to maintain. Neither is a position you can defend to IT or to a designer.

So I wrote the line down instead. Not a policy, a decision the designer can make alone in under a minute, and a clear path for what happens when the answer is no.

Designer role

Prototypes, POC, innovation concepts

Disposable by design
No real company data, no users beyond the test session
Blast radius of a failure: one person, zero consequences

OutputValidated insights, realistic user testing, stronger PRDs.

The line

Developer role

Internal tools

Testing, security review, backups, monitoring
An owner: maintained, auditable, transferable when people move
Blast radius of a failure: the whole team, and company data

OutputTools the studio can actually depend on.

The boundary is not about talent. It is about who is accountable when it breaks.

The rule

Four yes means go. One no triggers escalation.

Check all four gates

Answer each one honestly. They are deliberately blunt.

01 · Dependency

Is it independent of anyone else?

Yes means

No colleague needs to plan their day around it.

02 · Data

Does it avoid real company or customer data?

Yes means

It uses only made-up, non-sensitive demo data.

03 · Durability

Can it be thrown away after use?

Yes means

It does not need to survive changes, updates or patches.

04 · Ownership

Can you own it entirely yourself?

Yes means

No one else needs to verify, fix or take it over.

The four are not arbitrary. Each one names a cost that lands on somebody else: a colleague's time, a security review, a maintenance burden, an owner who has to answer for it. If none of those costs exist, there is nothing to approve.

Make the call

Two outcomes, no middle ground, no committee.

Go All four answers are yes

Build it.

It's yours to explore.

Prototype or proof of concept
No real data, accounts or keys
No intake, approval or ticket
No users beyond the test session
Share freely without growing a problem
Nothing to maintain or hand over

Go fast. Go alone.

Stop Any one answer is no

Escalate it.

This crosses the line.

It is a tool, not a prototype
It needs an accountable owner
It needs tests someone can actually read
It needs security and privacy review
It needs backups, monitoring, an on-call path
Handover is the requirement, not the code

Don't build it quietly.

Escalate does not mean stop working. It means the thing you built has become an organisational asset, and pretending otherwise is how a prototype turns into something a team silently depends on with no owner and no way back.

Run the leadership response

Three roles, in order. The answer comes back as a decision, not a queue.

01 · Design

Write the problem

Who is blocked, how often, and what it costs today.

02 · AI Leader

Check the line

Size the ownership, the operating cost, and the recommendation.

03 · Leadership

Make the call

Approve, decline, or redirect the accountable investment.

The middle seat is mine. It exists because the two ends of this chain cannot size the question on their own: a designer rarely knows what running something costs over a year, and leadership should not have to read code to find out. Sizing ownership and operating cost is the work that makes the decision possible.

The order matters as much as the roles. Starting with the problem rather than the tool is what stops the conversation becoming a discussion about whether to allow AI, which is not a question anyone can answer.

Real case

A tool for UI copy

A designer built a tool that moves UI copy out of the design files and drafts new strings with a model. It removed hours of copy and paste, and it is exactly the kind of tool designers now build for themselves.

Built by: A designer in the studio
Context: A global design studio
Outcome: Escalated

01 · Dependency
Designers in studios around the world need this copy, and cannot depend on a tool maintained by a single designer.
No
02 · Data
The copy is potentially sensitive data, and information security cannot be left in the hands of a designer.
No
03 · Durability
It has to follow every change in the files and the copy pipeline.
No
04 · Ownership
A maintained tool already exists. It may not answer this use case, but professionals maintain it. This one only accumulates technical debt.
No

Four no. One was enough to escalate.

Same tool, small studio

In a studio of a few designers, it could be a reasonable call. Everyone using it sits within earshot of the person who built it, the copy belongs to a handful of projects everyone knows, and when it breaks, the cost is an afternoon.

Nothing about the tool changed. The organisation around it did.

That is why the gates ask about other people rather than about the code. In a small studio, the people who pay for a broken tool are the people who chose it. In a global studio, they are teams who never knew it existed.

Escalating does not kill the idea. It turns a designer's shortcut into a problem statement the owners of the copy can act on, with the cost of running it on the table.

Framework, gates and escalation path written by me, and presented to design leadership.

Internal specifics have been left out of this page. Happy to go deeper in conversation.