Your enterprise has a prototyping problem. Not too little. Too much. Here’s how to channel it.
The Fire Just Got More Fuel
Claude just announced 1 million token context. OpenAI keeps raising limits. Every month, the barrier to building something drops further. And the name of the fire this fuels isn’t “AI adoption.” It’s prototyping.
I’m deliberately not calling this vibe-coding. Vibe-coding is one leg of a much bigger thing. Prototyping is what happens when AI tools get good enough that anyone — not just engineers — can translate an idea into something that works. Product managers are building internal tools. Designers are generating functional front-ends. Business analysts are wiring up data pipelines. The ability to prototype is no longer a technical skill. It’s a social right.
And right now, people in your enterprise are prototyping like rats on cocaine.
I’ve seen it first-hand. Across a large enterprise with hundreds of engineering teams, I watched the prototyping volume go from “a few side projects” to “we genuinely don’t know how many AI-powered tools people have built” in under a year. Not because anyone approved it. Because the tools got good enough and the problems were obvious enough that people just… started building.
The Two Choices (Both Wrong)
As an enterprise, you’re staring at this and you have two instincts. Both are bad.
Choice 1: “If I don’t look, it’s not there.”
The Ostrich. Head in the sand. Let people do whatever they want. Meanwhile, someone in a corner of your organisation has already solved a million-dollar problem and can’t ship it because the PO told them the Jira ticket is the priority. Someone else, knowingly or unknowingly, just published confidential customer data to a public API because the prototype needed “real data to feel real.”
You didn’t see it. So it didn’t happen. Until it did.
Choice 2: “I see you. All of you. All the time.”
The Empire. Lock it down. Approved tools lists. Usage policies. Mandatory reviews. Kill every unsanctioned experiment before the ideas even seed. Congratulations — you’ve eliminated the security risk and the innovation at the same time. The Force is strong with governance, but the Rebellion has better ideas.
I watched an organisation do exactly this. They sent a company-wide email banning all “unapproved AI tool usage.” Within a week, the same engineers were using the same tools — they’d just stopped talking about it. The prototyping didn’t stop. The visibility did.
The Third Way
Is there a path where you channel this energy instead of ignoring it or crushing it? Where you turn contained chaos into enterprise value?
Yes. But before you say “you’re a genius” — let’s make sure you actually need this. Let’s look at what you’ve probably already tried, and why it didn’t work.
What You’ve Already Done (And Why It Didn’t Work)
Hackathons.
Every enterprise’s first move. Put people in a room for a day, high adrenaline, end-of-day presentations, a few standouts, investment promises from leadership, applause.
Next morning: new dawn, new day, back to the same work.
Hackathons are top-down events dressed up as bottom-up innovation. Most organisations run them for AI adoption and awareness, not for sustained value creation. They reward speed over substance. They produce demos, not products. And there’s no path from “you won the hackathon” to “here’s a team and a budget.” Winning means a trophy, not traction.
The Death Star looked impressive too. Didn’t survive contact with a thermal exhaust port.
Announcements and policies.
“Please be careful using unauthorised AI tools. Here are our data protection policies.” Sent via email. Nobody reads it. The people who need it most are the ones who’ve already found their own tools and aren’t looking at their inbox for permission.
AI awareness events.
Expensive. Low retention. The people who attend are already interested. The people who need it don’t show up. I sat through one that cost more than a junior developer’s annual salary. Three months later, I asked ten people what they remembered from it. Nobody could name a single takeaway.
AI governance and adoption teams.
They exist somewhere in your org chart. Most people don’t know where. These teams do important work — tooling evaluation, risk assessment, vendor management — but they operate in the background. They’re not connected to the people actually building things. I once asked a developer if they knew their company had an AI governance team. “We have a what?”
None of these are wrong. They’re just incomplete. They address pieces of the problem but none of them answer the real question: how do you systematically absorb the prototyping energy and turn it into value?
The Prototyping Operating Model
Here’s the model. Three parts: the system, the team, and the infrastructure.
Part 1: The System
A rolling submission model with quarterly selection.
Not a one-day event. Not “submit your ideas by Friday.” A continuous, open pipeline where people prototype at their own pace and submit when they’re ready.
Why rolling? Because good ideas don’t arrive on schedule. The engineer who cracks a problem at 2am on a Tuesday shouldn’t have to wait for the next hackathon to show anyone. And people should be able to submit as many ideas as they want — the evaluation process filters, not the submission process.
The submission rule: prototypes only.
This is the critical filter. And it’s inspired by something Jeff Bezos understood early: the best way to evaluate an idea isn’t to read a pitch deck about it — it’s to use it.
Submissions are not ideas. If it’s just a sketch on a napkin, it’s too early — go build it first. Submissions are also not deployed projects. If it’s already running in production, you’ve skipped the process entirely and we need a different conversation.
A submission is a prototype: an idea translated to a minimum working level. It runs. It demonstrates the concept. It’s rough. That’s fine. But it exists.
What a submission looks like:
Every submission is a pull request. The PR description follows a standardised template:
# Prototype Submission
> **Submission Title:** AI-Powered Inventory Alert System
> **Submitter:** Alex Chen / @achen
> **Date:** 2026-02-14
> **Category:** ai-ml
## Problem Statement
Our regional warehouse network (12 locations) relies on manual stock checks
and static reorder thresholds to manage inventory across 8,400 SKUs.
Warehouse coordinators spend 2-3 hours daily reviewing spreadsheets and ERP
dashboards to identify items approaching stockout.
## Dollar Value Framing
- **Value type:** Cost saving
- **Estimate:** $680,000/year
- Stockout reduction: 340 events/quarter x 60% reduction x $320 avg
emergency freight premium = $261,120/year
- Labor savings: 12 coordinators x 1.5 hrs/day saved x 250 days x
$48/hr = $216,000/year
- **Confidence level:** Medium
## Working Prototype
- **Link:** github.com/achen/inventory-alert
- **Tech stack:** Python, scikit-learn, PostgreSQL, Slack SDK, Streamlit
- **How to run it:** `docker compose up` → load data → train → dashboard
## Effort So Far
- **Time invested:** ~60 hours over 5 weekends
- **People involved:** Alex Chen (ML), Dana Torres (warehouse ops, domain)
- **What was hardest:** Demand signal for promotional periods — model
treated promo spikes as anomalies, not patterns.
## What's Needed to Graduate
- **Team size:** 2 engineers + 1 ops lead for 3 months
- **Budget:** ~$85,000
- **Key risks:** ERP API access may require 6-8 week security review
Notice the structure. Dollar value framing forces people to think about whether the problem is worth solving before they submit. Effort transparency shows skin in the game. Graduation requirements keep expectations realistic. This isn’t a wish list — it’s an engineering proposal.
Quarterly evaluation and selection.
Every quarter, the organising team reviews all submissions from that cycle. Each submission gets scored against five criteria:
| Criterion |
Score |
What It Measures |
| Business Value |
/5 |
Real problem? Credible dollar framing? |
| Technical Feasibility |
/5 |
Can this actually reach production? |
| Resource Efficiency |
/5 |
Lean ask relative to value? |
| Strategic Alignment |
/5 |
Fits org priorities? |
| Innovation Factor |
/5 |
Novel approach or new-to-us? |
| Total |
/25 |
|
The scoring isn’t a beauty contest. It’s a structured way to compare apples to oranges — an ML inventory system against a meeting decision recorder against a compliance automation tool. Every evaluator fills in the same template. Comments are mandatory. The numbers create ranking; the comments create accountability.
From the scores, they select:
-
Top 5 to reward — public recognition, small prizes, visibility to leadership
-
Top 15 to invest — dedicated time, resources, or team allocation for the next cycle
The rest get documented feedback. Every submission gets a response. No idea goes into a void.
Graduation paths:
Every selected prototype gets one of four outcomes:
-
Graduate — fund it, staff it, put it on a product roadmap. It’s real now.
-
Iterate — promising but not ready. Gets another cycle with more support.
-
Shelve — valuable concept, wrong timing. Archived with documentation. Can be resurrected.
-
Kill — learned what we needed. Thank the team, archive the code, close the loop.
Every decision gets a graduation record:
# Graduation Decision
> **Submission:** AI-Powered Inventory Alert System
> **Cycle:** Q1-2026
> **Evaluation Score:** 21/25 (ranked 3rd of 42 submissions)
## Outcome: GRADUATE
Fund it, staff it, integrate into product roadmap.
## Reasoning
Strong dollar value framing backed by real backtesting data (78% of
stockout events flagged with 5-day lead time). Low resource ask relative
to projected $680K/year savings. Warehouse ops champion already lined up.
Primary risk (ERP API access) is a known 6-week process, not a blocker.
## Next Steps
- [ ] Assign product owner: Maria Gonzalez
- [ ] Allocate team: 2 engineers + 1 ops lead, 3 months
- [ ] Schedule kickoff by 2026-04-01
- [ ] Define MVP scope: pilot at 2 locations
The key: every path has closure. People know what happened and why. No prototype enters zombie state — alive enough to haunt you, dead enough to not ship.
Part 2: The Operating Team
Two groups make this work: a leadership team and an organising team.
The leadership team has one job: investment authority. They review the organising team’s recommendations, make funding decisions, and connect graduated prototypes to product roadmaps. They don’t evaluate submissions — that’s the organising team’s job. They make it possible for good ideas to actually become real things.
What they should do:
- Take time to understand what people are trying to solve, not just what they built
- Attend demo sessions, ask questions, show genuine interest
- Move fast on graduation decisions — momentum kills if you wait too long
What they should not do:
- Treat this as a checkbox exercise — people can tell when leadership is performing interest versus showing it
- Sit on graduation decisions for weeks — the engineer who built the prototype on their weekends deserves a timely answer
The organising team is the engine. These aren’t managers. These are your rockstars — the people who are already respected across the organisation. A cross-functional mix: product, UX, engineering, data, security. They understand both the technical and the business side.
Think of them as the Jedi Council — except one that actually listens to people instead of dismissing Anakin’s concerns. The job is curation, not gatekeeping.
What they should do:
- Review submissions with open minds — the best ideas often look weird at first
- Group similar submissions together — if five people independently prototyped something similar, that’s a signal about a real problem, not a coincidence. Pay attention to that.
- Connect people working on adjacent problems — facilitate the conversations that wouldn’t happen organically
- Look for patterns in what’s being built — the aggregate tells you more than any individual submission
- Build tooling that helps people prototype faster — shared components, design systems, API templates, even AI-powered extensions for common patterns
- Maintain transparency — everyone can see what’s been submitted, what’s been selected, and why
What they should not do:
- Gate-keep based on role or seniority — a business analyst’s prototype is as valid as a staff engineer’s
- Reject ideas for being “too simple” — simple solutions to real problems are the most valuable kind
Part 3: The Infrastructure (It’s a GitHub Repo)
This is where I might sound opinionated, but hear me out.
You don’t need a platform. You don’t need a multi-tenant app with versioning, workflows, approval chains, and a React dashboard. You need a GitHub repository.
I know what you’re thinking: “GitHub? For managing enterprise innovation?” Yes. And here’s why.
The instinct is to build a tool first. A submissions portal. A review dashboard. An analytics layer. Three months and $200K later, you have a beautiful platform and zero submissions because nobody wants to learn another internal tool. I’ve seen this happen twice. Both times, the platform outlived the programme.
Git + GitHub gives you almost everything:
prototype-ops/
├── templates/
│ ├── submission-template.md # What submitters fill in (the PR)
│ ├── evaluation-template.md # How reviewers score (per submission)
│ └── graduation-template.md # Decision record (graduate/iterate/shelve/kill)
├── submissions/ # One branch per submission, merged PRs = archive
├── examples/
│ ├── example-submission-1.md # AI-Powered Inventory Alert System
│ ├── example-submission-2.md # Meeting Decision Recorder
│ └── example-submission-3.md # Compliance Doc Generator
├── docs/
│ ├── guidelines.md # Do's and don'ts, approved tools
│ ├── ai-tools-guide.md # What AI tools the company offers + how to use
│ ├── problem-framing.md # How to think about dollar value and effort
│ └── reference-problems.md # Org-level problems leadership wants solved
└── dashboard/ # Simple UI to visualise submissions
-
Submissions are pull requests. The prototype code lives in the PR. The description follows the submission template. Discussion happens in comments.
-
Decisions are recorded. Approved, rejected, needs iteration — it’s all in the PR history. Reviewers’ reasoning is captured.
-
Everything is in one place. No context-switching between a submissions portal, a Slack channel, an email thread, and a spreadsheet.
-
Transparency is built in. Anyone can browse open PRs to see what’s been submitted. No duplicate ideas because you can search before you submit.
-
Governance is native. Branch protection, required reviewers, templates — GitHub already has the workflow primitives.
The docs/ directory does the heavy lifting that policy emails never could. guidelines.md tells people what tools they can and can’t use — which naturally educates about shadow AI without a single compliance slide. ai-tools-guide.md shows people the power of tools the company already pays for — reducing the incentive to go rogue. problem-framing.md teaches people to think about dollar value and effort before they build — the best filter is self-filtering. reference-problems.md gives direction without being prescriptive: “here are problems leadership wants solved, if you’re looking for inspiration.”
And yes — you can add AI-powered extensions to the repo that automate submission review, evaluation grouping, status tracking, and reporting. The organising team doesn’t spend their time on mechanics. They spend it on judgment.
I’ve built a starter repo that any organisation can fork to bootstrap their prototyping operating model. It includes the submission templates, evaluation workflows, team manifest, and example submissions.
prototype-ops on GitHub — fork it, adapt the templates to your org, and you’re running by next quarter.
Why This Works (When Everything Else Didn’t)
The hackathon failed because it was an event. This is a system.
The governance policies failed because they said “don’t.” This says “do — but here.”
The awareness events failed because they were broadcasts. This is a conversation.
The AI adoption teams failed because they were invisible. This is visible by design — every submission, every decision, every outcome is public within the organisation.
And shadow AI? It doesn’t disappear. But it surfaces. When people have a legitimate channel for their prototyping energy — with clear guidelines, approved tools, and a path to recognition — the incentive to operate in the shadows drops dramatically. Not because you banned it. Because you made the alternative better.
Like the Rebel Alliance, you don’t win by building a bigger Death Star. You win by giving people something worth fighting for. A system that recognises their ideas, resources the good ones, and doesn’t waste their time with the rest. That’s the Prototyping Operating Model.
One Takeaway
Your people are already prototyping. They’re doing it on lunch breaks, on weekends, in the gaps between sprint tickets. The question isn’t whether to allow it. The question is whether you channel it into a system that creates value — or ignore it until someone publishes your customer data to a public repo.
Build the operating model. Stand up the team. Fork the repo. Start this quarter.
The dinosaurs are already out. The fence is already down. The only question left is whether you build Jurassic World with better containment — or keep pretending the park is still under control.
If your enterprise is drowning in unsanctioned prototypes — or worse, pretending they don’t exist — I’d like to hear how you’re handling it. What’s working? What spectacularly isn’t? And if you’ve tried hackathons and they didn’t stick, you already know why.
