tekBlueprint

I’ve long wanted to share my thoughts on choosing between traditional, from-scratch development and development based on existing low/less-code platforms. Opinions vary, and some may have completely different experiences. Therefore, I won’t compare existing frameworks and platforms, in case anyone gets offended. The goal is to compare the approaches at a conceptual level.

No-code solutions are not included here, as they are more specialized and designed for use in very limited areas of application. Building universal solutions with them is difficult and not always practical. Again, there have been some unsuccessful examples of such attempts in practice.

Introduction

Companies have been undergoing transformation processes for some time now, with some replacing products from companies that have exited the market, while others are migrating their legacy solutions to a new tech stack (B2B, B2C). This poses a dilemma: whether to pursue traditional development or use a low/less-code platform. The answer isn’t always clear, and the wrong choice can lead to budget overruns, missed deadlines, or the creation of a product that’s unscalable. This also significantly impacts the architecture of the final solution.

Миграция со старых систем на новые, это отдельная тема и думаю её лучше выделить в отдельную статью. Пока речь будет преимущественно о разработке новых систем.

For clarity, I’ll only share relevant past experience as a starting point:

1. ~6 years, but a very long time ago, developing with Delphi. It was a classic RAD development tool with very fast release cycles. It was very popular in its time, and a lot of software was written in it and is still in use (mostly desktop applications). In my opinion, it hasn’t developed any equivalents in decades.
2. ~7 years – developing classic client-server web services. Everything is pretty much the same everywhere: one of the UI frameworks with a ready-made component library or one written from scratch, a backend from scratch or on an application server, and a DBMS.
3. ~1 year – developing an internal, closed platform tailored to the company’s needs. This is a mixed bag: a UI framework for development for external developers, a UI with server-side rendering for the platform’s administration needs, a platform backend, and a DBMS.
4. ~7 years of development on a low/less-code platform with our own tools.
5. And several more years of various projects with different tech stacks and development tools (Delphi, PHP / JavaScript / Java / C++, Java ME / Android / Swing / JavaFX, various UI frameworks in JavaScript, UE5 and many other different things).

So, there’s something to compare it to.

What are low/less-code platforms?

Low/less-code platforms are development environments that allow you to create applications with minimal coding. What typically distinguishes them from other low/less-code platforms is:

1. Most often, they rely on visual designers: a user interface editor, and logic configuration via forms.
2. Availability of ready-made components and plugins for extending functional blocks. For example, a plugin for working with analytical dashboards, reporting, and so on.
3. Pluggable or built-in business process management mechanisms. These can be either custom or based on existing BPMS engines.
4. Some platforms provide data model designers, or this is implemented using traditional coding methods.
5. Integration with popular external systems via ready-made connectors. This is not always available out of the box.
6. Built-in user management and access control mechanisms (RBAC, ABAC, RLS, etc.).
7. Cross-platform and adaptable user interface. It’s not always fully functional or high-quality, but it’s better than nothing.
8. The ability to develop using traditional methods. However, the degree of extensibility can vary from platform to platform, depending on the openness of its API.

There are actually quite a few such platforms on the market, both for on-premise deployment and available as SaaS.

RAD IDE

A brief digression into an era of forgotten technologies: Borland’s Delphi IDE was once very popular. It’s now owned by Embarcadero. The combination of a very fast compiler and a user-friendly IDE with a set of ready-made components (VCL) allowed developers to quickly churn out applications for virtually any task. It also had competition from Microsoft with its MFC in C++, but Delphi won out. As far as I know, Embarcadero now supports two main products: Delphi and C++Builder – Embarcadero Cross-Platform App Development Software. They have similar core concepts and functionality, but differ in their development languages.

At the time, it seemed that nothing was more effective in terms of development speed than Borland’s products. But, in my opinion, they were ultimately undone by sluggish decision-making and poor strategic planning. Off the top of my head, I can recall the following:

1. At that time, there were clear problems with the lack of good support for cross-platform development. Windows was the primary platform. Unable to find an alternative, development shifted to other technologies: QT/wxWidgets, .NET, Swing, and the web. There were many different ones, and I can’t remember exactly. Borland missed this opportunity, and Delphi’s relevance significantly declined. Lazarus (https://www.lazarus-ide.org) was also a free cross-platform alternative, and it’s still alive and well.

2. Failed attempts to enter web development; their forays into web development didn’t take off. I don’t even know now if they have anything left, but that niche was also lost.

3. Their entry into mobile development was too late, and the process itself dragged on. Ultimately, they gave way to competitors, particularly Android.

4. Bugs, deteriorating UX, and backward compatibility issues. I don’t know if it was their internal chaos or something else, but new versions were becoming increasingly heavy and problematic. Many simply didn’t upgrade, including myself, which also negatively impacted the product as a whole.

What made Borland and their tool/platform so compelling:

1. Superior application build speed and debugging ease. I think it’s unrivaled even now, and I suspect it will never be comparable.
2. A rich palette of visual components to suit any imagination. And the ability to easily write new ones, which is what I did for my projects. Plus, there were very good libraries from third-party developers. This greatly helped reduce development time.
3. Application execution speed–these are native applications, without any VM/GC/interpreters or other junk typical of a modern development stack.

Judging by the Embarcadero website, they now offer a tool for fully-fledged cross-platform development—Windows, Android, iOS, macOS, Linux, in Delphi or C++. But I haven’t used it myself for a long time, so I can’t comment on how good it is now.

As for long-term support, even after 25 years, there remains a fairly large pool of applications written in Delphi that are quite functional. Some are trying to migrate them to newer tech, not always finding a suitable replacement. The main problem is that there’s no one to support them, there are no Delphi developers, and we’re aging :)

To sum it up, Delphi is an old but good example of a successful RAD IDE, and indeed a complete platform for Windows development in the 90s and early 2000s. Modern counterparts are similar and borrow some successful ideas from Delphi (like components and plugins), but have moved away from desktop applications and toward web services.

Traditional development

Companies developing their own products often create specialized frameworks and platforms in-house, tailored to their internal needs and standards. These frameworks themselves may be based on existing frameworks, both for the backend and frontend. It’s safe to say they’re creating an internal platform on which to subsequently develop their own products. I wouldn’t say this is an easy path; there are plenty of pitfalls. The requirements for the qualifications and professional knowledge of the team, which will initially define the foundation, are particularly high. Furthermore, a long road of evolutionary development awaits, with careful adjustments to the tech stack and architecture. Such projects can often end up in production hell, which is difficult, but not impossible, to escape.

Such examples include points 2 and 3. They were developed over a long period, taking into account the product’s needs. There were growth challenges, but these were gradually adjusted and evolved. Yes, there were some disputes and conflicts among stakeholders, which is inevitable. Overall, I can’t say there were any moments when insurmountable obstacles arose and progress was impossible. There were always options for growth, without strict external restrictions.

Traditional development is justified if:

• You are creating a solution with a long-term perspective, where architecture and scalability are a top priority.
• Complex integration with internal systems is required. This is especially true if the interaction protocols or the systems themselves are proprietary and there are simply no available connectors.
• The project requires the development of unique processes specific to your business, complex data processing, or machine learning.
• Security, compliance with internal information security standards. The chance of receiving the solution in a ready-made form is practically zero.

Limitations and Risks

The first stage is always a complex process of developing the foundation, the building blocks upon which the rest of the solution will be built. The payoff will be noticeably delayed, and initially, it can feel like a black hole draining time and money. This also means that mistakes at this stage will have a significant impact on subsequent stages. Thoughtful planning and analysis of decisions are required here. An architectural committee and consideration of technical debt metrics are essential at this stage.

A professional development team is required, at least at this stage. I think it’s clear why. This is the foundation, and it must be done well. Any attempts to cut corners at this stage will have to be recouped many times over later.

Accept the fact that you will have to constantly maintain, update, and develop everything yourself. Otherwise, you will quickly fall behind current technologies, and problems with their implementation will arise. We don’t cultivate outright legacy software; that never ends well.

Also, don’t accumulate technical debt; you’ll have to pay it off anyway. It’s clear that you often need to get a product to market faster before your competitors, but you need to strike a balance. While you’re bogged down by endless errors and customer complaints, your competitors will overtake you or simply drop your services. And yes, this has happened in practice.

It’s essential to develop a culture of project knowledge retention and document architectural decisions. This is vital on long-term and complex projects, as people will come and go, but expertise should remain within the existing team or teams.

Low/less-code

I’ll start with some statements often heard from representatives of their low/less-code platforms. What they usually say is:

1. The fastest possible start, practically from day one. Everything is pre-configured and ready to go.
2. A working application within weeks/months. Quickly implement your ideas, quickly build and deploy.
3. Low entry barrier for developers, DevOps/SRE. Everything is ready, you just need to build it correctly.

The start is indeed quick and everything is ready. But this only applies to simple applications. This is typical readiness, based on certain abstract and general requirements. If the project requires something non-standard (for example, a complex UI), then a quick start won’t work. A preparation stage, a proof-of-concept, and an analysis of the usability of the chosen tool are necessary. From experience, points 1 and 4 have always been situations where modifications were required to meet the project’s requirements. And it’s highly advisable to do this early on in the project’s launch, to avoid ending up with a huge backlog of technical debt due for refactoring just a few months into development. For simple, single-function projects without any unusual requirements, a quick and painless start is truly possible. Done, deployed, and forgotten.

Rapid delivery is possible if everything fits together perfectly and no rework is required. But there’s a nuance, or rather, a question: “Whose hands can quickly implement the project: the vendor’s developers or the customer’s?” The correct answer is always the vendor’s developer, and of course, not for free. Yes, there are professional teams that will invest the time and effort to figure it out and implement it themselves, but you must have them. If you try to implement it yourself, you’ll find that you’ll first need to spend quite a bit of time learning the proposed tool. You’ll be lucky if the vendor offers training.

With a low barrier to entry for developers, the question is what constitutes a low or high barrier. As mentioned earlier, as long as you’re unpretentious and only use the out-of-the-box features, you’ll have virtually no problems. But that’s not often the case. And this isn’t just about the tool’s internal components (something might simply be missing), but also about how to fit the project into the required infrastructure and SLAs (availability, fault tolerance, and so on). You won’t always have everything perfect; you’ll have to make compromises. For example, the architecture and design of the chosen tool may simply not allow you to deploy and scale smoothly in K8S without some initial customization at the tool’s core level.

Limitations and Risks

I recommend a very thorough gap analysis of your needs and the capabilities of the vendor’s solution. Conduct internal R&D, don’t rely on others’ words and assurances. No platform offers every possible feature. These solutions are designed for versatility for a wide range of clients, not efficiency and a solution specifically for your needs.

Accept the fact that you may have to fix problems and support them yourself, not the vendor. This won’t happen right away, but it’s a high probability. This could mean a major redesign of your product or a lengthy migration process to new versions. Be sure to include backward compatibility and migration plans in your SLAs.

Consider a Plan B. Selecting an alternative vendor, organizing and training your development team, implementing parallel projects, and so on. Your business is now, in a sense, dependent on other people’s decisions, so keep this in mind.

There are also issues with technical debt here, but it’s already distributed between you and the vendor. You need a vendor with good terms in their technical support package.

Vendors aren’t always interested in adding the functionality you need to the platform. You need to be prepared to expand your development team and implement the functionality you need yourself. Or you can negotiate a separate fee with the vendor, which again isn’t always possible.

What and when to choose?

As I said earlier, this is a controversial issue. A preliminary analysis stage is necessary, preferably with R&D, after which an informed decision can be made.

A practical checklist before choosing low/less-code:

1. Functional Matrix – compare project requirements with the platform’s existing components.
2. Evaluate Resources – understand your team and budget.
3. Pilot Project – implement a small portion (10% of the functionality) and measure development time, performance, and limitations.
4. TCO Estimate – include not only licenses but also training, integration, and support costs.
5. Implementation Plan – this is actually quite important, including the availability of exportable artifacts (data models, business rules) and a migration roadmap.
6. Consult with an architect or technical specialists – as much as you don’t want to buy based on a pretty advertisement, the final decision should be left to the technical specialists who will be working on it.

When considered in terms of constraints and factors influencing the choice, it looks something like this:

If we consider the specific features of projects developed using one of the approaches, the following can be distinguished:

Conclusion

When choosing a low/less-code tool, it’s essential to carefully assess all risks and your capabilities. The consequences of poor decisions will be very costly, lasting for many years to come. It’s important to remember that:

1. There is no single solution. Choosing between traditional and low/less-code development is a trade-off between speed, flexibility, cost, and risk.
2. Thorough pre-project analysis is essential. R&D, PoC, and gap analysis help avoid costly rework.
3. Vendor-related risks should be addressed in the SLA. Support, backward compatibility, and migration terms must be explicitly stated in the agreement.
4. A qualified team is still required. Even with a low/less-code platform, specialists capable of integration, writing custom code, and maintaining the infrastructure are needed.

Final practical advice: If your project is in a “gray area” (unsure of the best approach), start with a pilot project. At the same time, begin formulating a technical/architectural solution based on it: CI/CD, monitoring, scaling, extensibility, and code standards. Based on the pilot’s results, you’ll be able to objectively decide whether traditional development is necessary or whether a low/less-code platform and its extensions will suffice.