An app in a day.

Low-code means building applications with ready-made components and models, with the option to add code. No-code reduces the need to write code within its supported scope. Both approaches have boundaries set by the particular platform.

Vibe coding describes a working method: I tell AI the behaviour I want, check the result and request further changes. The term is also used more broadly, so here I distinguish it from engineering work in which a person additionally controls the architecture, understands the important code and verifies the security measures.

These approaches can coexist. AI can change a low-code application model, while code generated through conversation can run on a managed platform. I would compare the actual architecture and the team’s working practices rather than choose between those labels.

Power Apps code apps allow custom web applications to run on the Power Apps platform. Lovable allows a project’s code to be inspected, edited and downloaded, while Bolt combines conversational building with GitHub version control. A company can therefore use a generator while retaining access to code and change history.

I would separate the availability of a feature from claims about its effectiveness. A supplier’s statement that an agent can build an application does not establish the cost of adapting it to our process. That needs testing in our own trial.

I would consider Power Apps for forms and operational tasks in a company working in the Microsoft ecosystem. I would assess AppSheet for similar needs in a Google environment and applications based on tabular data. In both cases, the data, permissions and working practices must fit.

Bubble, Lovable, Bolt and Replit also deserve separate assessment. They differ in how applications are built, hosted and developed outside the tool. Bubble’s documentation distinguishes data export from application portability: leaving the platform requires rebuilding the application logic. That dependence can be acceptable when the benefits and commercial terms justify it.

I would consider tools such as Cursor, Claude Code, Codex and GitHub Copilot for a team developing its own code. The company then needs people who can assess changes, diagnose faults and take over maintenance. Possession of a repository does not provide that capability on its own.

This is how I would make an initial shortlist. A trial on a real process is needed to assess a particular product’s fit. I would not assume that an internal tool is automatically low risk. A panel changing production parameters may need more control than a public contact form.

I see the greatest opportunities in needs that are too small for a separate project yet consume several people’s time. Someone rekeys data between systems, a manager assembles reports from multiple files, or a team tracks exceptions through email. A bounded application can help if it has access to the right data and a clear scope.

A person who knows the process can build a prototype and explain the need sooner. IT then has a better basis for discussing integrations and rules. The team must agree when an experiment needs the involvement of those accountable for technology and data. I also discuss this cooperation in IT as a business partner.

Not every need warrants another application. In the fault reporting example, I would first check whether an existing system already supports the function. An additional tool may bring another user list, copy of data and integration to maintain.

In the fault reporting trial, I would sign in as an employee at each plant, a manager and an administrator. I would test reading and changing data, including direct requests outside the interface. Hiding a button does not protect an operation if the server still permits it.

Platforms provide security mechanisms that need correct implementation. Google notes that AppSheet security filters are not a complete security solution and that sensitive operations also need protection at the data source. Replit describes further responsibilities for application builders, including authorisation and protecting secrets. GitHub recommends reviewing and verifying code prepared by agents.

The autumn 2026 Veracode benchmark update reports improved security results alongside continuing weaknesses. It tested 18 models, four languages and four vulnerability categories. This is an assessment of specified code generation tasks, not a measurement of the proportion of unsafe business applications. I would not use it to predict the probability of our application failing.

I would therefore complement functional testing with checks on permissions, error handling, dependencies and recovery. Retries also matter for operations that write data: an interrupted connection should not create a duplicate order or approve the same operation twice.

The licence price or tokens used for a prototype provide only part of the picture. I need the cost of launch, recurring charges and maintenance work. I separately assess the cost of changing scope and leaving the solution.

Charging models vary. Replit describes publishing costs that depend on deployment type and resource use. For platforms, I also check users, environments, data and integrations. Administrative features may require a different plan from the one used for the trial. Running custom code outside the generator requires hosting, updates and error handling.

I do not assume that custom code will be cheaper or that a platform will cost more. A comparison should cover the same scope, load and availability requirements. I value existing staff time separately from additional expenditure to avoid double counting. The IT budget model helps document those assumptions.

Before choosing, I would ask for a handover exercise. A second person receives the documentation and recreates the application in an agreed environment. They check the data, sign-in, integrations and how to deploy a change. If the company wants the option to migrate, the exercise should also cover dependencies on supplier services.

Custom code may make leaving easier, but the database, user accounts, stored files and external services remain. Exporting the frontend does not automatically move those elements. Likewise, hosting a platform ourselves does not remove dependence on its licence and runtime.

A current example of product change risk is the retirement of Power Apps Vibe. Microsoft states that these apps remain accessible until 30 November 2026 and describes rebuilding them in other tools. This concerns the Vibe service, not the entire Power Apps platform. The migration guidance requires checking functionality and data connections again.

I would therefore want a specific exit procedure and an accountable person. A general assurance that “we have an export” leaves too many unanswered questions.

I expect further combinations of AI generators, visual models and custom code. This is my assessment of the direction suggested by current products. It does not establish which supplier will retain an advantage or how quickly costs will change.

Companies may gain more freedom to develop tools close to the process. IT teams can provide shared elements, such as data access and a controlled deployment method, while the business tests usefulness sooner. Companies will also need to retire applications that duplicate functions or fail to deliver the intended outcome.

I would not use a single productivity improvement percentage to justify such a programme. In its 24 February 2026 update, METR highlighted difficulties with participant selection and measuring work using newer AI tools. The outcome needs assessing in the team’s own conditions, including verification and rework time.

I would return to the fault reporting app with a specific plan: a bounded trial, checks on data and permissions, agreed maintenance and a handover to a second person. When those conditions are met, building the prototype quickly can shorten the route to a useful application. After launch, the process owner continues to assess its effect and the technical owner is accountable for the agreed maintenance.

I checked supplier documentation and announcements on 2 November 2026. They describe product features and limitations; they are not an independent comparative trial. Veracode supplies security tools and its benchmark covers the specified scope. The fault reporting example is hypothetical. The cost model’s starting values are assumptions unrelated to supplier prices.

Before your own trial, you can use the AI use case assessment record. It helps document ownership, measures and the rationale for further work. To discuss a particular process, describe the current workflow and the problem to solve.