The Innovation Launchpad That Lets Non-Engineers Build Real Apps

In most software companies, there's a small group of people who can turn ideas into things you can actually see and use. Everyone else has to describe their ideas in words.

Software is one of the few products where the people who imagine it and the people who can make it are usually different people. A chef cooks the meal they imagined. A carpenter builds the chair they designed. A software person writes a ticket and waits.

AI has made building software something anyone with product instincts can do. Once that's true inside your organization, the question isn't whether to give your colleagues the tools to build - it's how.

Over the past year, I've been working with my colleague Eric, CTO at Mapp, on exactly that question. We call the answer an innovation launchpad, and I'm convinced every company should build one.

This is the story of how ours evolved, what it unlocked, and how you can build your own.

What an innovation launchpad actually is

An innovation launchpad is an internal platform where anyone in your company can turn an idea into a working application - without having to know infrastructure, security, or the operational craft that normally guards production systems.

It's not a hackathon sandbox that gets torn down on Monday. It's not a wiki of mock-ups. It's a real product surface, with real authentication, real data, and a clear path from "I had an idea on the train" to "colleagues - and eventually customers - are using it."

Our innovation launchpad grew through two clear phases - and is now entering a third.

Phase 1: The prototyping shell

The first version was almost embarrassingly simple. We took the look and feel of our product - navigation, colors, fonts, the basic page structure - and shipped it as an "empty shell". No data. No real functionality. Just something that looks like the real product and can be opened in a browser.

It was originally meant for product managers to prototype new functionality with AI. To my surprise, within weeks, it had become a popular tool for sharing ideas across the entire business, by people inside and outside of the technology org.

Looks like our product, but technologically has nothing in common.

For the first time, the people closest to our customers - sales, customer success, services - could show instead of describe. A salesperson who had had the same conversation about a missing capability for two years could now demo a clickable version of the answer.

A few choices made the launchpad work:

• It lived completely outside Mapp's infrastructure. We hosted it on a lightweight stack (Netlify and GitHub), but the specific choice doesn't matter - any stack that non-technical people find easy to use will do. The point is that it had nothing to do with production. You don't want the bar for "can I publish this idea?" to be the same as the bar for shipping to customers.
• Enablement was hands-on. Building the shell was only half of it. What actually got people started was a step-by-step video tutorial I recorded, walking semi-technical colleagues through how to use the shell to build their own applications. It turned out to be one of the most critical enablement pieces we had - a lot of people simply watched that video, followed along, and started building because of it.
• It used the real design language. Ideas that look like the actual product get evaluated like the actual product. Wireframes leave too much to imagination; a near-pixel-perfect mock-up ends the debate about whether the thing could exist.
• Feedback was built in. A small in-app widget turned any comment into a GitHub Issue. Once feedback exists as structured tickets, you can assign AI coding agents to them and have fixes and improvements deploy in minutes.

The first launchpad wasn't impressive technology. It was impressive permission. It told the company: your ideas count, and here is where they live.

Phase 2: From click-dummies to real applications

Once people had tasted what it felt like to put their ideas in front of others, the next question was obvious - and uncomfortable: can I make this one real?

Going from a mock-up to a real, API-connected application is a different problem entirely. You suddenly care about authentication, data access, cost, monitoring, security, and a dozen other things that have nothing to do with the idea itself. This is where most internal innovation programs collapse: every new app becomes a months-long infrastructure project, and only engineers can play.

Eric solved this with what I'd call standardized scaffolding. Every application built on the platform automatically inherits:

• Monitoring and observability
• Cost controls and a kill switch
• Authentication and role-based authorization (we started with Microsoft Entra ID and later moved to Keycloak when we needed to support external users too)
• A controlled path to internal systems and product data
• A cost-managed gateway to AI capabilities - we use LiteLLM under the hood

The framework on top is just Next.js - modern enough to build serious things, accessible enough that someone learning to code can get started in a weekend (especially with AI coding agents).

Phase 2 also meant a deliberate infrastructure choice. We moved the platform onto AWS - still outside Mapp's own data center, but flexible enough to scale easily as more people started building. The whole infrastructure is defined as code, and AWS gave us the services we needed to monitor, steer, and manage everything once many hands were building at once. It also helped that AWS was already part of Mapp's infrastructure: we had basic connections between our own data center and services and AWS, so the path was already there and we could build on top of it.

This helped us move from "innovation is allowed" to "innovation is actually possible." When the boring 80% is solved by the platform, what's left is the interesting 20%: the idea.

I want to give Eric credit here. The Phase 1 launchpad was a creative spark - anyone with modern web tooling can ship a clickable shell. Phase 2 is engineering discipline at a level most companies underestimate. Doing it without slowing people down, without compromising security, and without turning the platform into another bureaucracy is genuinely hard. Most of the value of an innovation launchpad lives in the parts users never see.

What it actually unlocks

A few months into Phase 2, the surface area of what was being built had widened in a way none of us predicted. People built tools for things that had quietly annoyed them for years - sharper internal reporting, better onboarding flows for new clients, project trackers tuned to how we actually work, a hackathon companion app, a custom roadmap tool, demo tooling for customer conversations.

My roadmap app is just one example - across the company, people were building their own internal tools on Mapp Labs.

None of these were "big" products. All of them removed friction that, on its own, was never important enough to justify a roadmap slot.

That's the first unlock: the long tail of internal problems finally gets solved. Engineering capacity is finite. An innovation launchpad gives every other function a way to scratch their own itch - supervised by the platform, but not blocked by the roadmap.

The second unlock is more strategic: product-market fit testing without a product team. An idea that looked good on a slide is suddenly in front of colleagues who try it, use it, and react. The ones that earn real usage and feedback get sharpened into something better and prove their worth along the way. The ones nobody reaches for quietly die - and that silence is its own signal: it tells you the thing wasn't actually needed. That's more honest than any survey. The winners become candidates for the real roadmap.

Phase 3: From internal tools to customer-facing apps

Phase 3 is the one we're living through right now, and it blurs a line that used to feel permanent: the boundary between "internal tool" and "customer-facing app" gets thin. Once an internal app proves itself, the question becomes "why don't our customers have this?" With a shared auth system, an app can graduate from internal to external without being rebuilt. That changes the shape of the company. Your product is no longer just the thing the product team ships - it's a platform, and the apps on top of it can come from anywhere.

This is exactly where we are right now with Mapp Labs. We've started exposing capabilities of our real product inside the launchpad, built on the APIs that already exist in our platform. That makes it easy to build Mapp Labs applications that integrate with the real product in a genuinely native way - not bolted on, but speaking the same language as the platform underneath.

The way we've organized this is by documenting each capability as instructions that AI agents can execute, and then building on top of those. That's how we've kept the system modular without turning the simplest use case into a bloated application. It deserves its own blog post - one I'll write once the first Mapp Labs applications built on our real product are out in the open, in the hands of real customers.

The platform alone isn't enough

Without communication structures, the apps ship and then die in obscurity. The company needs rituals for showing and discussing them. This is what worked for us:

• A dedicated prototypes channel in Slack. This was the first thing I established. Anyone shipping anything posts a link there. Colleagues react, comment, suggest, sometimes argue. Feedback arrives within minutes, not sprint cycles. It's the heartbeat of the launchpad - without it, the platform feels empty.
• A weekly demo meeting. I named ours Builders Unscripted. Anyone can show up and walk through whatever they built that week. No slides required, no permission needed. We discuss, react, and - most importantly - get inspired. New ideas are born live, on the spot, because someone saw what was possible.
• A support channel once things get serious. As soon as a few apps crossed from "experiment" into "people actually depend on this," we stood up a dedicated support channel. That keeps the prototype channel playful and gives the serious work its own home.

We layered on a few more things over time, but this is where I'd start: communication, dedicated channels, and one person hosting a weekly meeting where those ideas get demoed. Everything else compounds from there.

And none of it works by mandate. Nobody was forced to build - everything was voluntary. We simply tapped into people's curiosity and their willingness to learn something new, and let that turn into product ideas and solutions. All it took was enablement, guidance, and a little inspiration.

How to build your own innovation launchpad

You don't need our exact stack. You need the pattern. If I were starting again at another company tomorrow, here's the sequence I'd follow:

1. Start with an empty shell of your product. Take your real navigation, real colors, real fonts, and ship a click-through version with nothing behind the buttons. Host it cheaply, outside production. Do this in a week, not a quarter.
2. Open it to everyone, not just PMs. The people closest to customers have the best ideas they haven't been able to express. The shell exists for them.
3. Stand up the communication rituals from day one. A dedicated prototypes channel and a weekly demo meeting hosted by one accountable person. The platform produces output; the rituals turn that output into shared momentum.
4. Wire up feedback as structured tickets. Comments that become GitHub Issues (or your equivalent) become work AI coding agents can pick up immediately. This tight improvement loop is key to rapid innovation.
5. Only then build the real platform. When demand is obvious, invest in the boring 80%: authentication, monitoring, cost controls, kill switches, a default framework. Make it impossible for someone to ship something dangerous, and hard for them to ship something ugly.
6. Treat the design system as part of the platform. Shared components mean every internal app inherits good UX. This matters more than you think - internal apps quietly shape how your colleagues feel about the company they work for.
7. Give it a name and a home. Brand it. Make it a place people are proud to publish to. Ours is called Mapp Labs; yours should have a name that signals "this is where new things live."

A closing thought

The reason every company should do this isn't that it produces more software. It's that it changes who in the company gets to be a builder.

For most of software's history, "I have an idea" and "I can make this idea" lived in different people, and the gap between them was where the best ideas died. An innovation launchpad closes that gap. The engineers still produce the most robust output - that hasn't changed and won't. But everyone else stops being a passenger.

If you're a leader thinking about AI transformation in your company, this is the highest-leverage move I know. Don't start with grand AI strategy decks. Start by giving your colleagues an empty shell of your product and a way to ship into it. The strategy will write itself once you see what they build.

Thanks to Eric for being the engineering brain on the other side of this from day one. Check out his blog at eric.lubow.org.