Hey everyone!<p>I'm Aaikansh, part of the Growth team at DronaHQ, a low code app development platform.<p>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?<p>I would seriously love to hear what you guys think!
Vendor lock-in and business continuity would be my top concerns from a high-level perspective.<p>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.<p>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.
Asking developers about low code is a little like asking carpenters what they think of IKEA.<p>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.<p>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.
I've been in some really bad situations related to low-code products.<p>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.<p>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.<p>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.<p>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.<p>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.
I’ve worked at places where we’ve been building very speculative high-tech platforms, others where we built a few complex apps for the long term over the course of years, and others where we knocked out a stupendous number of simple to moderate complexity applications (70 in 8 months!) for a wide range of customers.<p>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.<p>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”.<p>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.<p>Look up my profile and shoot me an email, I’d love to talk some more.
I personally try to to avoid to work with low code and prefer to work with code. But I understand that for some people low code can be better and I do not see anything bad with it. Below is some information why I do not like low code:<p>* Inability to easily run everything (all code) and see what does not works.<p>* Possibility of accidently click something and unintentionally make undesired change that may go unnoticed.<p>* 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.<p>* Usually the low code systems have limitations of what can be done and it is very hard to overcome the limitations.<p>* 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.
It would be tough to build a business or a startup on top of a low/no code platform.<p>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.<p>How well will it scale? What will the costs be at scale?<p>I can't imagine trusting a platform holding all your cards like that.<p>There are too many reasons to build on open source and own your own destiny.<p>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.<p>I just can't see going all in on a no/low code platform of any kind.