Is Low Code The Future? How I built and shipped my revenue-ready MVP in 4 hours
bethanvincent.com
bethanvincent.com
It has to be re-written once it grows. *
While this is true, I don't think Bethan or any other low code advocate would dispute that. The question is: can you get test an idea with low code.
The answer to that might be a trivial yes, but if you had asked me what that means, I would guess a team of 3 people could prototype an idea in about a week.
I did not expect a single person to be able to test an idea in 4 hours. That is the real insight here.
* Not all the criticism. One person points out that calling it a business is overblown till someone pays for it.
“Groupon was originally run on WordPress because they only needed to test one thing: will local small businesses provide discounts in exchange for being introduced to potential new customers.”
And yes it is an example of that it has to be rewritten.
From https://bigthinking.io/the-mindset-for-innovation-everything...
To me, the insight is that the less you care about the future of your "product", the less time you have to put into it.
I look at the linked site, and all I see is "Minimal". I don't see any viability, I don't see a product (identifying what's being sold takes a few clicks). I also see a bevy of GDPR violations. I see an ADA (or the EU equivalent) liability. I, as a security conscious developer, forsee a disaster of a security story.
I see human scaling issues, as everything slightly out of the ordinary that happens requires an email to an address which is on the surface completely unrelated to the site itself. I also see 842 social media trackers blocked with standard FireFox settings (though I guess that falls in with GDPR violations).
I also see some potential legal liabilities, as all of the agreements are between the users and "Bethan Vincent". That lack of separation could put the owner in a lot of hot water should any of the above liabilities become a reality.
Most of these won't - can't - be solved with a technological re-write. A lot of them will require a fair bit of re-writing the entire business model.
He probably should think about all these things, for sure. And maybe have taken more than 4 hours :) , they're not necessary risks for sure, and since you've pointed them out, now he can fix them :)
That said, if you're operating out of the EU, and are targeting EU customers, being GDPR compliant seems like a no-brainer. Especially since it can be built in from the beginning with far less effort and money than retrofitting for GDPR compliance later.
The same goes with accessibility. Building with it in mind is cheaper over the long term than fixing it later.
The key is that your business won't just lose customers over these kinds of issues, the business instead gains legal liabilities with attached fines, legal fees, and remediation costs. Even if the goal of a startup is only to be acquihired, the acquired liability might not be worth the gain of an employee or two for a large corporation.
We have been programming computers for most of a century: 71 years this year. And in all that time, nobody has come up with a better way of telling a computer what to do than writing text in a programming language. People keep trying, of course, with endless permutations of flow-charts and rules. But sooner or later, you'll find yourself either:
(a) unable to express what you need to express, or
(b) tangled up in Cthulu's own flow-chart, barely accomplishing something that you know is a three-line `for` loop in Python.
And the thing is, anyone calling their system "low code" (rather than "no code") knows this. They know that the shiny demo can't actually do all you need. The moment you want to build something they haven't already imagined, you fall off the edge of the world. That's why they hedge, and say "sure, you might write a little code". Then the trap-door opens underneath you, and you go straight from a click'n'drag flowchart to writing a React component (or worse). Not fun.
I cofounded Anvil (https://anvil.works), and if you squint hard you could call it a low-code platform for web apps. But many valuable apps are a fifteen-line Python script surrounded by fifteen tons of JS framework. The problem here isn't the application logic - it's everything else! So build a drag'n'drop designer, and a VB/Delphi-like component UI, then get out of the way and let the author write their app logic in peace. When your users try to do something you haven't thought of (and they will!), they'll have an industrial-strength toolbox to deal with it.
But to tell someone that they can build substantial apps without writing code is to invite them to drive at speed up a blind alley.
So I agree with your rant, though in principle and in my most idealistic moments I'm still interested to see where the whole low-code "movement" goes.
What is exciting is that simple web/apps are getting to that same place that spreadsheets were at and where blogging was at.
People already have a clear idea of what they need most of the time: "fill out this form, send it in a email, put in a spreadsheet, load it on this page with an image", etc. Provide sensible defaults and let the CRUD apps flow.
It is tempting (albeit a bit snobbish) to think that "CRUD apps", as a category, have so little logic that you can describe a useful working version without code. I just don't think it's true - they are always shot through with squirrelly business logic.
You can carve off products like form builders (eg Google forms/Airtable/etc), but anything you'd describe as a "CRUD app" contains an amount of logic that's just painful to describe without code. (And the form builders know it, which is why they don't support those use cases!)
The key is having the awareness and discipline, when the prototype is validated and starts to gain traction, to throw it away and build the real production app using what you learned, instead of just accumulating months to years of technical debt and cruft on top of a prototype. If you launch with a "permatype" you will eventually find yourself facing a very expensive and painful "2.0" project.
I'd say easy code (think python and garbage collectors) plus easy scale (think cloud and apps and serverless) is where the easy wins are.
People have been trying to do point and click IDEs for ever. It's always a shit show and I see no reason to believe it'll change shortly
I've seen many cases where their were easy non custom solutions to test a first version of a product/feature I have refused to custom build until tested...where then shown ineffective.
Buy over build until it cannot scale (often the scale is cost not growth).
Is this the future? Yes, for people who are pushing out clones of simple, well-understood apps. You can put up a web store in a couple days, or make a first-person shooter, or a dating app.
And the code complexity doesn't actually go down; as it takes less code to meet a given set of expectations, expectations expand.
> It’s also extremely important to me that an employer has a positive attitude towards diversity and actively encourages candidates from under-represented groups. This is a hard thing to tell from Indeed or a job aggregate site.
But their MVP does nothing at all relating to inclusiveness. It's just a job board CRUD app just like all the other job boards.
Sure it may work for some easy cases but most products aren't that simple and as soon as you want to add some extra functionality you basically have to rewrite the application from scratch.
I'm happy that it worked for this guy but if I was a betting man I wouldn't bet on "low code".
the future will likely see apps being built in collaboration with AI.
Oh please no, that's just so unnecessary.
I am able to install a vanilla Drupal-based forum with all these integrations in the fraction of that 4 hours (working with Drupal for 15 years certainly an edge here), which I think can scale much better for less than your solution up to a certain point, but certainly fits to a York-scale. But would this prove it is a great business? Not really. Would this change if it was NodeBB, Wordpress or any other technology? Not at all. Would I hate working on something that is super boring to me just to earn money? Absolutely.
In general, "low code" should be the future: because efficiency, and maturity of available libs/components. What i'm saying is that this should be seen as a win.
But these are not the products of the future. Another way to look at it, is that anything like this might be a more well understood component of another application or product, and the more they're used the easier they'll be to integrate. The products of 2020's will end up being highly specific to some niche / vertical and require lots of industry knowledge.
Are you charging money and have customers actually paying you? If not, it's not a business yet. It's a website.
This barely functions as a website and looks like a few components thrown together using a bootstrap template.
What does "revenue-ready" even mean? They're willing to accept money for it? Really high bar to clear /s
I can programme if i need to but will often use convenience tools to quickly test ideas. Thats kind of the spirit of (many not all) startups right now.
Isn't the magic in figuring out what people are willing to pay for? That's definitely PGs message, along with speak to customers and do things that don't scale. And now someones getting flamed for attempting to do all three (whether it's worth blogging about is another thing).
I believe i'm ok to comment here as I have worked at both ends of the scale (B2C super fast and dirty vs super deep scientific medical software with long time line to market).
I don't think people are making fun of the "low-code" aspect as much as the "I literally built a business in an afternoon" part.
It's a job board, implemented 2 months ago, that has a handful of postings. How is that a business?
Don't get me wrong. I don't think the world needs another jobs board but at one point airbnb sold cereal boxes so who am i to judge on what a persons ambitions will look like in 12 months time if they continue to learn and get some feedback. I mean, if they are reading the thread there is a bunch of feedback here they can assess.
Everyone here who is commenting on scaleable systems had to start somewhere, i would bet for many that start was not with something that was at least halfway functional and could accomodate users.
There are lots of fair and constructive comments here which I'm going to be taking on-board both for York Tech Jobs and for future projects.
As many people have pointed out, the claim of being a business may be a bit farfetched at this stage. The spirit of the article was to show that building and validating a basic MVP is possible in a few hours, I added the last sentence about it being a business as a bit of a perhaps misplaced barb at people who are all talk, no action.
Thanks to everyone for their comments. It's really appreciated.
She says at the bottom of the article:
I literally built a business in an afternoon and so can you.
I also appreciate the effort to put something like this together, especially for a person without minimal coding ability. That part is great.
Calling it a "business" is everything that's wrong with the Silicon Valley mentality. It isn't something you do in an afternoon. It could be a business one day, heck, it should be! But emphasizing the technical component over actually doing business is how many so-called companies get into trouble.