Is Low Code The Future? How I built and shipped my revenue-ready MVP in 4 hours
In this technical retrospective (2020), @bdv500 shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 40 points
TOTAL DISCUSSIONS 49 comments
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.
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.
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.
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.
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.