Ask HN: Quick question for developers about low code/no code tools Hey everyone! I'm Aaikansh, part of the Growth team at DronaHQ, a low code app development platform. Now, I totally get that coding is a developer's playground, and we're not here to change that. But we're curious – what are your thoughts on these tools? Do they excite you, or do you have some reservations? I would seriously love to hear what you guys think! |
And as a developer I would be less than excited to take over the maintenance of low-code based applications, because well to a high-code person such usually web-app/saas based proprietary dev environments feel like a straitjacket. And anyways you'll likely be asked to jump in when the limits are reached and all extension efforts are uphill battles.
If you get the handover out of the low-code tooling to a "standard" development tooling (meaning something text-based in a non-proprietary programming language that I can edit in a IDE of my choice and have under proper version control) smooth, I'd be listening.
Speaking of solutions, that's where low code/no code comes into play. It's designed to break down those barriers and offer flexibility. With the right platform, you can avoid being boxed in by proprietary environments and have the freedom to transition quickly when needed.
Here's the thing about a product like yours. If you're going to expect developers to use your tool, you need to solve the problems developers don't want to do themselves. For example, I like building UI components, so I would never use a platform that forced me to choose from their list of components. For a low code tool to be worth it, it needs to replace a part of the job that I hate, not replace a skillset that I've been lovingly perfecting for years. You need to make it so I don't have to learn something boring, not make all my knowledge useless.
Your customer is not me. Your customer is a PM who can't build but can make the decision to adopt, or a small business owner who doesn't have money to hire real engineers. Just like how Ikea's customer base is largely made of people who don't already know how to build furniture.
We understand that developers have varied preferences and needs. Our aim isn't to replace your skills but to provide a tool that can take care of time-consuming and repetitive tasks. This way, you can focus on the more intricate aspects of your projects.
A. If the product isn't powerful enough, then users can't easily handle situations outside of the normal workflow or quickly change processes to accommodate business needs.
B. If the product is too powerful, then you need someone technical to work on it. And no technical person wants to work on it. Code is easier to write and more powerful than some convoluted SaaS low-code product.
The reason excel is the most popular low-code solution is because it's turing complete and non-technical people can do the bare minimum with it.
Any solution that isn't turing complete is going to run into problem A. Any solution that is turing complete, including excel, is going to run into problem B.
The best thing you can do is solve for A as much as possible, and let technical people under the hood as much as possible to solve for B. Don't try to force technical people to use the problem A workflow.
It's a very popular tool and plus its almost available in every organization and there's so much you can do much with excel that it literally blows my mind.
For example I read about a Japanese artist who used excel to create paintings
That last case has gotten me excited about no code because “excellence” in a place like that is standardizing what your team does to produce a good enough product with minimum effort, particularly no wasted effort.
I also spent some time looking at applications of “semantic technology”, ontologies, and ideas from the old symbolic A.I. with a business development guy and one thing we researched in depth was “low code”.
As a dev my concerns are: (1] low-code gets productivity by imposing defaults, if management/customers are happy with those defaults that’s great but if they insist they want something different that could eliminate many of the benefits or worse it could be a lot more expensive to get it right. (2) on successful projects devs spend much more time maintaining than building greenfield systems, if low-code is really going to be competitive in the long term it has to have a great story for that.
Look up my profile and shoot me an email, I’d love to talk some more.
I totally see your point about low-code defaults and the maintenance hustle. Balancing efficiency and customization is key, and yeah, keeping things running smooth is where the real game is at.
Writing to you now. Would be great to chat more.
* Inability to easily run everything (all code) and see what does not works.
* Possibility of accidently click something and unintentionally make undesired change that may go unnoticed.
* Inability to quickly scroll through all code and instead the need to click multiple menus (some of which can be accidently missed) to get understanding how everything works.
* Usually the low code systems have limitations of what can be done and it is very hard to overcome the limitations.
* New AI technologies can help you with code (I am not using them everyday but sometimes I am finding them useful) and with low code they are not much helpful.
But I believe many platforms now provide with debugging of your workflows or any controls that you have incorporated in your app. And when it comes to accidental changes, or undesired changes, now it is also possible through audit logs.
We at DronaHQ provides our users with these options
There is too much risk and lock in what if the platform raises prices, goes out of business, something happens where they lose your data/app.
How well will it scale? What will the costs be at scale?
I can't imagine trusting a platform holding all your cards like that.
There are too many reasons to build on open source and own your own destiny.
Granted sometimes a startup doesn't have a technical founder but there are still lots of decisions to be made and technical decisions for them to be successful.
I just can't see going all in on a no/low code platform of any kind.
Indeed, trust is a key factor. While it's true that concerns about price changes, platform stability, and data security are valid, it's also worth considering that we often rely on a multitude of applications and services to keep things running smoothly.
It's a balancing act between leveraging tools that can streamline processes and being mindful of the potential risks.