From Lovable to a business-critical system: what comes next after vibe coding?

Lovable is an AI-based application development platform that allows you to build web applications and websites by giving the AI prompts describing what you want to do. As well as the user interface, the tool can generate, for example, a backend system, a database, a login system and integrations.

Lovable is currently one of the most prominent AI-based application development platforms. The same trend can also be seen in low-code and no-code solutions such as Bolt.new, Microsoft Power Apps, Bubble and Retool. While the tools and the ways in which they are used differ, what they have in common is that a company’s own specialists can build functional applications with a significantly lower technical barrier to entry than before.

Someone who is very familiar with the company’s own processes can, for example, build an initial version of an internal tool, a customer portal or a new digital service without having to launch a traditional software project. The idea can be tested quickly, feedback gathered from users and unnecessary features weeded out before making any major investments. The starting point for a potential software project is also improved when there is already something tangible to build on.

So, with Vibecoding, you can actually get surprisingly far these days. At some point, however, the first working version may evolve into a system used to handle real customers, orders, personal data, production or other information vital to the business. At that point, the requirements placed on the system will also change.

The prototype made in Lovable is a good starting point

When a client comes to us with a Vibe-coded app, we don’t have to start the project from scratch. The first version of the app tells us a lot about what we’re aiming for.

User flows may already have been tested, the key screens have been finalized, and feedback may even have been gathered from users. At the same time, the company has gained an understanding of which functions are actually necessary and where the greatest benefits of the process lie.

The work already carried out also provides a solid foundation for the next stages of development.The existing application serves as a concrete basis against which business needs, technical requirements and the next stages of development can be discussed in considerably greater detail than would be possible on the basis of a mere list of requirements.

The code itself can also be utilized if its structure and technical choices are suitable for the intended future use. In some projects, a large part of the existing implementation can be carried forward. In others, the user interface may be retained, but the back-end system should be updated from the perspective of information security, maintainability and future development.

The next step becomes clear by examining what has already been built and what is required of the system next.

As the system becomes more important, the technical requirements also increase

In an internal company trial, a small number of users may well manage just fine with an application whose structure has evolved gradually through trial and error. The situation changes when the number of users increases and daily processes begin to depend on the system’s functionality.

The application collects real data. Users have different roles and access rights. Data needs to be transferred between CRM, ERP, financial management, e-commerce or other systems. The system is being developed with new features, and the technical solutions implemented during the first few months are beginning to influence how easy it is to make changes.

At the same time, the impact of errors increases. If a company’s internal system is temporarily out of action, the impact may be minimal. However, if the same system handles daily orders, production work orders or data required for invoicing, the problem will quickly become apparent in other areas of the business as well.

This also entails responsibilities relating to information security, data protection and regulation. The processing of personal data is subject to the requirements of the GDPR, and depending on the sector and the role of the system, NIS2 obligations, for example, may also need to be taken into account.

In the case of a service that utilizes artificial intelligence, it is necessary to assess what obligations the EU’s AI Act imposes on the system. At this stage, the value provided by the software partner begins to become apparent, particularly in terms of overall management.

First, let’s find out what’s under the hood

An AI tool can generate a large amount of working code in a short space of time. However, the functionality visible to the user only reveals part of the system’s technical state.

When we start taking the app further with you, we’ll go through, for example:

• the structure of the code and the technologies used
• libraries and external dependencies
• information model
• Login and access rights
• integrations
• error handling
• logging and monitoring
• backup and recovery

At the same time, an assessment is made of how easily another developer would be able to understand the project as a whole and continue its development at a later date.

This is particularly evident in a company’s internal coding culture. The original developer of an application is usually very familiar with its development history, the prompts and the solutions that led to the current end result. A year on, someone else may be in charge of development. In that case, a clear structure, documentation and comprehensible technical solutions will make the work considerably easier for those who take over.

A technical review also examines aspects that are not visible in the user interface. How have access rights been implemented? Is sufficient information logged to enable the investigation of problems? Where are API keys, passwords and other sensitive credentials stored? How is the system restored if something goes wrong?

The technical assessment also sets out how the existing implementation should be continued and what changes should be made before further functionality is built around the system.

The architecture determines how easily the system can be developed

In the first version, the most important thing is often to get the desired functionality up and running. As the system’s lifecycle extends, the importance of its architecture increases.

The responsibilities of the front-end, back-end, database and external services must be sufficiently clear to allow the system to be modified in a controlled manner. A good architecture helps to add new features without a change to one function causing problems elsewhere.

At the same time, future use must be taken into account. The number of users may increase, the volume of data may grow many times, and new integrations may emerge around the system. If these requirements are identified early enough, the technical infrastructure can be scaled to meet future needs without unnecessary over-provisioning.

Data, access rights and data protection must remain under control

In a company’s own application, data is rapidly becoming one of the most important factors. It must be possible to process data relating to customers, orders, products, production or other processes reliably, even when the system is being modified.

In addition to the data model, consideration must be given to backups, data migrations, log data and recovery from errors. If a major technical change is made to the system at a later date, the data must be transferred in a controlled manner.
At the same time, it is important to be clear about where the company’s data is located, who manages it and under what conditions it can be transferred to another environment.

If an application processes personal data, it is also necessary to understand the data lifecycle. Data cannot be collected or stored simply as a precaution, and the company must be able to explain, for example, why the data is being processed, how long it will be retained and how it will be deleted where necessary.

Access rights, information security and data protection evolve alongside the system

When an application handles data relating to customers, orders, products, production or other processes, data management quickly becomes a critical part of the overall system.

It is important to know where the data is located, who controls it and how it can be transferred or restored if necessary. In addition to the data model, consideration must be given to backups, migrations and how data integrity is maintained when the system is changed.

The processing of personal data entails its own set of responsibilities. A company must be able to answer at least the following questions:

• What personal data is processed, and on what grounds?
• Who has access to the data?
• Where is the data stored and for how long is it retained?
• What external services and data processors are used?
• How can data be restored, deleted or transferred if necessary?

Access rights must also correspond to actual job roles. One user may be authorized to view data, another to edit it, and a third to approve, for example, an order or a payment. API keys and other sensitive credentials must be carefully protected to ensure they do not end up being visible to users or in the source code.

The processing of high-risk personal data may require a data protection impact assessment. It is not recommended to put off addressing GDPR obligations, as the most serious breaches can result in fines of up to €20 million or four percent of a company’s global annual turnover.

The platform’s own security features are an important part of the overall solution, but the company remains responsible for the implementation of its own application and the processing of personal data.

When designing integrations, it is also important to plan for exceptional circumstances

A system that supports business operations rarely operates in isolation. Customer data may be fed into a CRM system, orders from an online shop may be processed, and invoicing data may be transferred to financial management. In production, the same data may be passed on to an enterprise resource planning (ERP) system or other systems.

In integrations, the technical work goes beyond the actual data transfer. Decisions must be made regarding what happens if another system fails to respond, if the same event occurs twice, or if the information received via the interface is incomplete.

In a well-planned integration, these situations can be handled in a controlled manner. A poorly managed error is easily noticeable to people in the form of extra administrative work, missing data or the need to manually resolve discrepancies between systems.

External services are also part of the system’s information security. For example, for organizations falling within the scope of NIS2, the cyber security risks associated with supply chains and service providers are also factors that must be taken into account. Therefore, when it comes to integrations, it is important to be aware not only of data transfers but also of the services on which business-critical processes actually rely.

Testing and monitoring provide assurance for continuous development

The completion of the first version usually marks the start of a new phase. Feedback is received from users, processes change and new features are added to the system.

Automated tests can be used to check key functions whenever changes are made. In this way, for example, order processing, invoicing or any other business-critical process can be verified before a new version is released to users.

In a production environment, it is also necessary to have visibility into what is happening within the system. Error logs, monitoring and alerts help to identify anomalies and determine their causes. At the same time, the development team gains insight into slow-running operations, recurring errors and technical issues that should be addressed next.

Logs and monitoring also support information security. If something unusual occurs, it must be possible to trace the sequence of events and access to data retrospectively. In systems subject to regulation, this may also form part of a company’s obligation to demonstrate how risks and anomalies are managed.

It is recommended to identify the dependencies of the platform and services used

A vibecode-based application is often supported by a number of external services. In addition to the development platform itself, services such as databases, authentication, hosting and AI may be used.

Using them is a completely normal part of modern software development. It is essential to know what the system depends on and what impact changes to the service’s pricing, terms and conditions or technical features would have.

At the same time, it is possible to assess who controls the source code, data and production environment, and how easily the system’s development can be continued on top of another technical solution, should the need arise.

Dependencies may also have regulatory implications. For example, a company needs to know where personal data is processed and what sort of agreements are required with service providers. The EU Cyber Resilience Act, in turn, introduces additional cybersecurity requirements for software products, placing greater emphasis on the management of components, vulnerabilities and updates.

Controlled technical ownership facilitates long-term development and reduces the likelihood of situations where a single tool subsequently comes to dictate business options.

A good partner also challenges the original idea

The value of a software partner does not, therefore, stem solely from the fact that someone implements the requested features. When an external team is brought in, it is also able to assess the solution from the perspective of user experience. In similar systems, they may already have seen what kinds of solutions work, where technical debt is likely to arise, and which features increase project costs in relation to the benefits they bring.

If artificial intelligence is to be incorporated into the system, the risks associated with the use case and any requirements under the AI Act can also be assessed at this stage. AI-assisted coding alone does not make an application an artificial intelligence system as defined by the AI Act; therefore, the decisive factor is how artificial intelligence is used in the finished service.

The aim is to devote the time and money allocated to development to matters that genuinely drive the business forward.

You don’t need to rebuild everything created in Lovable

There is no single formula for transitioning from a prototype application to production use. Sometimes an existing implementation provides a good foundation, and development can continue directly on top of it. In another project, the user interface and user flows may be retained while the back-end system, data model or integrations are enhanced. Sometimes the greatest value of a prototype lies in what it has taught us about users and business needs.

A complete rebuild may place an unnecessary strain on the budget. Building on top of a structure that is ill-suited to further development may, in turn, increase costs down the line. It is therefore recommended to understand the current implementation and future requirements before deciding on the next step.

At the same time, the investment required for the next phase usually begins to take shape. You can get a rough idea of the potential scale of your own project using a software development cost calculator.

Vibe coding and professional software development complement each other

Tools such as Lovable enable companies to experiment with and build their own solutions – something that, just a few years ago, would have required a software developer from day one.

It can also make the actual software project more efficient. Once a company has already tested the idea in practice, the software partner’s time does not need to be spent solely on figuring out what the service should look like or what it is intended to do.

Efforts can be directed toward the areas where external expertise brings the most value at this stage: architecture, integrations, information security, quality assurance, maintainability and the design of systems critical to business operations.

This also involves ensuring that the responsibilities that grow alongside the system remain under control. When a pilot project becomes a business-critical solution, information security, data protection, documentation and applicable regulations must evolve at the same pace.

We could therefore go a long way with, for example, the Lovable app, which is already quite well developed. We’ll then review the current implementation, business objectives and future requirements, and determine what to build on and what to strengthen for the next phase.

Vibe coding can therefore take an idea a long way very quickly, but once the system becomes part of day-to-day business operations, it must be accompanied by technical continuity, clear responsibilities and expertise, on which the solution can be safely developed over the years.