Yes. A product manager can build a working prototype without engineering support, using AI app builders that generate a real backend along with the interface. That means actual user accounts, actual saved data, and actual logic that runs when someone clicks a button, not just an interface that simulates the click. The gap between a PM's Figma prototype and a working proof of concept will have narrowed enough by 2026 that "let me just build it" is a realistic option for a growing set of features, not a stretch.

Why did "prototype without engineering" used to mean "prototype without real functionality"

For most of the last decade, prototyping without engineering had a specific meaning: a Figma file, clickable through a fixed set of screens, standing in for what a feature might look like if someone eventually built it. I spent years getting good at that file. I knew the shortcuts, built a component library I carried between three companies, and could turn a rough idea into a stakeholder-ready mockup in an afternoon.

The problem wasn't the tool. It was what the tool could and couldn't tell you. A clickable prototype tests whether a flow makes sense to someone looking at static screens. It cannot tell you whether the feature works, because nothing in it actually runs. No logic executes. No data gets saved. Every click is on rails, and the rails only go where you built them.

So "prototyping without engineering" quietly became a euphemism for "getting feedback on how something looks, not on how it behaves." Useful for navigation and visual hierarchy. Useless for anything involving state, accounts, or conditional logic, which is most of the interesting product work.

What's changed: from Figma clickthroughs to working prototypes

AI app builders changed the calculation. Instead of describing a feature to an engineer and waiting for a sprint slot, a PM can now generate a working version directly: real authentication, a real database, real logic connecting the two. The output isn't a simulation of the feature. It's a small, rough, genuinely functional version of it.

This matters more than it sounds like it should. A stakeholder looking at a working prototype isn't being asked to imagine how something behaves. They're using it. They hit edge cases you didn't anticipate. They try the thing you specifically didn't design for, which is usually the most useful five minutes of the entire review.

From 2025 to 2026, this shift has moved from novelty to standard practice for PMs at companies with any kind of engineering backlog. The tools generate production-grade code, not throwaway demos, which is a separate claim from saying a PM-built prototype should go to production. It shouldn't. But the underlying quality of what gets built has changed the kind of feedback a PM can gather before engineering is involved at all.

What you can realistically build as a PM with no coding background

I track something obsessively in a spreadsheet: time to first user feedback, measured from the moment I start building to the moment a real person reacts to something real. For years, that number lived around nine days. Spec the feature, brief a designer, wait for the mockup, schedule the review.

Six weeks ago, I needed to test whether users wanted a digest option for notifications instead of real-time alerts. I used Mayson to build a working version myself: a login, a settings toggle that actually saved a preference, and a simulated version of the digest email. It took under an hour, including two false starts on the toggle logic. Mayson's free tier includes 10 credits with no credit card required, which is enough scope for a build this size.

I had reactions from six users within 48 hours. My time-to-feedback for that feature: 2 days, against a 9-day average. Two of the six told me they wanted the digest grouped by category, which wasn't a question I'd thought to ask in the spec. That single piece of feedback reshaped the feature before a single engineer touched it.

Where this fits (and doesn't) in your existing product process

Here's the limitation worth stating plainly: what I built is not production code, and it shouldn't be treated as such. It proved that users wanted grouped digests. It did not solve for email deliverability at scale, notification preference syncing across devices, or how the feature interacts with our existing infrastructure. Engineering still owns all of that, and they should build it their way, not extend what I hacked together in an hour.

Some features don't belong in this workflow at all. Anything performance-sensitive, security-critical, or deeply wired into existing systems needs engineering from the first conversation, not after a PM has built a parallel version. The value of a PM-built prototype is narrow and specific: it answers "do users want this, and how do they actually use it" faster than a spec document can. It doesn't answer "how should this be built?"

How to get a working prototype in front of stakeholders faster

The organisational risk isn't the building. It's how the prototype lands with engineering when they find out about it. "The PM built a thing without telling anyone" reads badly even when the outcome is good, so I've learned to introduce it in a specific way.

I don't present a working prototype as a finished decision. I present it as a research method, just as I'd present a user interview. When I loop in engineering, I lead with what I was trying to learn, not with what I built: "I wanted to know if users cared about grouped digests before I asked you to spec real-time sync work. Here's what six of them said." That framing puts the prototype in service of a question engineering also wants answered, rather than positioning it as a PM doing their job for them.

If your company requires a security review before new tools touch anything real, start that conversation early with a narrow scope: internal use, fake or test data, no production deployment. Most security teams have a fast path for exactly that scope. The version of this that causes friction is the one nobody heard about until it was already in a stakeholder deck.

What to do once your prototype proves the case for engineering time

Once the prototype has done its job, the handoff conversation changes shape. You're not walking in with a hunch and a mockup. You're walking in with what six real users did, which assumption held and which one didn't, and a spec that's already been tested against actual behaviour.

If engineering tells you the working version isn't the right technical approach, that's expected and fine. Your prototype validated what users wanted, not how to build it properly. The two of you are now having a scoping conversation grounded in evidence rather than a guess, which tends to be shorter than one that starts from a Figma file and a hopeful spec.

I have three hours this week to test the next thing on my roadmap, not three days. That's the actual constraint most PMs are working inside, and it's exactly why this shift matters: the question isn't whether you have time to prototype; it's whether you can scope the question tightly enough to get a real answer inside the time you've got.

FAQ

Prachi is a senior product manager at a consumer tech company in Bangalore. She writes about building inside organisations, PM-led prototyping, and the gap between how products get made and how they get talked about.