AI-built internal tools: keep, replace or rebuild?

In many companies, someone has already built a piece of software with AI. A coordinator described a request tracker to an AI app builder. A sales lead turned a spreadsheet into a small portal. It took days, it worked, and people kept using it.

That was a reasonable choice. A tool built quickly by the people who understand the work often captures the workflow better than a written specification would have.

The harder question arrives later, usually unannounced. The tool now holds customer details. Another team relies on it. Someone asks for it to be connected to the accounting system, or the person who built it is about to change roles. By then it is part of how the company operates, but nobody has decided what it is: an experiment, something to replace with a product, or a system the company formally owns.

This guide sets out how to make that decision. It starts by establishing two things, what the business relies on the tool for and who is accountable for it, then compares three paths: keep the tool on its platform with proper controls, replace it with an existing product, or rebuild it as a custom system. It also covers when the third path is worth its cost.

When a quick tool becomes part of operations

Treat a tool as part of operations, not an experiment, once two or more of these are true:

• People outside the original team use it. Other departments, partners or customers log in.
• It holds personal, customer or financial data. Names, addresses, contracts, prices, payment details.
• It makes or records decisions about money or customers. Approvals, assignments, quotes, refunds.
• Another system or process depends on its output. Reports, invoicing or a weekly meeting rely on what it produces.
• Only one person can change it. Usually the person who built it, often on top of their main role.

Two is a rule of thumb, not a legal threshold. Personal data on its own already brings obligations, and a single signal can matter if the tool supports something critical.

None of these signals means the tool was a mistake. They mean the business now depends on it, and that dependency deserves a deliberate decision.

Why the question is coming up now

Building software this way is no longer a fringe activity, and both the platforms and technology leaders have noticed.

On 28 September 2026, Lovable announced a way to deploy apps built on its platform into a company’s Microsoft Entra tenant, where staff sign in with their work accounts and the apps appear in the company’s app inventory. The Microsoft runtime behind it is in public preview, and Entra sign-in for the workspace is offered on Lovable’s Business and Enterprise plans. In August, Replit expanded audit logs and admin controls for its Enterprise customers. The direction is clear: platforms are starting to bring AI-built apps under the controls IT already uses, mostly on their higher-tier plans.

Technology leaders describe the same pattern from their side. In a Harris Poll survey of 685 CIOs in eight countries, commissioned by Dataiku and published on 24 September 2026, 84% agreed that employees are creating AI agents and applications faster than IT can govern them. In Retool’s June 2026 survey of 307 technology and security leaders, most of them at companies with 200 or more employees, only 5% were very confident they had complete visibility of the internal tools running in production. Neither survey covers Romania or focuses on smaller companies, and both come from vendors of governance or internal-tool software, so read them as a sign of direction, not as a precise measurement of your market.

Then there is the data. In late September, security firm UpGuard reported finding 16,326 databases on Supabase, a backend platform widely used by AI-built apps, with tables anyone on the internet could read; more than half showed signs of personal data. UpGuard traced the problem to configuration: tables created through Supabase’s API, the route AI coding tools typically use, do not get its row-level access protection by default. TechCrunch covered the findings. For a European company, personal data in a tool brings GDPR obligations however the tool was built.

First, establish what the business relies on

Before comparing options, answer six questions with the people who use the tool. An hour or two is often enough, and the answers usually narrow the choice to one or two paths.

Three paths, and when each one fits

The first two paths are often the right answer, and they usually cost less up front. Keeping a tool on a platform that now offers proper sign-in and audit is a legitimate decision, as long as someone owns it. Replacing it with a product is the better choice whenever the workflow is common enough that a vendor has already solved it well. Each path also carries a dependency: on the platform, on the product vendor, or on whoever maintains the custom system. Knowing which one you are choosing is part of the decision.

When a custom build justifies its cost

A custom system usually costs more up front than either alternative. It justifies that cost in specific situations:

• The workflow is genuinely distinctive. Your pricing rules, job types or approval paths are part of how you compete, and products force manual steps back in around them.
• It must exchange data reliably with your systems of record. Reading from a spreadsheet is easy. Writing correct records into an ERP, CRM or accounting system every time, and recovering cleanly when something fails, is where most of the engineering effort goes. A clean finish is not proof of a correct result. In ThinkingBox, a benchmark from researchers at Microsoft and three US universities, AI agents worked through simulated business workflows; in about two-thirds of the failed attempts, the agent finished normally, had already changed data and received no error. That study measured AI agents, not apps built with AI, but the lesson carries over: a workflow that “worked in the demo” says little about whether the records are right every time.
• Customers or partners depend on it. External users need access rules, support and availability. Some platforms and products provide these well; when yours cannot, at the level your customers expect, a custom system becomes worth considering.
• You need control over the roadmap, operation or ownership. The tool has become part of your product or service, and its future cannot depend on a platform’s pricing or priorities.

When a custom build is justified, the tool your team made is a head start. It shows how the people closest to the work want it to run, and real usage shows which parts matter. A custom system takes that as its starting reference and adds what the quick version left out: roles and permissions, the exceptions, data ownership, integrations, monitoring, backups and a way to recover. Whether any of the generated code is reused is decided case by case during discovery.

This is where our custom software development work starts. Discovery usually takes 1-2 weeks and defines the first release. A first working version typically follows in 6-10 weeks, depending on integrations and how much is still unknown. Your organization owns the code, documentation and project accounts.

A hypothetical example: the dispatch tracker

Take a company invented for this guide. A facilities maintenance business with about sixty people sends technicians to client sites. A dispatch coordinator built a job tracker with an AI app builder: client requests come in, jobs are assigned, technicians mark them complete. Within months, four teams use it and it holds client addresses and contact names. Finance now wants completed jobs to feed invoicing in the accounting system.

The dependency check. Dispatching now runs on the tool, it holds personal data, it needs to write to a system of record, and only the coordinator can change it. Four of the five signals apply.

The three paths.

• Keep it. Possible for dispatching, if the platform supports individual sign-in, access rules and export. Invoicing is the open question: keeping it works only if the platform can write completed jobs into the accounting system reliably, and someone owns that link.
• Replace it. Worth a real look: field-service products exist that cover dispatching and connect to common accounting systems. If one handles this company’s contract types without workarounds, that is the answer.
• Rebuild it as a custom system. Justified only if the company’s job types and contract pricing rules are specific enough that products push manual steps back in. In that case, the coordinator’s tracker becomes the starting reference for the requirements.

The example shows the reasoning, not a verdict. The right path depends on facts only that company has.

What to do this month, whichever path you choose

Four steps protect the business while you decide, and all four are useful whatever the outcome:

1. Name an owner. One person accountable for the tool, its data and its users.
2. Give each person their own sign-in. Shared logins make access impossible to manage or audit.
3. Confirm where the data is stored and who can read it, including anything left publicly readable by default settings.
4. Restore one backup as a test. A backup that has never been restored is an assumption, not a safeguard.

If the tool is heading toward customers or a wider pilot, our guide to what a vibecoded prototype still needs before it can run a business covers the readiness checks in more detail. If keeping or replacing the tool turns into a line in next year’s budget, the six questions in before approving your 2027 technology budget apply directly.

Questions buyers ask

Can we keep the tool our team built and just make it safer?

Often, yes. If the workflow is internal and the platform supports individual sign-in, access rules, audit logs and data export on your plan, keeping it with a named owner can be the right answer. Reassess when the tool needs reliable two-way integration with your core systems, or when customers start to depend on it, and check whether the platform can meet those needs before assuming it cannot.

If we rebuild it as a custom system, is our team’s work wasted?

No. The tool shows how the people closest to the work want it to run, and real usage shows which parts matter. A custom system takes that as its starting reference. Whether any of the generated code is reused is decided in discovery, case by case.

How long does it take, and who owns the result?

Discovery usually takes 1-2 weeks and defines the first release. A first working version typically follows in 6-10 weeks, depending on integrations and how much is still unknown. Cost depends on scope, integrations and data quality, and you receive an estimate for each phase after discovery. Your organization owns the code, documentation and project accounts.

If an AI-built tool already runs part of your operations

If you would like a view on your situation, use the contact form to send us four things: what the tool does, who uses it, what data it holds and which systems it needs to reach. We will tell you which of the three paths we would examine first, and what a discovery would need to confirm.