Building your own field app with generative AI: good or bad idea?

It's simple enough for a logistics manager to describe what they need in a single sentence to Claude, ChatGPT or Gemini. Thirty seconds later, an interface appears: fields, a “submit” button, a document to attach. It works. The paper form is dead, and nobody had to call IT.

This scenario is no longer an isolated anecdote. It's playing out today in a growing number of businesses equipped with consumer-grade generative AI tools. The instinct makes sense: why wait six months and negotiate a development budget, when a prompt gets you a visible result in minutes? Indeed, use of generative AI has nearly doubled in the last six months, with 75% of global knowledge workers using it 1.

Case in point: this played out at scale at a leading European logistics group. Non-technical teams began building their own apps and dashboards with Gemini, without waiting for formal sign-off. Asked about it, the group's IT leadership never questioned its teams' ability to produce these tools.

Their concern lay elsewhere: governance and data consolidation – dozens of ungoverned artefacts, data that never rolled up anywhere, nothing that outlived its creator.

The CIO's diagnosis was blunt: a tool built alone with consumer-grade generative AI can be copied by anyone else – but it can't be governed. What IT can accept, on the other hand, is generative AI built on a governed platform.

Code was never the hardest part

You've probably already seen it work, maybe even built one yourself. Describe what you need to Claude, ChatGPT or Gemini, and you get a working app. That's not in question, and it isn't going to become less true: generative AI models improve every few months, and whatever gap still exists between AI-written code and hand-written code keeps closing.

The reality is that coding an app was never the hardest step in a field digitisation project. It's the most visible step, the one you can film in a three-minute demo. That doesn't make it the most decisive one.

Why? Because for an operational team, a mobile app isn't a screen that appears once. It must survive wear and tear: the departure of the person who built it, a warehouse with no signal, a phone OS update, a security audit, three years of company growth. Code generated from a prompt answers none of these questions. It simply raises them later – often at the worst moment, once nobody is left to answer them.

The iceberg hidden beneath every “homegrown” app

Generative AI produces a visible result within minutes: that's the tip of the iceberg, roughly 20% of what makes a field app actually work, over time, at organisational scale. The remaining 80% sits below the waterline, invisible in the demo – and it's exactly what builders underestimate the most.

Governance and key-person risk

An app built by one person, using their own Claude, Gemini or ChatGPT account, leaves the organisation with nothing to work from. No spec. No documentation. No second person able to take over if needed. Its only record is one individual's chat history.

As long as that person stays with the company, the app lives. The day they change roles or leave, the app is orphaned: nobody dares touch it, let alone develop it further, for fear of breaking a mechanism nobody really understands.

At organisational scale, multiply this by every employee who, one evening, decided to try a prompt to solve their own problem.

This is precisely the trend Gartner anticipated back in 2021 3:

This isn't a footnote. Every app built outside IT's view is another data silo, another reporting source that never rolls up anywhere, and another compliance risk nobody has assessed.

Here's the observation that shifted one CIO's thinking, from building in-house to a governed platform:

An app built for the office doesn't survive in the field

Consumer-grade generative AI produces what it knows best: “office software” interfaces – fields to fill in, boxes to tick, text to type. That's almost the opposite of what a technician, a delivery driver or a QHSE auditor needs in the field.

A warehouse operator wears gloves. A technician works in bright sunlight, on a barely legible screen. A delivery driver holds a parcel in one hand and their phone in the other. None of them has the time, or a free hand, to fill in a form designed like a spreadsheet.

What field work needs is the opposite of manual entry:

• Guided capture, where a barcode scanner,
• OCR or a vision scanner, replaces typing,
• and every step is designed to take two seconds with one finger, not a keyboard and a paragraph.

This kind of design can't be improvised in a prompt, or from behind a desk. It's built on years spent watching operational teams at work in the field.

Just as critical: reliability in real conditions. A demo runs on head-office Wi-Fi. The field means warehouse basements with no signal, rural rounds in dead zones, and teams who can't stop working because a request timed out. Offline mode isn't a feature you bolt on afterwards: it's an entire architecture (local storage, sync queues, conflict handling, partial-failure recovery) that can't be prompted into existence either. It must be built.

Find out how Chronopost uses WizyVision to carry out stock-takes of its refrigerated units

Updates, distribution, integrations, security: the rest of the iceberg

These first two points are the ones operational decision-makers underestimate most. But the iceberg goes further still, below the waterline.

Rolling a self-built app out to 50, 200 or 1,000 field devices means setting up a developer account, listing it on the App Store (iOS) or Google Play Store, and going through their review cycles every time it changes – or managing enterprise MDM distribution instead, with app signing and versioning either way. 

Maintaining it means:

• Shipping a new version without cutting off active users' access;
• Absorbing an OS update that breaks a dependency;
• Fixing a security flaw that can't wait for the next sprint.

On a governed platform, none of this is a new project: the app is already installed, and a new version is a configuration change, not a store submission.

Equally, an app that doesn't talk to any other system is little more than a form: without a connection to the ERP, WMS or reporting tools, the data it collects doesn't consolidate anywhere. It just adds to the pile of manual re-entry the app was meant to eliminate. And integration is precisely the work DIY never finishes: authentication, rate limits, error handling, evolving data schemas, monitoring – the list grows as the system does.

Security and compliance round out the picture: hosting, encryption, role–based access management, audit trails, certifications (ISO 27001, SOC 2...). None of this is a minor detail for an IT department in a regulated sector such as energy, healthcare, transport or finance.

It's why WizyVision holds ISO 27001 certification. We'll cover this topic in more depth in a future article dedicated to security and compliance.

In other words, homegrown apps, once built, don't just carry a set of risks – they also require IT's involvement to maintain, secure, keep compliant and develop further. An IT team that, more often than not, had no part in creating them in the first place. That's extra workload, by any measure.

The real test: what does the code look like a year on?

Let's assume, for argument's sake, that the generated code works perfectly on day one. It still has to hold up over time.

This holds for teams with code review, quality tooling and validation processes in place. It's necessarily more severe for an app built by a single business user, working alone, with no second opinion, no repository discipline, no review. The code works on day one. What quietly degrades is everything that has no owner.

A study published in July 2026 by GitClear and GitKraken 6, analyzing 623 million real code changes between 2023 and 2026, offers a useful data point here – including for professional development teams with proper tooling and discipline.

The real cost never shows up in the demo

Software engineering research has converged, for decades, on the same finding: initial development is never the dominant share of a piece of software's cost over its lifetime. Several analyses across the sector converge on a similar order of magnitude: maintenance is thought to account for 50 to 80% of a piece of software's total lifetime cost, against 20 to 50% for initial development, depending on context 4.

The Standish Group documents a related pattern in its CHAOS Report 5:

None of these costs shows up in a prompt demo. They show up, one by one, in the months that follow launch: as tickets, urgent fixes, and change requests nobody quite knows how to handle. The person most comfortable with the prompt becomes, in practice, the permanent maintainer of an app they never signed up to look after. It isn't written into anyone's job description.

The same prompt, a radically different “day two”

As already noted, AI is genuinely good at writing code. That's why the WizyVision admin console lets you generate an app from a simple description in natural language. The instinct to prompt is the right one. What changes everything is what it's built on.

Two identical prompts, two radically different outcomes, depending on what they're built on.

Sent to a standalone generative AI, with no platform behind it, a prompt that generates raw code leaves you with everything below the waterline:

• Offline sync;
• Distribution;
• Updates;
• Permissions;
• Integrations;
• Governance...

All of that becomes your problem, to build yourself, piece by piece, with no safety net.

But sent to the WizyVision console, that same prompt lands instead in an environment where offline mode, distribution, permissions, integrations, and governance already exist. Configuration becomes the documentation: the app is a declarative schema – fields, rules, workflows, statuses – readable and editable by anyone with the right access, rather than code whose logic lives in one author's memory. Access control, roles and audit trails are centralised once, rather than reinvented on every project.

Same prompt. Same starting instinct. But a radically different day two.

Comparison: a standalone AI-generated app vs an AI-generated app on a governed platform

Why choose a robust platform over an app generated in–house with AI? Here, criterion by criterion, is what sets an app built from a standalone prompt apart from one built from the same prompt but deployed on a platform designed for field operations.

When building your own app with AI makes sense

That said, there are situations where prompting your own app is the right call: 

• A genuine one-off, used once for a specific need; 
• A disposable internal tool, with no ambition to outlast the quarter; 
• A task with no field component and no offline requirement, simply replacing a spreadsheet.

In these specific cases, the time and cost of a platform may not be justified. So the question to ask isn't whether AI can build the app – in most cases, it can. The question is whether this app needs to outlive its creator, field conditions, and next year. If the answer is yes, the hard part starts exactly where the prompt leaves off.

Conclusion: code was never the hardest part

Next-generation no-code platforms and consumer-grade generative AI have one thing in common: they've put building a first version of an app within reach of any operational employee. That's not a problem to fight. It's a signal worth listening to.

If your field teams are already prompting their own tools, that's not insubordination: it's proof that a real need exists, and that your team's instinct is the right one. The point isn't to stop them – it's to give them something solid for that prompt to build on: an app that's governed, robust in the field, connected to the rest of your information systems, and built to outlast whoever created it.