Case Study on Low Code for Frontend Applications

Introduction

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:

• Need for a throwaway rapid prototype / MVP
• Developing customer facing web and mobile applications with basic requirements and simple interfaces
• Simple data visualisation and reporting needs
• Automation of repetitive tasks, internal workflows and business processes
• Educational tool to introduce basic programming concepts
• No internal development expertise

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.

Low Code Features Assessment

Rapid development & quick updates

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.

Risks and Notes

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).

Reduced technical barrier

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.

Risks and Notes

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).

Consistency

Low-code platforms often provide pre-built components and templates, ensuring a consistent look and feel across the application.

Risks and Notes

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.

Consistency can also be easily achieved by using a design system framework, such as Material UI, Mantine or Radix UI for example. In addition to design system frameworks, implementation consistency can also be ensured through the use of frameworks such as Next.js in the case of react (there are many other alternatives).

Cost-effectiveness

With faster development and less need for specialised frontend developers, costs can be reduced. In addition there may be maintenance savings since low code platforms often include built-in support, regular updates, and security patches.

Risks and Notes

Initial startup costs may be lower, but long-term expenses could increase due to platform licensing fees, potential need for specialised consultants, or costs and complexity associated with migrating away from the platform later if it no longer meets your needs.

Vendor lock-in is also an important factor, as low-code platforms have historically implemented significant price increases which are hard to negotiate against given the difficulty in moving away from them, whereas in the traditional application space moving from hosting provider, while a nuisance, is usually not a big problem.

In the case of low code platforms, it is essential to consider the Total Cost of Ownership (TCO) rather than focusing solely on initial startup costs. A true comparison between low-code and traditional development models requires accounting for several factors:

• Recurring platform costs - as they usually operate on a subscription model with recurring fees
• Specialised consulting services - for optimizations or customizations, especially if ongoing support is required
• Scalability costs - costs might increase depending on usage means that over time the platform costs may be substantial (e.g. based on users or other metrics)

Focus on business logic

Developers can spend more time on complex business logic in the backend rather than frontend implementation details.

Risks and Notes

Full focus on the backend might lead to neglecting frontend optimizations as the backend should be developed with (frontend) usability in mind. This could result in a suboptimal user experience or performance issues (e.g. no proper support for pagination, providing too little or too much information on the API responses, to name a few).

As a general approach, the frontend should strive to be as simple as possible, centralising complexity on the backend services, however, having the ability to cooperate with the frontend on the implementation is invaluable in terms of flexibility and capability of implementing a solution that is architecturally sound, performs and scales well.

It’s also important to note that, while complexity might be hidden by the backend, the frontend also needs to be implemented according to the relevant business logic, hence the need to know and understand it does not disappear by using a low code platform.

In addition, while business logic is indeed a critical aspect of any application, there are also other non-functional requirements that are essential for a successful application such as scalability, performance, usability and observability to name a few over which there is little over control in the case of low code platforms.

Reduced need for specialised frontend developers

Not requiring specialised frontend developers on the team has the potential to either reduce overall the team size or allow it to focus on their current (backend) activities instead of having to worry about an additional piece of software.

Risks and Notes

It can lead to a skill gap in your team. If you need to move away from the low-code platform or handle complex frontend issues, you might lack the necessary expertise in-house and face communication challenges such as. frustration of the technical team members communicating requirements and contract specifications to non-technical parties.

In addition, any updates, bug fixes, and new feature releases are controlled by the vendor, which may not align with internal development timeline or priorities.

Not having dedicated frontend engineers will pose a challenge to the team as ultimately there needs to be a strong (technical) alignment between frontend and backend implementation, regardless of the platform in use.

Additional Considerations

In addition to the identified risks, it’s also important to consider how the application building process using a low-code platform will align with internal development processes, and how it will affect expectations regarding development cadence and coordination. This might mean that the team may need to redesign its development process to accommodate the low-code platform's workflow.

Typically, frontend and backend development efforts need careful synchronisation to ensure proper feature validation and testing before deployment and client release. In practice this means that there is an expectation around testability of the features (which can be hard to automate on low-code platforms) as well as on the processes that need to be followed before a feature can be made available to end users. In practice this might mean that the development process requires features to be available for testing and acceptance environments, which don’t always exist out of the box on low code platforms. Also, since development happens externally to internal CI/CD systems it may be very hard to impose checks and rules regarding security, version control, code style and other internal best practices and information security requirements.

From an operational perspective, it should also be noted that adopting a low-code platform introduces another system that requires maintenance, monitoring, and financial investment.

Conclusions

Low-code and no-code platforms offer an enticing opportunity to reduce dependency on software developers and allow less tech-savvy individuals to create fully-fledged applications. Key use cases include rapid prototyping and MVP development, creating basic applications, implementing business workflows, and automating repetitive tasks. However, their effectiveness depends on the complexity of the business problems, required flexibility, and the technical skills available within the organisation.

This assessment reveals several potential benefits but also draws attention to associated risks:

• Low-code platforms can speed up frontend development and facilitate quick updates, but customizations may take longer - or be outright impossible -, and frequent changes can lead to poorly planned updates and deployments.
• While they reduce the technical barrier by allowing non-technical team members to contribute, it can result in designs that are hard to maintain, have performance issues and a suboptimal user experience.
• Long-term costs and vendor lock-in are significant risks.
• Adopting a low-code platform may impact internal development processes, requiring careful synchronisation between frontend and backend efforts to ensure proper feature validation and testing.

It is important to note that the choice between low-code platforms and traditional programming does not eliminate the complexity and effort involved in proper planning, clear definition and refinement of technical and business requirements, testing processes, quality assurance, information security, and stakeholder alignment. These elements are crucial to the successful deployment of an application and remain constant regardless of the coding approach. Low-code platforms address the coding aspect of application development, which is generally just a subset of the total effort required. All other aspects of the development lifecycle demand the same level of attention to ensure a successful outcome.

Weighing the pros and cons of low-code in this context, where a development team already exists, though primarily focused on backend development, the recommendation is to implement a custom frontend using off-the-shelf frameworks and design systems. While there may be a need for specialised frontend work to bootstrap the project, ensure that all technical enablers are properly set up (internationalisation, linting, selection of a design system, etc.) and there’s a proper frontend architecture in place, it is expected that backend developers with minimal knowledge of frontend technologies and a willingness to learn beyond their area of expertise will also be able to contribute and modify the system as needed leading to a collaborative development environment.

From an operational perspective, monitoring and deploying a static frontend application - as opposed to a backend application whose code runs on servers - should not present a challenge to the existing IT teams.

This approach allows partners to maintain control over their development processes, implement complex use cases without having to circumvent limitations of low-code platforms, avoid vendor lock-in, and ensure that both frontend and backend are optimised for performance and user experience.

As you ponder about Technology and explore the potential within your software development practices, remember that you're not navigating these waters alone. We, the 25Friday team, are dedicated to guiding tech companies through the maze of technical strategy. With our expertise in consultancy and nearshore development, we partner with organisations to fine-tune their vision, align their teams, and craft strategies that resonate in today’s dynamic market. Reach out to us, and let's work together to turn your challenges into successful ventures that stand out in the tech landscape.