The \u201clow code\u201d sales pitch is seductive. After all, who wants to spec out a months-long software project to be handled by a large team of expensive, opinionated developers when just a few or even a business user will do?\nThe low-code movement that has been emerging, thanks to tools that offer intuitive interfaces for building software, is enabling developers to snap together applications with a few clicks and, at most, a few hundred keystrokes.\n[ Beware the 14 reasons why software projects fail and the leadership practices that could sink your software project. | Get the latest CIO insights direct, with our CIO Daily newsletter. ]\nBut with ease comes complications. Lurking behind these programming crutches and mind-reading interfaces are several dark secrets that take a little shine off the seductive promise of low-code development.\nVendor lock-in\nAs with many technologies, the amount of work you do with low-code tools is proportional to the control you have. By handing off much of the work to the tools, the more you rely on them, and the more control they have over your process. Over time, what once felt like a \u201cpartnership\u201d becomes a (potentially unhealthy) co-dependent relationship with their stack.\nThere are strategies for minimizing the lock-in that comes with using low-code tools. You can write your code to be more portable, isolating your business logic and then wrapping it with glue code that connects it with the local low-code API. Porting it to a new service is not impossible if you do a good job planning ahead. But notice how you\u2019ll still be moving to another service. If you want to bring everything into your own servers, well, you\u2019re going to have write the rest of the code eventually yourself.\nPrice control\nLike many businesses, cloud platforms will often offer low prices to lure you in and then raise prices when they can. Thanks in part to lock-in, once you build your system on their platforms, they control the prices. Unless you sign a long-term contract, there\u2019s no way to be certain what it will cost to run your product next year or five years from now, but if your low-code creation requires their back end, you can be sure they\u2019ll remember this at the bargaining table.\nThe trickiest examples of pricing include shifting the formula. A service that once charged by the invocation may switch to charging by bandwidth. Or maybe they\u2019ll offer some hybrid. The bean counters can run spreadsheets all day long, but you\u2019re still probably going to just go along with the price change because it\u2019s too much work to modify everything.\nBlackbox\nMost low-coders pay little attention to what\u2019s going on behind the curtain. The platforms are attractive because they free us from that worry. But sometimes you\u2019ll want to know, and there\u2019s a good chance you won\u2019t be able to find out. Maybe the code behind the curtain is officially proprietary. Maybe there are real secrets buried behind that API call, the kind that must be protected at all costs. Or maybe no one wants to answer your question because no one has made a decision and the lawyers gum up the works. Maybe their team finds you annoying.\nThis is especially tricky when regulators are involved. Banks, for instance, face questions about how they choose when to grant loans. An artificial intelligence service built into a low-code platform may be very savvy, but good luck telling regulators you have no clue what\u2019s going on inside.\nInefficiencies hide in the cracks\nIt\u2019s nice to hand over control to full-featured APIs, libraries and stacks, but often the code behind the curtain is much less efficient because it must be ready for many eventualities. Did some fool pass a null pointer? Are all the arguments for the function correctly formatted? These details can be checked again and again as your invocation works through all of the layers of the code. Low-code tools vendors must bullet-proof their wares because they don\u2019t know what some fool might do. All that bulletproofing may be wonderful technically, but just like an armored tank, it\u2019s generally much, much slower.\nLimited capabilities\nThe demonstration is usually awesome. The charming sales engineer creates a new, cute doggy dating site in just one line of code by invoking the createDoggyDatingSite function that just happened to be built into the framework.\nMost low-code platforms are a little bit more general, but the odds are that you\u2019re going to quickly exhaust the powers of the built-in functions. Maybe you want your site to handle dogs and cats while keeping them from mixing. Maybe it\u2019s an asymmetric relationship, say cats and gold fish, and the data structures need to keep their needs straight. The details are important to you and that\u2019s why you\u2019re building your app, but there\u2019s no way that any low-code company could anticipate all of them.\nSoftware can be flexible and adaptive to our needs, but we need to be in the loop. That is, we need to write the code that adapts it. The more flexibility we want, the more code we need to use to specify it. More code is not low code.\nMonoculture\nSome of the scariest bugs are the ones that we find in the most popular libraries. When someone found a problem with libssh, almost every Unix or Linux box in the server farm was at risk.\nSuccessful low-code platforms create a monoculture by design and the monoculture is wonderful until a problem appears and then everyone has the same problem. The network effects that the venture capitalists chase are not just for getting people rich. Sometimes everything falls apart together when a fatal flaw is found in the network.\nThere\u2019s no way to avoid this problem. The good news is that everyone has more of an incentive to fix the problems if we\u2019re all in the same boat.\nHomogeneity\nA few years ago, a clever car lover noticed that it wasn\u2019t so hard to build a car by calling up the car parts manufacturers, ordering their stock items and bolting them together. He spent most of his money creating a beautiful, curvy profile for the body but everything else was stock.\nOther car lovers noticed. Isn\u2019t that the door handle from a Volkswagon? Aren\u2019t the seats the same ones in a Porsche 911? Isn\u2019t the steering wheel a leftover design from Ford? Low-code projects end up generating the same effect. They end up feeling pretty similar to each other because the developers are working from the same bins of stock parts.\nIf the code is just there to do a job, say maintaining an inventory in a warehouse, the look doesn\u2019t matter. But if the software is part of your brand, well, your low-code software is going to feel pretty similar to your competitors\u2019.\nParalysis\nWorking with a powerful low-code platform is like playing in a garden. Everything is beautiful and simple \u2014 until you try to leave. The woods outside the garden are filled with darkness, uncertainty and doubt \u2014 and lots of work. If there\u2019s a built-in function for what you need, the frameworks are great but as soon as you want to do something different paralysis sets in.\nLow-code vendors like to tout their tools\u2019 openness. You can link in any code. But just because you can doesn\u2019t mean it\u2019s easy. Often the startup cost of figuring out the interface can be ten times more complicated than the simple feature you want to add. Spending hours, weeks or even months trying to learn how to extend your project is frustrating, but it\u2019s an accurate reflection of the investment you need to make in a platform. It\u2019s not that stepping out of the garden is so hard; it\u2019s that everything is artificially easy inside the garden.\nCopy cats\nIf it\u2019s easy for you to create it, it\u2019s easy for someone else to copy it. Low-code platforms tend to avoid exclusive relationships. If the software is going to support another business with its own competitive advantages, well, that\u2019s okay. But if creating the software is your business model, be ready for some competition.