"Let's just build the damn thing — and see what happens!"
That's what you inevitably say when you realize that wireframes, fake buttons, or no-code solutions won't do the trick in the case at hand.
When the only way forward with your idea is to build "the damn thing" — as minimum viable as they get — and see how it performs.
It's delicate. You have just a few engineers at your disposal (it might be a startup or a new initiative in a big org), you don't care how clean their code is (they will still do), and you don't think twice about scalability (yet you'll be punished for that later if you are lucky) - you just need to get results as soon as possible.
At this stage, the speed of development becomes crucial. Slow startups die fast. Here are a few thoughts on how to prevent this unfortunate outcome — and build prototypes and MVPs faster.
I noticed that ambitious developers often default to building "perfect solutions" from scratch. But when you test ideas, it's much better to leverage already existing tools, frameworks, and libraries — instead of reinventing the wheel.
The key here is to make sure that your tech lead shares this notion, that she enjoys working with libraries and frameworks, and recognizes the advantages of this approach for an early-stage initiative. If, on the contrary, she defaults to building "perfect solutions", you're screwed.
Let's face it: any experienced developer can figure out how to leverage any existing framework or tool. They will simply read the docs, poke around them, and voila! The problem is that reading and experimenting takes time — and time is money.
That's why I learned to ask which libraries the coders know well — and opt for them if it's possible.
I also noticed that some developers have a natural tendency to choose the trendiest and newest solutions. "The trendiest and newest" might also mean unproven, buggy, or not having good docs or enough support from the community. It also means that replacing team members will be more problematic or not optimal (assuming your initiative survives long enough to have problems on the staffing front).
A paradox: sometimes, building your own thing is faster indeed. We once spent a few days trying to make a React Native component from one existing library work — and failed. Then we built our own component in just a day. The catch here is that you rarely know such things in advance. So the right strategy is to be vigilant — and change your tactics as soon as your team starts lagging behind your estimated schedule with the implementation of a certain ready-made solution.
Some layouts are easy to build — and some are tricky. Designers do not always even think in these categories, and it's critical to constantly remind them of this. Is a certain element really needed? Is that animation necessary? Making changes in Figma can take a few minutes — and entail hours if not days of development. While for the end user, there might be NO REAL DIFFERENCE whatsoever.
By the way, this approach of leveraging existing frameworks and tools in development can be applied on the design level as well. There are tons of design elements out there — icons, pictures, animations — that can be reused. Lots of them are free or cost pennies. You just need to tweak them a little so that they will match your style guide — but it's much faster than making something from scratch.
Products can — and should be — simplified as well. What is crucial? The ability to decide what NOT to do, and how to simplify things and cut off functionality without compromising the user experience to deliver not a half-baked prototype but a product that feels real and still does the job, despite being an MVP.
I’d argue that this skill — managing scope based on how much capacity you have — is the most crucial in product development. Maybe in life too. People often underestimate the complexity of their decisions/solutions — in online businesses and offline ones equally. At least I witnessed that almost daily in all the companies I worked for.
Simplification is the key. Do we need an app — or can we just make do with a web solution? Do we need locations on a map when we can show them in a list sorted by distance? Does marketing need all these tricky types of discounts — or can they maybe work with just one? Every decision has to be justified from the user's perspective.
Life (and business) is the art of balance. I'm fully aware that the problem with the described approach might be that the team might feel too limited and demotivated at some point — especially if you go on in this "prototyping mode" for too long.
If you as a developer only get to employ the tools you know and can't get a new toy (framework) to play around with, where is the fun in it? Also, the whole idea of an engineer's career is to constantly acquire new tech skills by doing new things. Your designer wouldn't be super thrilled either if you limit them too much.
So overdoing what I've just described can be harmful as well.