Skip to main content
Most prototypes are built to test user reactions. Feasibility prototypes are different - they’re built to test whether the engineers can pull something off 🔧 A feasibility prototype isn’t shown to customers. It’s an internal technical spike: rough, throwaway code written specifically to answer one question - “can we actually build this?” - before the team commits to building it properly.

​
When you need one

Not every feature needs a feasibility prototype. Simple CRUD features, familiar UI patterns, standard integrations - these don’t need proving out. You know they’re buildable. Feasibility prototypes earn their keep when there’s genuine technical uncertainty:
  • A new integration with a third-party API you’ve never used
  • A performance requirement that pushes the boundaries of your current stack
  • An AI or ML feature where you’re not sure the model will produce useful output
  • Real-time functionality on infrastructure designed for batch processing
  • A novel interaction pattern that may not be achievable in your framework
If an engineer says “I think we can do this, but I’m not sure” - that’s a signal to spike before you plan.

​
What it looks like

A feasibility prototype is typically a few days of focused engineering work. No design, no polish, no tests. Just enough code to prove or disprove the core technical assumption. The output isn’t a feature. It’s a confidence level: yes we can build this, yes but it will take three times longer than we thought, or no, the API doesn’t support what we need 🚦 That confidence level changes the product decision. Maybe the solution needs to change. Maybe the scope needs to shrink. Maybe you need a different technical approach entirely. Better to know now than after two sprints.

​
The spike vs. the prototype

In agile terminology this is often called a spike - a time-boxed investigation to reduce uncertainty. The terms are interchangeable in practice. What matters is the discipline: set a clear question, set a time box, return with an answer. See also feasibility testing for the broader discovery practice of validating technical assumptions - feasibility prototyping is the hands-on implementation of that.

​
Involving engineers early

Feasibility prototypes only happen if engineers are in the room during discovery - which is exactly why the product trio model matters. When engineers hear about a proposed solution in a customer interview, they naturally start asking “can we build that?” A feasibility spike is how they answer it 💡 Lesson learned: the most expensive feasibility discoveries are the ones made three weeks into a sprint when someone finally tries to connect to the API and finds out it doesn’t do what the docs said 😬 Spike early. Spike cheap.