It is that simple.

I can assume that there might be counters, attacks and pushpacks to this heavy statement. Bear with me on this. Before we address the house on fire, let me take you on a quick detour.

This was my first day of a new semester while doing my Master’s in design studies at the Delft University of Technology. My professor at that time started the semester with the Pressure Cooker Test.

What was it about? As a team, we had to compress six months of product building and development into one day. It was, literally, a pressure cooker!

We wrapped up the day having made a very quick-prototypyish demo, presenting it to the mentors who had facilitated this event.

A year after this happened, I started doing my Masters’s thesis, where I underwent the conventional product-building process. I did roughly two months of design research, including planning, landscaping, feasibility studies and all that jazz, before building the product.

Throughout this phase, my mind wandered back to the Pressure Cooker Test.

Was there a faster, quicker, more rapid way to do the same?

The only issue was that most of the insights were gained after the product was in the hands of the users. During my weekly check-ins with my design professor, I often asked him, “Why does design research take so much time? Even after months of user testing, it doesn’t seem as close to reality as expected..”.

This was when my professor mentioned the story of another fellow graduate who was working with a prosthetics company to design use cases for an improved hip replacement surgery. The student had extended her design research, not by one week or month, but by a whole year. At the end of the design research, she had become an expert on hips. After one year of investigation, she was able to grab onto that 1% deep insight which led her to formulate the product vision and further development.

Now, who has time for all this?

You might not be having time to do such extensive research investigations. Oftentimes, it’s a luxury. Especially in startup environments where a week or two can make or break a company, we might need contrarian and unconventional systems for product building.

The bigger problem with research can be done for one day, one month, or even a year. The depth might change, but it wouldn’t necessarily guarantee that the product is better. You might increase the chances of it succeeding and still failing.

Most of the products don’t survive a day out in the open.

This led me to hypothesize that the best product insights are gained by putting the product out in the open as fast as possible. Even if they are not perfect or the best working solution available now.

If a wrong decision can make or break a startup, putting the MVPs out as quickly as possible is better. It’s similar to how we shoot bullets with a shotgun and attempt multiple hits expecting one of them to hit the bull’s eye.

Now, you might ask, how is this even connected to the discussion we have been having between code and no-code?

With no code, you could build startups for breakfast.

The times have changed.

From Learn, Test and Launch, it has now come to — To Launch, Test and then Learn.

The first time I used a no-code app was to build a COVID Wiki app during the second wave of the pandemic in India. As we wanted to intervene as soon as possible, we completed the process in 1-2 days, from ideating, brainstorming, building and launching. When I pressed this app’s launch button, it felt eerie and weird. The app was nothing fancy but — How could this be built so fast?

I launch, test and learn. All the time. No code had rewired my brain.

It has changed the way I think about building products.

So, umm, what is no-code?

If you’re with me so far, but still confused as to what no-code means, let me give you a quick primer.

No code is nothing but code. Except that all the syntax and programming language jazz are stripped out. In no-code apps, you find everything to be more visual. All those WYSIWYG-style drag-and-drop interfaces replace lengthy lines of code.

The no-code landscape is picking up quite fast. Now, you have a no-code alternative for most of the code-based products you find in the market.

This approach is a part of my product philosophy now. This thinking has penetrated deeper into the work I do.

For Noora Health, I’ve been building various mini-apps using these tools to solve specific problems in our workflow. I’ve also got quite fast at building landing pages using a no-code website builder, Framer. Recently, for developing a landing page for a client, a lot of cross-functional alignment was needed to bring all the marketing/comms pieces together. Using Framer, we could quickly collaborate and make version changes rapidly before going live. In a conventional setup, there would have been a lot of back and forth, which this avoids.

And there are other tools too. Creating finance, budget and subscription trackers on Notion. Or complex automation on Integromat and Zapier. And it’s happening everywhere. All without code. Even in some startups.

Julia created HelloPrenup (a prenup management portal) after getting frustrated by hiring various overseas developers who didn’t consider the sustainability of the product they were building. She decided to do it all independently with her co-founder using Bubble, a no-code application platform. The startup ended up raising $150K for 30% on SharkTank. (After all, the customer doesn’t care if the product is built using code or no code. They just care if the job is done.)

Gartner predicted that 65 per cent of app development will happen on low-code platforms by 2024. It’s no surprise to see the rise in no-code developer profile jobs.

The beauty of no-code is apart from the fact that it helps us to think with a higher level of abstraction.

From 30 ft vantage point to 30,000 ft above sea level.

Writing code and its syntax makes you look at it from a 30 ft view which might not always be required. Even though the coding languages are still some form of abstraction (programmers use various pre-packaged libraries and ready-made components in the building process), it is still very difficult for product managers, marketers and founders to read and understand.

For example, almost 90% of the time, people’s problems in business are usually SOLVED problems.

And there is a high chance that these might be reduced in abstraction to a template and made easy to build using existing no-code tools.

No code is like driving a car in first gear. You have enough tools and services available to get your MVP launch ready. If you want anything more, you will run into problems.

You seek code if you want to drive your car in fourth gear with much more control and precision.

Instead, the developer’s time could be best utilised to solve unsolved problems that have NOT been abstracted yet. Or in other words,

Use code only if no-code fails!