For 4 hour experiments, it sounds like a reasonable strategy; but what happens are your requirements become increasingly complex? Is "Low Code" going to work, for example, if you want to implement A/B tests? Possibly one day.
As with all titles that starts with a question, the answer is probably no.
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".
Real life is imitating art at this point, truly. Saw that whole plot point in the final season of Silicon Valley that was released last month and thought it was one of the most farfetched unrealistic scenarios in the whole show. Looks like I was really wrong.
Great, you made a location-specific clone of an app that has been made hundreds or thousands of times before.
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.
For prototyping relatively simple, UI-focused apps, yes, I think low-code and no-code solutions do have a place.
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 feel like this is the self-help hype all over again. People with a network of followers can sell almost any weird stuff. And then afterwards they praise themselves for doing so.
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.
Low code is definitely the future. Look at all the things you can do by calling the right APIs and/or all the scaffolding available. The clear trend changed after RoR and managed cloud services like Heroku popped up. Now the big players offer cloud services that would take months to code but if you pay up you have access (everything as a service). The lesson for developers is work on tools consumed by other developers and if this is not the case probably someone else is working on automating bits of pieces of your work.
This has literally always been the case for the history of software. Unless you're willing to tell me an operating system is a low-code solution, building software has always been about obfuscating the frustrating parts to focus on the stuff that actually matters. Infrastructure as a service is just the current iteration.
Low code means low expectations. Coding is not the hard part, but to satisfy the end-user or regulatory needs with the positive (or at least minimal negative) impact on the user experience. Complications arise when you think on "what can go wrong" (e.g. you lost a webhook going to your CRM and you want to understand why it happened, how it impacted the user, how can you recover automatically) and start mitigating them.
I honestly feel like these comments are quite elitist.
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).
Well to be fair the title is "How I built and shipped my revenue-ready MVP in 4 hours" not "how i built my business in 4 hours". The claim is an MVP. I've seen people raise money with less than this so at least something was built. I've also seen people raise money to hire people to build an MVP which ended up being something built using "low programming tools". At least the poster is making an effort to take some action. I cant speak for how they will iterate etc but many people with an idea never actually even get started.
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.
I can confirm that I am reading all the feedback with avid interest.
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.
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.
Shit it takes me about four hours just to get a few basic services set up & configured for a new business idea, before any kind of product work can start. Could throw up an experiment without doing that but it wouldn't really be ready for customers, just faux-ready enough to prove demand (which is still nice and all). Having done that one would not yet have "literally built a business", though.
I vehemently disagree. To me, this is a classic case of people who believe in YAGNI versus people who plan (sometimes too much) for the future. I've been burned too many times to be able to adhere to the YAGNI protocol. Sure, these low/no-code solutions may work fine for a while but eventually, they'll hit an impassable roadblock and then they're stuck until they either decide that roadblock isn't worth overcoming or put in the time and effort that could have been accounted for at the beginning.
The criticism -- almost all the other comments at this point -- focuses on one aspect of the low-code app:
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.
Low code already happens. Now I think it’s just getting popular .
“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.
Yeah, it's not really new. A few years back, I interviewed at a startup that was close to two years in, and they described their app as "the most overloaded Drupal installation in existence," and were in the middle of migrating it to Rails.
If people got limited feedback, prior to wider distribution, they could re-work their articles so 95%+ of the discussion isn't centered around one superficial point, but rather the bread-and-butter of the article's point: as you mention, 1-person & 4 hours vs. 3-people & 1-week. Big difference between the two!
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.
This sounds like the kind of risk someone running a startup can take.. do you really advocate limiting MVPs due to potential GDPR violations? And English ADA equivalent violations?
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 :)
I guess it really depends. Any risk might be worth it depending on the benefits.
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.
As a programmer, I kinda don't want it to be, but I acknowledge that as short-sighted.
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.
Being the critical HN person, I would say that "revenue ready" is a fancy term for "I built this website/app and now need to get clients". So revenue ready = just a website/app.
So, this is where the founder of a "low-code" startup pops up to confirm it: "Low code" is mostly a false promise.
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.
Today I'm working on a project in which I was brought in late to rescue it, where they're extracting data from BIM software (which fits the definition of a no-code database-backed GUI app) using (low-code) MS Access and pushing it into (low-code) QuickBase, and all 3 pieces were set up by people who (yay) didn't need to understand code but (boo) really could've used a few lessons in best practices.
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.
"No code" is always only "less code": look at the complexity of Excel spreadsheets by non-coders. But it is a "singularity event of sensible defaults" that allows useful things to be built before the first whiff of code.
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.
Excel is sui generis - it is the end-user-programming platform that lived. But even Excel formulas are a textual programming language, and the really hairy Excel spreadsheets spill over into VBA (a "real language" for these purposes, and one whose ergonomics still blow the web out of the water).
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!)
So, basically nothing particularly noteworthy about the actual product as it was built by 1 person in 4 hours. For this type of business the hard part is the network effect, so in effect the journey is barely begun.
If it's possible to prototype or test a potential new product or feature with little to no engineering effort... that is the only responsible thing to do.
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).
The problem is this MVP doesn't even fit the objective that the author lists in the beginning. They stated:
> 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.
I'm always curious what's the point of such articles? It is as useless as a programming language benchmark on "Hello, World!" and "Number of empty HTTP request/sec".
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.
52 comments
[ 3.7 ms ] story [ 103 ms ] threadSure 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.
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.
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.
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.
And the code complexity doesn't actually go down; as it takes less code to meet a given set of expectations, expectations expand.
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.
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.
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.
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
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!)
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).
> 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.
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.