No-Code February 19, 2021

No-code needs Code

Matteo Mosca @matteomosca

No-code has been called the "the fast fashion of building products" here


It’s an analogy I had never thought of before, that might be true and here is why in my opinion 👇🏼


  1. 3

    I just recently read something similar about the no-code movement. I think this is a fantastic direction.

    Here's why:

    In October of 2018 when I started my entrepreneurial aspirations, I had an idea of what an MVP was but I didn't know cost effective ways to get them built. So, falling into a very likely common trap for many first time founders, I spent way too much to bring our first two products to market. My first idea failed, my second idea is okay but I think I'll see a lot more success with my third idea.

    Had I understood about no-code, low-code options when I started out, I'd still have a lot of my funds on hand with significantly more options available. As you state in your post, the better the no-code, low-code options are the quicker you can bring your product to market in a cost-effective way and prove if it's going to be a viable business (or not) without breaking the bank.

    I agree - at the end of the day, I don't care what language my app is written in, what the technology stack is, or how it works. I want it to meet my business requirements, be affordable to develop and maintain, and be secure.

    1. 1

      Agree! And by the end of the day, our customers care about the benefits we provide, not the technologies

      I love this image, it states this point in a very clear way!


  2. 2

    Love this - speed and lack of distraction are the key benefits of No-code tools

  3. 1

    Insightful! Thanks for sharing this

  4. 1

    Can you build a no-code tool with no-code tool? :D

    1. 1

      Actually I've been working on a Proof of Concept to do exactly that:

      The key is not to think about code or no-code, but data formats and tasks people do frequently together. An example that already exists are GraphQL-schemas; Most people just want to get an overview of the schema, others want to build on top of it (queries), few want to expand it. There are lots of stable choices for viewing the schemas, less for building queries and the ones for expanding the schema are still kind of limited.

      In the POC I've experimented with building layout and state transitions in low-code. It's based on json-ld, so React components get automatically selected based on json-ld types. That's knitted together with typescript and the resulting data format is saved in git. Here's how editing that currently looks :

      I think wardley maps are really helpful here: For "code's customers", the way to solve some of their pain has moved from the Custom Build to the Product stage

    2. 1

      Crains can put themselves up!

  5. 1

    To be honest i think a little different here. Of course if you want to ship a game, you should not write an Engine but use one. If you wanna sell Shoes online, you should create, buy, design Shoes and sell them on a 1-click online shop and not program an online shop.
    But if you sell online shops, you can't use an existing online shop and sell it right? You have to code one.
    So all this no-code movement is basically creating a product that doesn't exist of code. I do not understand this movement at all. People are selling Shoes since years without coding.

    To me what people mean with no-code is simply "building a product without distraction". If you wanna sell Shoes through an online shop, you won't ever get the idea of also founding a shipping-company right ? You will use an existing one for sure. But thinking about coding a new webshop seems valid ? Yeah simply because you can sit infront of your computer 1 hour and start coding your new webshop. Founding a shipping-company would be way more effort.

    Coding is fun and easy to get started. This is why people tend to spend a lot of time at coding instead of focusing on the product. But thats it.
    Happy to start an open discussion here :)

    1. 1

      This is very cohesive. We’ve been building Mobile Apps for 13 years and often (most days) see customers in both startups and enterprise get distracted by expensive opportunities to tinker. This especially happens with visual items or prominent UX flows (login, navigation), and rarely adds much value to the product.

      Constraints are good - most people are just constrained and forced to release by budget!

Recommended Posts