The 5 no-code most typical mistakes and how to avoid them

I can’t count all the no-code tools I have played with. Nor can I count all the languages and libraries I have ever worked with.

But, here are the most typical mistakes made using no-code I noticed, from my relatively small point of view.

1) Bad understanding of database relationships, and how it will affect the business

Often, makers don’t think too much about how their data co-exist with each other. They’re not aware of how much this will slow them down in the long run, early bad decision with no-code aren’t less costly than with code. Some pay the price of such mistakes years after the fact.

💡

No-code creates technical debt, the same way actual code does.

Some tools, like Airtable, don’t help to make the right calls. Airtable, in particular, is one of the worst database I have ever worked with. While the frontend is just awesome, the backend is just as horrific. It feels like it’s been built by a team of drunk underpaid interns during a summer holidays. Simple things, like relationships, allow for many-to-many relations even when you specify you want a one-to-many relation. No other database does that, and for very good reasons.

💡

This is the issue I’ve seen the most, and it’s very difficult to address, because there is no “right way”. The right way depends on the business state at that time and how it might evolve. Also, it will almost always evolve differently from what you thought back then, as the business matures. Having someone experienced, who understand how the relationships work with the no-code tools you use (which are very different on how they usually work with code!), will be a game-changer. Bad database design decisions don’t wait years to bite back, a couple of weeks is enough sometimes to facepalm yourself with the “if I had known” feeling.

2) Choosing the right no-code tool, for the wrong job

This is no different from developers choosing “build the fastest compiler” using Node instead of Rust, because they’re simply “most familiar with Node”.

Tools are only great to use when used for the purpose they were created for.

For example, using Airtable when you need millions of records is a terrible idea that will either kill your business or force you to migrate when you need to focus on scaling.

It’s not because something is possible that it’s a good idea.

💡

When looking for no-code tools, make sure you have your “functional requirements” list prepared, with the “must-have” and “nice-to-have” carefully thought. This will tremendously help you eliminate plenty of candidates early, which will in turn save you a lot of time. Having a quick talk with expert who knows the ins-and-outs of a specific no-code tool can help you validate/eliminate candidates very quickly!

3) Not spending enough time analysing no-code tools to find “THE good fit”

Often, builders want to build, and build fast. But, as pointed out previously, whatever you build will only be as good as whatever no-code tools you picked for the job. Finding the good fit is crucial. And, because of how difficult it is to understand all the limitations of every tool out there, and taking into considerations that those limitations can change at any time, it is extremely difficult to be 100% sure the tools you picked will do the job now, in 6 months, and in 2 years. No one can know that.

In this aspect, open-source software (OSS) can be much more reliable than company-made tools. Not that it cannot die when you need to scale, but even if it does, it will always give you a way to self-host things while transitioning into a new provider. Company-made tools can die, and die hard, leaving you with no alternative than re-building everything at once using a new stack, which is extremely stressful, and often feels impossible.

💡

The time needed to make such an analysis must not be underestimated. The last time I had to do that, I spent 3-4 months POCing around with various tools, analysed around 30, tried around 12 and POCed about 6 of them, to finally make a conscious decision as to why we were picking those tools. Ironically enough, it was the very last tool that I found that fit our business the most, after 3 months of trying and failing. I’m glad I didn’t abandon this quest until I found what I was looking for, but damn that was hard on the morale.

4) Not using any convention, or poor-chosen ones

Bad conventions are even more harmful than no conventions at all. Conventions matter in the long run and save a lot of time, while avoid human mistakes.

Airtable, for instance, has very poor built-in conventions (none at all, actually). They don’t help settings any convention at all, and their “friendly” interface doesn’t help either. People think they’re writing casual text when naming tables and columns, and they aren’t aware of all the issues this might cause. Worse, Airtable encourages this by treating columns names as labels, and doesn’t allow making a difference between the “internal name”, and the “display label”.

Sure, naming your column companyName or nameOfCompany isn’t going to be much of an issue at the beginning, until someone else (or yourself!) have a change of heart and start mixing both naming conventions. From there, you’ll have a hard time finding your columns, and you’ll be more likely to make mistakes when writing automations, and those can have terrible side effects.

💡

In my small company, I am not the only one using Airtable, but all new columns go through my review. My teammates can add more columns as they want, but we usually agree on the naming of the new fields previously, during our “design” phase. When things need to be fast, they do so on their own, but ask me to review their naming. This might sound silly, but if we hadn’t spent that time on this, we wouldn’t be able to have the same naming convention across our 3 airtable database and more than 2000 columns. (I’m not saying we’ve done it perfectly, though, but we’ve highly reduced the technical debt on this side by doing it this way!)

5) Not documenting things, or failing at making it discoverable

Documentation is hard, so hard to write, even harder to make it right, and even harder to make if discoverable and actually useful for the people who need it when they need it!

It’s not for nothing that documentation is so bad for internal products, especially those written with actual code!

💡

As a consultant, I can tell you most of the internal projects, whether they’re built by “experts” or interns lack good documentation. Most of the time, that documentation doesn’t even cover the most basic of things like “what this project is for? what does it do?”. Documentation for no-code is not different, and, once again, no-code tools don’t always particularly help making things right.

Even when the documentation is there, well written and up-to-date, it’s no-use if the person who needs it cannot find it. It must be discoverable.

💡

This might come as a surprise for many non-developers, but the best documented projects out there often are open-source projects! Why? Because nobody will give a damn about a project if they don’t understand what’s it for and how to use it! That’s why OSS always have great documentation, because they rarely get famous when they don’t, no matter how good the software is!

Finding the right way to document your projects, one that works for everybody, is a challenge. It takes time, it often feels useless and a waste of time, but it if not done properly, it will slow down your scaling, not on the technical side, but on the human side. You won’t be able to bring in new people efficiently if things aren’t properly documented.

Also, it gets even harder when using multiple no-code tools, like Airtable, Zapier, Integromat, N8n, and having your whole business made of pieces from there and that. It makes things really hard to understand, and having an overview is quite a challenge.

💡

We document all our Airtable formulas and automations (Airtable, Zapier, Integromat) into a dedicated GitHub repository. It feels like a waste of time to keep that up-to-date constantly, but it saved us quite a few times, too. For example, when deleting/renaming a column in Airtable, it’s the only way to easily and quickly know what automations/formulas are affected. A simple “search in project” and we get the whole overview of every affected components. This gives me such a great piece of mind for maintaining things that I can only advise you to do the same, although I wish it was simpler and automated.

There are plenty of other “typical mistakes” with no-code, but this is my curated top 5. Don’t hesitate to share your thoughts and feedbacks!