How to Do Rapid Prototyping for Real
The CEO of GE Ventures, Sue Siegel said, “Failing fast without losing a customer is better than spending three hundred million dollars on a project that you take all the way out for a year or two.”
The philosophy of “failing fast” (or, more optimistically, “confirming your idea is really good fast — and you’re a total genius”) is catching on with everyone creating apps, from early-stage startups to Fortune 500 enterprises. It’s kind of a no-brainer. Who doesn’t want to make sure they’re building things their users will actually use?
Everyone’s doing rapid prototyping, right?
But if you’ve ever been a part of the product development process, you know real rapid prototyping can be a pipe dream. It comes down to time, money, and culture. Most “rapid prototyping” projects don’t get the kind of investment they really need.
Product designers, software engineers, and UI/UX freelancers all cost (a lot) of money, and even building just “the basics” for your app can be time-consuming. Want to investigate the viability of GPT-powered chat vs. a live rep? Should you use biometrics or ID card scanning for enhanced security? Will your users share deep links or invite their friends to the app? It’s all more code, more integrations, and more effort.
And what if your users don’t want to use the app features your team built? It can be disheartening to find your hard work left on the cutting room floor and not in the finished product (or its newest iteration). It might feel like wasted effort. Most people don’t want to admit they championed a “failed” idea in front of stakeholders and bosses — and nobody will take risks in the first place if they’re not allowed to fail.
How many collective eyeballs have rolled when developers heard higher-ups talk about their company’s commitment to “rapid prototyping” when the reality is… less PR-friendly?
Rapid prototyping, but actually
Making rapid prototyping part of your company’s innovation system starts with embracing intelligent failure: “. . . if you accept that failures will sometimes occur in uncertain environments, it makes sense to plan for, manage, and learn from them — and in many cases to consider them experiments rather than failures.”
That still leaves the problem of time and money. And that’s why Onymos was founded.
Onymos Features-as-a-Service is a functionality component library. It includes over a dozen pre-built app features like login, payments, OCR, and MQTT for web, mobile, and IoT apps. Each feature comes with device-side functionality, server-side processing, optional data storage, and ongoing maintenance/updates.
And we wanted them to be as easy to add to any app as it is to add a button from one of the UI component libraries most app builders are already familiar with. They’re drop-in, drop-out solutions built to scale from the prototype stage to production.
It’s already part of innovation systems at companies like Albertsons, CVS, and Walmart because Onymos makes rapid prototyping and development, well, rapid.