Low Code As It Is: Your Best Pick for PoC and Concept Testing

Symfa is a custom software development company which has also products of its own. Those are the solutions that we use internally and offer in the B2B market. One of such products – HQ ERP – in its first version was written on a low-code platform. 

The year 2017. Code On Time is a very popular low-code platform. So we decided to take our chances and give it a go with our first version of the HQ ERP.

The endeavor had a dramatic, although predictable ending. At some point, we hit a wall. The second version of the HQ ERP was to be rewritten on a custom code from scratch.

Did it change a thing about my attitude towards low code/no code platforms? Not a bit. Low code wasn’t to blame as far as our story goes. It gave us tremendous value instead.

So, as you already know, the second version of the HQ ERP was redone from scratch on custom code. But I wasn’t disappointed – not a tiny bit – about the no code/low code movement. Without it, we wouldn’t have learnt the things we learnt. This is exactly what I shout from the rooftops to our clients – don’t think twice about using low code for prototypes, concepts and ideas testing. Don’t waste your time on a detailed solution only to see your dreams shutter. Whenever you feel confident about the path – you see that the prototype works and it brings the benefits you expect – go for the costly framework development. But don’t do this at the start of your journey. Use low code to make those beautiful mistakes.

Me, I’ve seen the good, the bad and the ugly about low code and have learnt how to apply the good part – well – for my own good. Say, a hesitant client approaches us with a project. They are not yet sure about giving us a chance as their vendor. What we do is develop a working prototype solution in almost no time using low code solutions to show the client that we’re a fit. We got your idea, we know what’s on your mind and – look – you can see with your own eyes we know how to do that. It sells, that’s what I know.

One can hardly develop a full-fledged product using low code. But here’s the thing – in 80% cases this isn’t even necessary. No one expects low code to be that good. That’s what I also know.

As I’ve already mentioned, businesses of all sizes use low code – an insurance major that opts for Outsystems, or a trading startup that goes for Bubble. And they all will have their own reasons for that.

• An insurance major uses Outsystems in order to meet a gazillion of their internal workflow optimization/automation tasks, without spending a two-year budget worth on them.
• Oil trading startup chooses Bubble so that they could showcase their idea before the investors, fast. Well, for now, as there are no investors, it doesn’t make sense to invest heavily into the prototype.
• Or a custom software developer, like us. Using low code, in 2021, we developed a relocation platform for our talents. The decision to use low code was made in order to gain velocity amid geopolitical uncertainty. To this day, we use the platform all right. No other tool would make us that flexible.

At this, low code isn’t a panacea for business, it’s just a convenient tool to use. Whenever we offer it to our clients, we try not to be too dramatic about the value it brings. What I always mention at the start is

• The functionality we can do using low code
• The way we’ll do it
• How much it will cost the client and 
• The limitations that such an approach imposes. 

Perhaps those limitations aren’t crucial at this stage for the customer. So yes, if you can tick all the boxes, we go for a low code. If not, no problem, let’s make it custom. 

What IS crucial is that the client makes an informed decision. Low code or custom code perform better under different conditions. Each case is unique and requires detailed consideration.

They say, there’s no such thing as a strong backend in low code. I say – you simply don’t know how to make it right using low code.

The problem often lies in backend developers. You see, they don’t like low code tools that much.

Low code skills don’t automatically make you super attractive to the HRs in the development market. Say, Code On Time (that one that gave us our first HQ ERP version) was the top choice in 2017. This platform met our backend needs alright. Sometimes it wouldn't go all smooth and we had to come up with workarounds, but it ended up just fine for us. Yet, if Max, the full stack engineer, would want to leave his .NET position and go work full-time as a Code On Time developer, he would soon deeply regret that. Since then, .NET hasn’t lost an inch in competition, and look where’s Code On Time now. It’s nowhere as promising a niche for the developer as a mature framework with a story to it.

That is how I see things from the engineer’s perspective. But I’m a businessman, a founder of an international company, so I mainly think the way the clients do. Low code was designed to close business issues. The developers, in their turn, see those issues differently. Say, they want to solve the task efficiently and refine their knowledge of the technology they used to do it. The technology that would keep them competitive in the market. You got my point, right?

Still, I’m an engineer myself and I cannot abandon that part of me. Low code solutions sometimes pose severe technical limitations. 

What if the form would open in two seconds instead of one?? (Just kidding. Usually those slight performance lags aren’t that important for the client).

Now back to real problems, where the low code platform wouldn’t allow you to implement the FUNCTIONALITY that your business needs.

Say, what if it doesn’t allow you to put that stamp in the lower right corner of the page? 

Or add a constructor inside the invoice item to make it more detailed? 

Low code would provide a simple table where you can still perform some sort of calculations, but oftentimes that’s not enough. If you want to go deeper into your invoice, play with the logic, add some custom components, it’s way easier with custom code. I mean, it still can be hard to do, but it’s way harder, if ever possible, with a low code.

Rumor has it, you should stay away from low code because of the vendor lock-in. For example, the hosting conditions with Bubble – $29 per month? Man, it’s a robbery! And you should be careful with those ownership terms, too.

What I say, though, is that it’s a huge mistake to imply that all low code systems are the same in terms of payment and ownership limitations. There are open source low code systems like Tooljet. It slightly lags behind top three low code market leaders – Outsystems, Appian or Power Apps (according to Gartner) – but you can safely run it on your servers and enjoy the ownership.

Rumor also has it that low code tools in the age of component-based development* don't make any sense. I say – go use component-based development! This is the right thing to do in 2023 to deliver high-quality apps quickly. However, sooner or later, you’ll hit the same wall that we did with HQ. In order to make the component work for you, you customize it, and not in a very fancy way, as those are already pre-built code sections you cannot fully own. In the worst-case scenario, you’ll have the same low-code Frankenstein. So why would you want to do that? There are tons of low-code opportunities out there that can do better – at zero cost or for money, depending on your financial situation.

Here’s my personal list of top four low code solutions. These are the tools that I used in a dozen of projects and that stood my test (and I’m no sweet guy when it comes to technologies). 

• Tooljet – free and open source. I like it because I prefer to be on top of things, in terms of ownership, code quality and functionality.
• Outsystems – one of B2B leaders. A great fit for complex corporate systems. Customizable and costly.
• Retool – a market leader that is nice to use and way nicer to pay for (as compared to Outsystems). Mostly suits the needs of smaller companies.
• UI Bakery – this is where my heart melts. I’ve been following these guys for a while and, honestly, they gave Retool quite a hard time recently. Young and ambitious, I wish them luck.

Well, given the above and my 20-year-long experience in software development, let me tell you something. Next time take your chances and make your prototype on a low code. For a final version of a full-fledged product you’ll most likely have to switch to a framework. This is especially true for external corporate product development (as compared to the product for internal use only). 

For concepts testing, theory verification in order to make it right in the final version, going low code in 2023 is a no-brainer. As right a thing to do as to see Paris once in a lifetime. And Paris is beautiful.