Technology
In the context of migrating to a new web-based platform, a partner evaluated the use of a low-code platform for frontend development while developing the backend in-house. This case study explores the trade-offs associated with this approach as well as potential risks and suggests alternative solutions when applicable.
AUTHOR
João Nogueira
Solutions Architect
June 25, 2024 - 10 minutes read
Low code / no code platforms have been the digital holy grail for decades as a tool to democratise development of digital systems. Recent years have seen significant advances and developments on major players, including Mendix, Microsoft, OutSystems and Salesforce to name a few. They position themselves as a versatile tool for a wide range of applications that allow organisations to accelerate development cycles, reduce costs, and foster collaboration between technical and non-technical team members. Less tech-savvy members are drawn to the prospect of developing applications using a visual environment and easy to use ready-made building blocks.
While there’s a huge appeal to the promise of creating applications without the need for coding, low code platforms are not necessarily the right tool for every job and it’s worthwhile to consider the scenarios where they excel as well as the scenarios where they don’t.
In general, low code platforms can be the right choice in the following situations:
The applicability of low code platforms to solve business problems largely depends on the complexity of the problems as well as the expectation around the flexibility of the platforms - which typically have hard constraints on how to use them - and the existence or lack of technical skills in an organisation.
Through the use of pre-built components, drag-and-drop interfaces, and templates, low-code platforms have the potential to significantly speed up the frontend development process, fostering rapid prototyping, quick iterations, and faster delivery of functional user interfaces.
Changes to the UI can be implemented more rapidly, allowing for faster response to user feedback or market demands.
While development may be faster initially, customizations or unique features might take longer to implement than with traditional coding. The time saved upfront could be lost later when dealing with or circumventing platform limitations.
Rapid prototyping is useful; however, it might lead to premature commitment to certain design decisions. The ease of creating prototypes might discourage thorough planning and architecture discussions. The ease of making changes could lead to frequent, poorly planned updates.
Even without low code platforms, developing for frontend does not necessarily mean writing everything from scratch as templates for design systems such as Material UI and others are readily available (e.g. with create-react-app).
Non-technical team members can contribute to frontend development, potentially improving collaboration between designers and developers as well as providing additional availability of resources to develop the frontend application.
This can lead to a false sense of simplicity and ability to get work done properly. Non-technical team members might create designs or functionalities that are difficult to implement or maintain, skip consideration of corner-cases, security and performance best-practices, leading to technical debt or performance issues.
It’s worth noting that even though low-code platforms in theory require less technical knowledge, there is still an opportunity cost regarding the learning curve of the platform itself as well a cost to performing technical integrations with the custom backend which will require technical know-how to some extent (e.g. on HTTP APIs, form and response payloads, etc).
Low-code platforms often provide pre-built components and templates, ensuring a consistent look and feel across the application.
While pre-built components ensure consistency, this is not necessarily a good thing in isolation, as it can also result in a generic-looking application that lacks uniqueness and requires the programmer to stick to an inflexible UI over which he has no control over, potentially harming the end user experience.
Low-Code Platforms
Frontend Development
Rapid Prototyping
MVP Development
Business Workflows
Application Development
IT Strategy
Vendor Lock-In
Software Development
Digital Transformation
Technology
May 19, 2026
-
6 min read
How to Build the Optimal AI-First Engineering Team
This is not about which AI tool to pick. It is about how you build a team that can consistently deliver with AI, today and six months from now when everything has changed again.
I recently hosted a webinar with our CTO Francisco Velasco on this exact topic. We have 90+ AI-first developers working across 35+ Dutch tech companies. What follows is what we actually know from practice, not theory.
One disclaimer Francisco and I both agree on: what we share today may be old news in three or four weeks. The pace of change in AI tooling is that fast. We saw it that same morning with updates from Copilot and Codex. That is precisely why structure matters more than any specific tool.
Maarten Moen
Managing Director
Technology
October 30, 2024
-
15 min read
Scaling Efficiency in Nearshoring: Our Journey to Fully Automated Processes
As 25Friday expanded from a small startup to a growing company, they encountered operational challenges requiring a shift from manual processes to a fully automated, scalable framework. This journey, documented here, reveals the lessons, tools, and strategies that supported their evolution into an efficient, autonomous organization—serving as a roadmap for others seeking operational agility and seamless workflow integration.
Francisco Velasco
Chief Technology Officer