Your developers have a two-year backlog, and the business is building workarounds in spreadsheets. Here are five real enterprise apps that got built anyway — by the people who actually needed them.
App development without coding has moved well past the “simple form on a website” stage. The examples below come from regulated industries where the stakes are real: healthcare, financial services, logistics, and government. Each one was built by an operations manager, a compliance officer, or a department head — not a software engineer. Each one is in production today.
The pattern across all five is the same. The bottleneck wasn’t capability. It was security architecture. Specifically: what happens when you add AI to an app that touches sensitive data, and who is accountable when something goes wrong.
The Five Apps and What They Actually Do
1. Incident intake at a regional hospital network. A compliance manager built a structured intake form that routes patient safety incidents to the right department, generates a preliminary summary using AI, and triggers a notification chain — all without touching the EHR directly. Built in eight days. The hospital’s IT team spent another three weeks on access controls before it went live, which is exactly how it should work.
2. Vendor risk scoring at a mid-size insurer. A procurement lead built a tool that pulls responses from a vendor questionnaire, runs them against a rubric the team defined, and outputs a risk tier with a plain-language rationale. What broke: the first version let AI access the full vendor database to “contextualize” scores. That got shut down immediately when IT reviewed it. The final version uses a scoped data connection with read-only access to a specific table.
3. Field inspection logging for a utility company. A field operations director built a mobile-friendly app that lets technicians log inspections by voice, converts the audio to structured data, and flags anomalies against a maintenance schedule. The AI component is narrow — it classifies, it doesn’t decide. That distinction matters for liability.
4. Grant reporting at a state agency. A program officer with no technical background built a reporting tool that pulls expenditure data from the agency’s financial system, drafts narrative sections of grant reports using approved language, and flags gaps where supporting documentation is missing. This one is worth noting because the no-code platform alone couldn’t have done it — the AI integration required IT to configure a secure API connection and define exactly what data the model could see.
5. Client onboarding triage at a wealth management firm. An operations manager built an intake workflow that collects client information, runs a preliminary suitability check based on defined criteria, and routes to the appropriate advisor tier. The AI summarizes but does not recommend. That’s a deliberate design choice with compliance implications, not an accident.
What Broke (and Why It Was Predictable)
In four of the five cases, the first version of the app had an AI security problem. Not a catastrophic one — nothing leaked, no one got fired — but the kind of problem that would have become serious at scale. Overly broad data access. No audit trail for AI-generated outputs. Model outputs treated as decisions rather than inputs to decisions.
This is the actual hard part of app development without coding. The no-code platforms handle the interface and the workflow. They do not handle the AI governance layer. That gap is where enterprise deployments stall or, worse, go live with exposures nobody noticed.
The grant reporting app is the clearest example. The program officer connected the AI tool to the financial system using admin credentials because those were the credentials she had. IT caught it during review. A scoped service account with read-only access to specific tables replaced it before launch. That’s not a no-code failure — that’s a process working correctly. But it only worked because IT was in the loop before go-live, not after.
Peridot’s position on this is straightforward: AI in enterprise apps needs a control layer that operates independently of the no-code platform. The platform governs the workflow. The control layer governs what the AI can see, what it can do, and what gets logged. When those two things are conflated, you get security decisions made by whoever built the app — which is usually someone whose job is not security.
What the Security Architecture Actually Looked Like
Across these five apps, the security patterns that worked had three things in common. First, data access was scoped at the infrastructure level, not the application level. The AI model didn’t get access to a system — it got access to a defined, auditable subset of data from that system.
Second, AI outputs were logged and attributable. Every AI-generated summary, score, or classification was stored with a timestamp, a model version, and the input that produced it. This matters for regulated industries where you need to explain a decision six months later.
Third, the human decision point was explicit. None of these apps let AI take an action. They let AI inform a human who takes an action. That’s not a limitation — it’s a design principle that keeps accountability where it belongs.
The hospital and the wealth management firm both ran their apps through Peridot’s infrastructure layer, which handled the scoping and audit logging without requiring the business builders to configure it themselves. The utility company and the insurer had IT build equivalent controls natively. The state agency used a hybrid. The mechanism varied. The requirement didn’t.
What IT Directors Should Take From This
The question is not whether your business users will build apps without developers. They already are. The question is whether those apps will have a security architecture or whether they’ll have the security architecture of whatever default settings came with the platform.
App development without coding is a real capability shift, and blocking it to preserve control is a losing strategy. The business will find a way, and you’ll inherit the risk without the visibility. The better position is to define what a safe deployment looks like — scoped data access, audit logging, clear human decision points — and make those the entry criteria for any AI-enabled app that touches enterprise data.
These five apps are in production because the people who built them and the IT teams that reviewed them agreed on that criteria before launch. That agreement is the actual product. The app is just what it enabled.
The backlog is real. The workarounds are worse. Governed no-code deployment is not a compromise — it’s the architecture.