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
Once designers can build working software, they do. That is the point of teaching them. 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.
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.
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.
Four yes means go. One no triggers escalation.
Check all four gates
Answer each one honestly. They are deliberately blunt.
Is it independent of anyone else?
Yes meansNo colleague needs to plan their day around it.
Does it avoid real company or customer data?
Yes meansIt uses only made-up, non-sensitive demo data.
Can it be thrown away after use?
Yes meansIt does not need to survive changes, updates or patches.
Can you own it entirely yourself?
Yes meansNo 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.
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.
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.
Write the problem
Who is blocked, how often, and what it costs today.
Check the line
Size the ownership, the operating cost, and the recommendation.
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.
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.
