I don’t really understand what “no code” is. You can put up a storefront and conduct business without writing a line of code, simply by adding plug ins to Wordpress, calling out to stripe etc. The result is somewhat templatized and slightly generic looking but that’s great: your value comes from the content, as the author correctly describes, and the visitor will presumably understand navigation etc.
This kind of process has decades of predecessors, from dbs like Delphi, Excel, to Emacs in the ‘70s to (so it was claimed at the time) FORTRAN.
Is “no code” meant to somehow imply something more?
From what I can tell yes. It’s intended to imply something more.
See bubble for example - https://bubble.io . It’s basically “visual” Rails. The intention is to allow users to build complex, interactive software visually, without having to write code.
Webflow has a ton of plugins that can get you something similar. You can have a user model (memberstack.io) with authentication and even the ability to create user specific content. I was able to create a fairly complex user dashboard that had real time charts pulled from an Airtable database that was synced automatically with user interaction using Zapier.
...but, here’s the issue. You just can’t do enough. I made it about a week before I abandon the idea and went back to Rails.
I’m still bullish on the idea of no code though. The tools are there. They just need more functionality.
That's always the case though. The reason why we use programming languages is because we need the expressiveness they offer. Attempting to simplify it any further severely limits the type of applications you can build. And so you end up with cookie cutter apps. It might be fun, it might even be useful for some back office tasks, but if the marginal cost to produce a thing goes to near zero, it would imply the supply of apps competing for that category would explode.
A lot nocode or lowcode tools are visual programming languages; they are in fact just programming tools but look (and often are) simpler to start off with. But when you need more, you are in fact programming with code, just via a visual interface. Which indeed can (will) become painful for many tasks. Then you are using the wrong tool for the job.
Thing is, and this differs per market; most companies do not need anything more than endless streams of crud apps, and that is where these tools shine. You (and many of HN) might work in the b2c market, but where I work, people do not care much about how things look or ux; they care if they work just a little better than the sap or oracle interfaces they had before. Actually, this goes for many (most?) b2c products as well; most (traditional; challenger banks are a lot better) banking or airline apps I know look like bad template barf-ups (many are indeed that, bought from the same cooking cutting companies) and yet people use them. Would it be better if they were custom designed with money spent on actual ux and design? Sure, but apparently not enough to matter to the company commissioning it.
When companies I work with look for no/low code, the only reason they will not use it is vendor lock in; if they cannot run on premise and/or ‘eject’ the code, they will not use it. Several products allow this and they are fairly popular (so much in fact that they cannot find enough ‘devs’ for their clients).
These systems have their place; it is just (much) faster (some boring things in regular environments are just a few clicks with these tools) for some x% of applications while another y% you cannot do with them or is very difficult; I would still do the x% in such a tool as thinking ‘we might need x+y later on’ is premature usually and in my experience does not pan out. We have programmed applications ‘created for expansion’ 15-20 years ago that run to this day which would have fit in the x%; aka we wasted time and money while the expansion was never realised by the client.
Edit;
> it would imply the supply of apps competing for that category would explode.
And that is a very consumer centric approach; we are not all making fitness apps or something; these apps would all look (more or less) the same but work on different APIs and data; that is fine for almost everything; not only some internal stuff. It helps companies a great deal to just have something their clients can use vs nothing, even if the cost is close to zero; and they cannot be the same as they talk with different systems and different data. Even creating partner dashboards more efficiently than slinging code is something people do all the time and you cannot ‘just copy paste that’ to another company.
These products are not generally meant to build ‘the next whatsapp’. But you can prototype it with them and show investors; I agree with you there though; wrong tool for the job.
> When companies I work with look for no/low code, the only reason they will not use it is vendor lock in; if they cannot run on premise and/or ‘eject’ the code, they will not use it. Several products allow this
What nocode tools don't have lock-in? The ones I know which are open source still have these proprietary add-ons for important stuff like authentication or connecting to other systems.
Conceptually some no-code tools work essentially as glorified editors or code generators for a particular subset of a mainstream programming language. In this case, at any point you can abandon the no-code tool for a project or part of it and continue maintaining and developing it as an ordinary bundle of code.
>Thing is, and this differs per market; most companies do not need anything more than endless streams of crud apps, and that is where these tools shine.
IME at least 20% of the needs of these companies are not met by "basic CRUD app programming" which is why these no-code things never really take off despite often appearing quite impressive. 80% is not enough.
Basic CRUD also implies an understanding of domain modeling and normalized relational db design. In practice these are uncommon enough skills among developers never mind users of tools like these. That's half the reason why spreadsheets business users want turned into apps are so horrendous - it's not even intrinsically a problem with excel, it's just that the relationships between the domain objects are usually confused and the data is in a mess.
I've worked for a company that market themselves with "No code". How it worked there was that we spent a lot of time understanding the users need and business domain and modelled a properly normalised db from it. Then came the "no code" part, which was a platform that made it easy and very fast to create the first iteration of the interface from the database. For those things where the mapping to some tables in the database were simple it was just a few clicks. Something like search customer and create/update customer pages takes less than a minute to create.
And you are of course right in that this will only create 80% of what the customer needs. But the marginal cost for us to create those first 80% of the application were almost zero. And since we weren't worse than anyone else with the last 20% we could deliver fast, inexpensive and still have large margins.
The mistake I think many do when they think "no code" is that they think that they can eliminate the developer and let business people just "configure" the new application. But those people have the insulting idea that the only thing that makes programming hard is syntax.
> The mistake I think many do when they think "no code" is that they think that they can eliminate the developer
Exactly. No-where did I mention you do not need (good) devs for this. They are just not writing code (in the traditional way). No/lowcode is not saying the same as end-user development, although it gets mixes up quite a bit (also by the companies selling the tools), it is not what I mean when when working with such tools.
And in my experience at least, you can push back closer to the 80% than the 100%, so sure, you don't get that last 20% (or part of it) but maybe I can convince the client they don't need it. And if they do, I would choose (maybe) another tool for the job like I said.
On one hand this is correct, many apps compete only on form function like (Instagram vs snap).
I think there will always be a random form function that captivates (today’s ticktok), but my prediction is that the web will be won less by competing on form factor, and rather won focused on other parts of the user experience.
In a simple example, logistics is an obvious differentiator, 2 day vs 5 day shipping etc.
There are so many dimensions to compete on and app design will contribute to many of those dimensions, but some ways to compete will not involve coding.
> See bubble for example - https://bubble.io . It’s basically “visual” Rails. The intention is to allow users to build complex, interactive software visually, without having to write code.
Why the "hate" for code? I immediately understand the problems that typical programming languages have for people who are not trained in programming. But there exist good reasons why other approaches like "visual programming" have failed (except for some niches). So in my opinion the solution is not to "spread hate" against code for a "stupid" market pitch, but take the time to develop programming languages that are better suited to the needs of the customer.
I can think of a few. Most of these things could also be done with text-based code, but typically aren't when you're just starting out:
- No set up issues (visual programming is cloud-based)
- Less of a discoverability issue (visual programming shows a lot of things all at once)
- A sense of familiarity (people have seen flow chart like things before)
- It's easier to see the difference between arguments and parameters
Full disclosure: I have almost never seen visual programming languages, but I got the idea that there was no devil's advocate present within you. So here I am ;-) I find it quite easy to think from a beginner's perspective, because in some sense I can't fathom that I know what I know now since I never thought I'd ever know this much in my entire life (and I'm only 31, lol).
> - No set up issues (visual programming is cloud-based)
Cloud-based has nothing to do with visual programming or no-code (you can also do cloud-based editing of conventional code if you desire). Counterexamples: LabVIEW, Simulink.
> - Less of a discoverability issue (visual programming shows a lot of things all at once)
Wasn't "shows a lot of things all at once" actually an argument (marketing pitch) why conventional programming language overwhelm many people who are not programmers, and visual programming languages are "thus" better because charts have a lot less "intellectual density" than computer code?!
> - It's easier to see the difference between arguments and parameters
> Most of these things could also be done with text-based code, but typically aren't when you're just starting out
This means that it all can be done, but isn't. Which means that it's a cultural issue, not a technical issue.
Also, I was under the impression that discussion was about mainstream programming languages and mainstream visual programming languages (of which you said there were none). Here's a workable definition of mainstream: the Stackoverflow top 10. It doesn't have LabVIEW and Simulink.
When you discount niches for visual programming, then you have to do it with text-based programming as well, otherwise the argument isn't fair. I presume that you know this. So I find it peculiar that you don't qualify why you're using languages that aren't (seemingly) remotely mainstream, or why you're not using mainstream examples.
> Wasn't "shows a lot of things all at once" actually an argument (marketing pitch) why conventional programming language overwhelm many people who are not programmers, and visual programming languages are "thus" better because charts have a lot less "intellectual density" than computer code?!
I wouldn't know.
I'm quitting this discussion, the exclamation mark + question mark, "what is actually the difference?" There seems to be no wonder or curiosity from your side. Instead it seems purely adverserial.
There's lots of people who want to do stuff, but code is expensive. They are excited for solutions that let them do "pretty much" what they wanted to, without having to make that investment into code.
> I’m still bullish on the idea of no code though. The tools are there. They just need more functionality.
Maybe, but I think the idea of setting up a SaaS business without writing any code just won't work.
If the tooling is simple enough that a non-coder can get it to work, then the no-code SaaS business is providing very little of value. The user could just do the job themselves using the same no-code tools.
I think you’re right that having some sort of moat is very important to a business, but I don’t think that moat has to necessarily be the software. It could be operational expertise or fame or capital or connections or anything else that’s hard to replicate.
Drag and drop plus lots of options in dialog boxes, looks like.
It's been done before. Viamall, (later Yahoo Store) the first online shopping cart system, was very much like that. Totally hosted, updated through the web, pay by the month. When Yahoo bought them, they demanded a cut of revenue, too. Those seem to be the key components of this concept.
Other ancestors include Visual Basic, Dreamweaver, and Hypercard, but those were not hosted by the company behind the system, so they didn't have the lock-in and profit potential of hosted systems.
It's a reaction to the mess the HTML/CSS/Javascript crowd has made of web design. The web was supposed to be WYSIWYG, and that got broken.
Actually, the earliest browsers pre-CSS weren't just viewers but had also editing with primitive styling, though it's difficult to imagine in today's CSS-heavy web. Personally, I think adding a complete new item-value syntax and value space on top of HTML/SGML (which already has attributes for exactly this purpose) was completely uncalled for, and to this date we're hearing about the structure/presentation dichotomy which just never made sense as a justification for adding additional syntax.
Historical note: Viaweb was written in lisp, so most of the users had a hard time customizing it (I heard of one book on modifying Viaweb, but have never actually seen it.)
Hopefully this isn't ungenerous, but it seems like a marketing/signaling term that people on places like indiehackers use to market their products. If it wasn't labeled as such, a nondescript framework with the plugins + content that you could build for the last 20 years wouldn't stand out. Bothers me that it is something that apparently people are proud of, they'd empower themselves a lot more by sitting down and picking up a basic framework, where they aren't limited by someone else. It's not as though they aren't capable.
The guy behind http://www.buildfire.com enabled companies to offer mobile apps without coding experience. He now has the means to race McLarens and sky dive religiously.
Unlocking human ingenuity while making our species less depending on learning to think like a computer is always going to be a big market.
Usually it means you're still coding, but entering the "code" into forms and wizards instead of text. After that inevitably fails there are usually text coding fallbacks that require 10 times more code than if you'd written the whole thing from scratch.
No-code solutions are like Glide [1], which lets you create a mobile app using Google Sheets as a starting point and then assembling interface elements/flow logic in a designer.
I think there's value in no-code even for seasoned programmers, especially for quick front-end work. The front-end world is currently very fragmented. Us backend folks are completely befuddled by all the options and frameworks that are out there (Angular, Vue, React, Oh jquery is out? Wait, there's a movement back to plain old Javascript? etc.).
Many of us just want to concentrate on building the backend, and use a tool to quickly mock up a CRUD interface or mobile app in order deploy quickly and iterate with customers.
>> Is "no code" meant to somehow imply something more?
In a way it's less. The products you list are much more capable developer products. These are more in the direction of the FileMaker or Access level of constraint, but implemented in a more modern way which means they can be fairly effective.
Using "no code" is just branding that hasn't been used broadly until now. Maybe it has, but it probably isn't well known enough to be unusable. I'd have called these "4GLs" perhaps.
Lots of companies are getting in on the act to create a market for this. All of the established companies making business software have some no/low code solution. Then there are newer companies like Zapier who do automation and are trying to be a connector between these apps.
Access was one of my favorite Microsoft products of the late 90s. As a high school kid learning C, VB6, and Linux I came across access and really liked that it let me make easy forms. If you knew how to do DB design access was a great tool. I made a grading system for a teacher and several other teachers adopted it. They used it for almost 8 years before moving on. I was just a curious high school kid able to make useful software with a little persistence. It still feels like that level of accessibility in terms of software tooling does not exist in modern dev. It’s all watered down and abstracted in ways a simple Desktop app is not.
No code is a signal of bullshit for a company who claims software development as their competitive advantage but in truth the core competency is something else or doesn’t exist at all. Wework is a good example.
No code/low code is reinvented over and over as trends/paradigms enter their late stages of consolidation. Yes it implies “something more” in that these new tools function in the modern world.
I think of it as the final evolution of the Uber/Airbnb/Any process with a website is a tech startup thinking process.
This whole no-code thing is basically a bunch of terms that allow people with valid, legitimate but boring old businesses to feel like they are Microsoft or Google. While extracting a whole lot of money of course off the fluff around it.
yea building complex, polished apps using no-code tools is arguably more harder than just writing code and using frameworks. it's a different set of skills, albeit still a skill so i don't get why programmers are feeling threatened by it.
I feel threatened by it in a very specific way. There are pointy haired bosses who will order that: "now we will do low code". When they bump into obstacle that is not doable in low-code they will be angry at the developers that cannot deliver what customer wants. Where with just normal development you would not run into such issues.
As a developer I have some power to say no to such thing but marketing people at low-code can promise everything without ever providing what they promised.
I ran into this in my last federal contracting job. Customer was being sold on using ServiceNow as a low code solution to replace a custom .net application with something like 2 million LOC.
No-code and low-code solutions are seductive to many because they can get easy wins fast, but those easy wins mask the fact that more complex functionality is either more difficult, or outright impossible. Not to mention that once you heavily customize those products, upgrades can become very painful and very costly.
A "low code" or "no code" office would never hire me in the first place, so I'm not really scared of this. My talent lies in making hard things possible, not in the low-hanging fruit that can be done with "low code".
That said, as senior developer I've been very happy lately to get the company to use more off-the-shelf libraries (like Material UI for React) rather than coding our own stuff, lessening our development and maintenance time and letting us work on more stuff that matters instead. Of course, we can also create custom components instead if we have to.
No, it's just that, but below some threshold of friction because of comprehensive integrations and simple UI. Think Zapier, in which you can build something that has real value in under 5 mins.
It's a useful category for the people who use these (like me).
This is the vibe I regularly get from Indie Hackers. So many start-ups exist to serve the start-up/SaaS industry. Every second day there's a "SaaS that helps you create a SaaS that sends Emails for SaaSes" start-up posted there.
Startup founders often cater to other startup founders, and it seems oddly circular, until you look at more mature businesses and realize the same thing is happening: businesses selling things to help other businesses sell things to other businesses…
No-code platforms have always been a great way to put a MVP together. MVPs help you vet the idea before pouring real dollars into it. They are not meant to be the foundation for the product itself; those thinking otherwise have a very expensive refactor ahead of them!
I hear MVP thrown around like candy in the consulting I do. I _wish_ they started with no code!
Didn't some now-unicorn start its life as an email distribution list or spreadsheet?
YC's 19 cohort https://www.glideapps.com/ allowed me to have a meaningfull conversation with prospect (lets call a Proof Of Concpt) after minimal work.
POC accepted, deal signed; left glide for regular webdev.
The value no/low code brings is having buttons screens and transitions really quick in order to generate engagement with prospect.
Totally agree on the MVP front. The term "no-code" may be annoying or way too "buzzwordy" to some, but I think that really misses the point.
These tools (WordPress, Zapier, Launchrock, etc.) can be used to get something out in the world quickly and figure out if it's worth investing time/money into.
You might be thinking of Groupon, from memory their origin story involves emulating software functionality with spreadsheets/email lists/much manual grunt work.
Groupon began as a collective action site called ThePoint - think love child of Kickstarter and Change.org. It was built out and functional but not getting traction. They shifted to using that platform to market deals at local businesses and it took off from there. It was code from the start. However, as it grew there were thousands of sales and editorial employees turning customer contacts into sales campaigns, but that's not really something that code could replace.
The first real low-code solution was a spreadsheet. Spreadsheets were what drove businesses to buy PCs in the early 80s.
In the 90s, CASE (computer-automated software engineering) was a big thing. Powerbuilder was huge. Novell had one where you could draw a flowchart and fill in dialogs to make client-server apps... UI builders became common as language vendors added graphical IDEs to their game.
In the 00's we had a lot of visual development tools for websites. Dreamweaver, FrontPage, etc...
In the 10's we had Zapier, IFTT and Yahoo's pipes.
Lots of successful products and fortunes made with No Code and low code.
Originally, SQL was sold as a way to make programmers redundant by allowing business people to write their own reports.
In theory, with SQL any executive could write his own report instead of having to wait for weeks for those pesky software guys to write the reports.
For many decades, different waves in the industry have tried to bring tools to the market to allow non-programers to write programs. The thinking is that the tooling or the grammar are the obstacles for regular people to write programs (applications).
The issue is that it is not the syntax or the tools that are the barrier. The barrier to write programs is that the author has to thing about all possible states and conditions and handle them. That requires patience and a certain mindset. If you are not able/willing to be that exhaustive, you will not be able to write general programs. Conceptually you could write programs (or web applications) that have been narrowed to very specific choices of workflows with most of the conditions already taken care of for you.
Creating a website with drag-and-drop tools is not that difficult; until you start to consider: what happens if the user shrinks the window below certain width? What happens if he views the site on a phone? What happens if I have to change the length of a piece of text?
Yes and I am wondering per /indyike's statement "Lots of successful products and fortunes made with No Code and low code." - what are some examples because the product names mentioned were not made with no/low code.
They'll find some success, the same way that visual editors for desktop applications, and visual editors for web pages, found some success. In the end, these tools all require you to drop the facade once you want to do something too advanced.
I personally don't see how these companies can be worth much. Just as with visual web editors, they started out charging a lot but over time the price floored out to zero. Now there are dozens of websites that give away their "no code" editors, with the hope that you'll pay them to host your site forever.
> I personally don't see how these companies can be worth much. Just as with visual web editors, they started out charging a lot but over time the price floored out to zero. Now there are dozens of websites that give away their "no code" editors, with the hope that you'll pay them to host your site forever.
I agree. It seems like almost every day a new no-code platform crops up. Eventually, competition should bring prices down and hurt margins, right? What's the economic moat here?
For example, do you want to build a website or app from a spreadsheet? There's plenty of options and they all look very similar.
I am more bullish on the no-code solutions that target a niche/vertical, like forms (typeform) or member sites (memberstack) because you can offer complementary services (like Shopify does for shopping) and the niche is understood well enough that you can get close to covering 100% of use cases.
I would guess that a horizontal no-code company would have a harder time maintaining a competitive advantage.
The no-code solutions are enabling a digital sort of business that is distinct from their analog counterparts. Their examples - teaching, online job-board, courses for sale - are digital upgrades to teaching, newspaper classifieds, and books.
You can stitch together a useful business with these tools. But you won’t build a pure software business. They are just entirely different things. Building the so-called “no-code” technology is the software play.
As an aside, “Plenty of Fish” 1.0 was built with an off-the-shelf website builder. You don’t need to be a pro-coder to provide value.
No-code is a funny term and I'm not sure what it means. I would understand if it was non-dev or something similar. But most "no-code" people I know who work on side projects can edit basic javascript/etc, but couldn't write much from scratch.
I'd imagine this group is the subset the author is looking at. If you want to look at people who actually can't code, they are likely non-technical, and not using a tool like zapier. They're startups probably look very different (consulting, etc).
It’s funny to think about the differences in technical ability here. I build stuff for people to edit that our team often ends up editing for them. It’s not a complex CMS. People just get nervous and/or are lazy. Just existing in the digital age is a struggle or an annoyance for them, let alone this.
Occasionally I run into someone in Marketing/Sales who is in love with the idea of Zapier. It’s always Maslow’s hammer run amok.
My guess is this no-code thing is just taking advantage of the increasingly large, seemingly untapped demographic you mentioned here. They just don’t realize the actual cost they’re committing themselves to.
I find it odd that the article's topic is literally "the surge of people taking a shot at building a business with no code products", but the author then goes on to be really surprised that so many people in this group are trying to build a business compared with "developers in general".
Well if you interview developers who represent their startup product i guess you might end up with similar figures of "wants to be an entrepreneur"?
It's missing the point that devs might have a number of incentives in building tools outside of a business scope, but when someone sets out to build a product even when it's not their job & passion "anyway", it pretty damn sure aims to make money
Most software engineering is yak shaving in the sense that your high level goal is some business domain feature like “process a payment” but you spend most of your time in far detached language and os primitives, fighting idiosyncrasies in some json parser or UI state update library that has nothing to do with processing payments. Geeks really dig this impedance mismatch because they get to do the “fun stuff” instead of the boring business domain stuff. But a lot of people care only about the business domain stuff and could care less about descending into the catacombs. There will always be a need for point and click application creation and the tendency to want to get rid of the geek middlemen.
> You wish, usually you still end up programming the thing, just with worse tools.
This, exactly! I once was stuck under a manager that fully bought into the idea that BPMS systems would replace most enterprise development (or at least wanted me to think that way to work on his BPMS project). He said semi-technical BAs would be able to do all the work in the future, blah, blah, blah.
It wasn't true: we built what was asked for, but you had to be a developer to get within 10 feet of the thing. There were so many gotchas, and you had to code to implement anything that wasn't a toy. It was basically developed with shitty fake-Java and shitty fake-JSP with a lot of other shitty-fake technologies.
The title is just extremely wrong and clickbait. There's no content or data about "rise". If anything, the default founder is no-code outside of SV. There's a sharp rise of coding-founders, just because basic coding is becoming "basic knowledge" and taught in highschools now. I won't click these clickbait indiehackers links again.
I recall some ads from the 1980s saying "No coding required - just use our scripting language!" It must have been a successful pitch, as the ads lasted for years.
A great example of the no-code system might be something like Power Automate/Power Apps/Power BI from Microsoft.
It's pretty painful to use when you want to do something simple in code like explode an array, take a few of the values from that and implode back into an array again.
Things like AWS Quicksight or Google Data Studio might be in the same sort of world too.
so, the big question for me is: these tools generally package a lot of functionality in their "no-code" wrappings, otherwise they would be near useless (for example see LabView and Co, which are painful to work in and interestingly seldom marketed as "no-code"...).
So what's technically the difference to a high-level API? History tells us (from Fortran to Emacs to TeX to R/Keras/...) that these tools generally last _a lot_ longer than any of the non-spreadsheet no-codes. While at the same time being much more flexible.
So basically the "no-code" founders that are making money are the ones building "no-code" tools for people who can't code and those teaching people to start "no-code business."
I can't imagine you can build or even conceive a complex app without understanding the technicalities of how it all works. It seems to me majority of the no code tools are used for content websites with payments.
I think the future will be in "low-code" rather than "no-code".
For example, Looker has LookerML which while it isn't full blown programming, it allows for a lot of customisation and far more complex use cases when compared with "no-code" alternatives like Tableau.
I will never get the rationale behind creating a new proprietary language solely to protect people from 'full blown' programming. Or, in some cases, being able to read/manipulate config files with standard tools.
What very specific use case? I have found Cue to be versatile and usable anywhere yaml / json / config is used or needs to be validated. I'm mainly focused on code generation with Cue as the input. https://github.com/hofstadter-io/hof
I'd consider a situation where you've got a human readable (?) data format that needs to be validated a rather specific niche for a domain specific language. All I'm aware of in that area is XSD and DTD for XML (and maybe some recent efforts to make schemas for JSON but those aren't too flexible).
I'm happy someone is trying to fill that niche though, I'll remember cue for when I run into such a scenario.
> Just imagine the same being true for coders: that 7 out of every 10 programmers you spotted at developer conferences or in the engineering departments of larger companies were really only making ends meet while starting their own businesses.
Whether code or nocode, if your solution can solve a valuable problem, u can make money.
Nocode tools are just equipments like your screw driver, cutter, etc. This question is like asking whether a repairman can make money. Of course he can!
in architecture it is grasshopper for rhino, in sound it is puredata or max/msp, in business SAP is pushing this since the 90s. with the idea to enable business to implement things w/o the need of developers: (1) brf+ to implement business logic, (2) the new integration product "cloud plattform integration" to integrate via flows (3) sap crm aet to create crud functionality. in some way it always fails. the best thing about having code is the versioning, the things you can automate.
Betteridge's Law would have saved me some time. The answer is no, not really; the only company doing well according to the article is Lambda School, and as we've explored here before, their money-making schemes have nothing to do with no-code tools and everything to do with scamming students.
This kind of process has decades of predecessors, from dbs like Delphi, Excel, to Emacs in the ‘70s to (so it was claimed at the time) FORTRAN.
Is “no code” meant to somehow imply something more?