Yes. With AI, employees who know a workflow can describe it in plain words and get a working tool, often the same day. The risk is not their skill but the guardrails: employee-built apps have exposed data when access rules were left to the builder. Let employees build on one company platform that keeps every app inside the company, controls access by role, checks every piece for security and records who did what.
For most of the history of business software, the people who understood the work and the people who could build the tools were different people. The office manager knew exactly how job intake should flow. A developer, if you could afford one, had to learn it from her, translate it into code, and come back weeks later with something that was close but not quite right.
AI has changed who can build. An employee who knows the workflow can now describe it in plain words and get a working tool. The real question for an owner is no longer whether employees can build software. It is how to let them do it without creating risks you cannot see.
What has changed
Two things happened at once. AI got good enough to turn a plain description into a working app, and employees started using AI whether or not anyone approved it.
- In Pax8's October 2026 survey of companies with 5 to 499 employees, 67% of AI-engaged businesses had built one or more AI solutions now in regular use.
- PagerDuty and Wakefield Research reported in June 2026 that two-thirds of office professionals who use AI at work had used AI tools they believed were not permitted.
- Among professional developers, AI is already the norm. Stack Overflow's 2025 survey found 84% use or plan to use AI tools in their development process.
So employees are already building and already experimenting. The decision in front of you is whether that happens on a platform you chose, with rules you set, or on whatever each person found on their own.
What employees build well, and what to save for later
Employee builders are strongest where they know the process inside out and the stakes of a mistake are manageable. That covers far more ground than most owners expect.
| Good first builds | Build after a few wins | Bring in specialists or established systems |
|---|---|---|
| Job intake and tracking | Customer-facing portals for your own clients | Payroll processing |
| Inspection and checklist apps with photos | Tools that combine data from several departments | Payment processing and card data |
| Purchase and time-off approvals | Dashboards pulling from accounting exports | Systems that must meet a specific regulation you have not reviewed |
| Equipment and inventory logs | Scheduling across many crews and locations | Replacing your core accounting system |
| Simple dashboards from existing spreadsheets | Vendor and subcontractor tracking | Anything your insurer or auditor must sign off on first |
The middle column is not off limits. It is where builders go once they have learned how to describe a workflow, test it and switch a team over.
Where employee-built apps have gone wrong
The public failures in this category are not stories of employees being careless. They are stories of platforms that left the hardest part, access rules, to the person building.
Access rules left to the builder
Access rules decide who can see and change which records. When they are missing, anyone who finds the app can read its data. In March 2025, researcher Matt Palmer scanned 1,645 apps built with Lovable and found 170 of them, with 303 endpoints, exposed because database access rules were missing. The flaw was recorded as CVE-2025-48757 and published in May 2025 with a severity score of 9.3 out of 10. According to the National Vulnerability Database record, Lovable disputes the CVE, saying each customer is responsible for protecting their app's data.
That last point matters most for an owner. If the platform's position is that safety is the builder's job, then every employee you let build becomes your security team.
The problem did not go away
In August 2026, a scan published on reeve.page looked at 18,554 Lovable apps. Of the 3,553 where a database could be checked, 57% had tables readable without logging in.
Platform-level flaws
Sometimes the gap is in the platform itself. In July 2025, the security firm Wiz found a flaw in Base44 that let anyone with an app's public ID register on private apps, bypassing single sign-on. Base44 fixed it in under 24 hours, and Wiz reported no evidence of exploitation. The lesson is to ask how the platform enforces access for every app, not only how a builder configures one.
Tools that outlive their builder, or die with them
The quieter risk is ownership. A tool built on a personal account belongs, in practice, to that person. When they leave, the tool either stops working or keeps running with nobody who understands it.
The guardrails that make it safe
You do not need to turn employees into engineers. You need a platform and a few rules that make the safe path the automatic one.
- One approved company platform. Every internal tool is built in one place the company owns, not on personal accounts.
- Every app walled inside the company. Only people in your company can reach any app, and every request is checked.
- Invite-only access with roles. Owners, admins, builders and app users each get different powers, decided by your admin.
- Security checks on every piece before it is saved. Not a single scan at the end, and not left to the builder.
- A complete record of who did what. Every build and every change is traceable to a person.
- A named owner for every tool. Someone accountable for keeping it right, with a second person who knows how it works.
- Tools belong to the company. When a builder leaves, their access ends and their tools stay.
- Predictable costs. Builders can try, test and refine without a meter that punishes every attempt.
Choosing your first builders
Look for the people who already act like builders. They keep the master spreadsheet, they wrote the how-to document nobody else updates, and coworkers ask them how things work. They know the exceptions, which is where most tools fail.
Give them three things: time (a few hours a week during a build), a clear first problem chosen with their manager, and permission to say a tool is not ready yet. Treat the first build as a learning project as much as a delivery.
Example: a crew lead builds a daily inspection app
Example: a crew lead at a 40-person landscaping company is tired of paper inspection sheets that come back wet, incomplete or not at all. He describes a vehicle and equipment inspection app: each morning, every crew member picks their truck and trailer, answers a short list of yes-or-no checks, adds a photo for any failed item, and submits. Failed items go to the shop manager's list automatically. Crew members see only their own submissions; the shop manager and owner see everything.
He tests it with his own crew for a week, adds a check for trailer lights the shop manager asked for, and the owner rolls it out to all six crews. The shop manager now sees problems before trucks leave the yard instead of after they break down.
How an employee describes a workflow well
The difference between a tool that sticks and a tool that gets abandoned is usually in the description. A good builder covers six things, in plain words, before asking for anything.
- The people. Who starts the work, who acts next, who approves, and who only needs to see it.
- The information. The fields already in the spreadsheet or on the paper form, copied exactly.
- The steps. What happens first, next and last, and what each status is called.
- The rules. Limits, deadlines and approvals, such as "anything over $500 needs a manager".
- The exceptions. Cancellations, rejections, missing information and rush jobs.
- Done. What finished looks like, and who needs to be told.
A builder who can answer those six questions does not need to know anything about databases or code. Most of them answer the first four in ten minutes. The last two take longer, and that thinking is exactly what makes the finished tool fit the real work.
Employee builders compared with the alternatives
| Employee builds on a company AI platform | Hire a developer or firm | Buy off-the-shelf software | |
|---|---|---|---|
| Who knows the process | The builder, firsthand | Learned secondhand from your team | Designed around a generic version |
| Time to first version | Often the same day | Weeks to months | Days to set up, longer to adapt your process |
| Fit to your workflow | Exact, and changed as you learn | Exact, but every change waits on the developer | Your process bends to fit the software |
| Ongoing changes | The builder asks for them in plain words | New requests, new invoices | Wait for the vendor's roadmap |
| What protects your data | The platform's rules for every app | The developer's skill and habits | The vendor's security |
None of these columns is wrong in every case. For the everyday workflows that make up most of a small company's internal work, the first column wins on speed and fit, as long as the platform carries the security load.
A checklist before employees start building
- Name the approved platform and publish it in a one-page policy.
- Confirm every app stays inside your company and access is invite-only.
- Set up roles: who can build, who only uses apps, who administers.
- Pick two or three first builders and one workflow each.
- Agree which data is off limits until the team has a few wins.
- Require a week of real use by a small group before any tool goes team-wide.
- Set a monthly spending cap with alerts.
- Check that removing a person leaves their tools with the company.
Experienced AI users already work this way. Microsoft's 2026 Work Trend Index found that 86% of AI users treat AI output as a starting point, which is exactly the habit you want: build, test with real work, then trust.
How FORGE handles it
FORGE was made for employees who know the work to build the tools themselves, with the company in control. People describe a workflow in plain words; a panel of top AI models plans each tool, a dedicated AI crew builds it, and every piece is checked for quality and security before it is saved. Most teams have their first real tool the same day, as a web, mobile or desktop app.
Every app lives inside your company, people join by invite only, and roles for owners, admins, builders and app users decide what each person can do. A complete record shows who did what, and tools belong to the company, so they stay when a builder moves on.
A seat is $49 a month with 3 builds, app users are free, changes are a small fraction of a build and only count when something changes, and a build FORGE fails is free. Caps and alerts at 80 and 100 percent keep spending visible, and nothing bills by itself. Our team onboards every company with a workflow workshop that picks your first builders and first tools. Talk to us or see our security approach.
Questions people ask
Do employees need to learn to code to build software with AI?
No. On a platform built for business teams, they describe the work in plain words: who does what, what information is captured, what the rules are and what done looks like. The platform handles the technical work. What they need is a clear picture of the process, which they already have.
Which employees make the best builders?
The people who already maintain the team's spreadsheets, write the how-to notes, or get asked how things work. They know the process and its exceptions, and they care about getting it right. Job title matters less than curiosity and patience.
Who is responsible if an employee-built app leaks data?
The business is, in the eyes of customers and regulators. Some AI app builders state that each customer is responsible for protecting their app's data. That is why the platform you choose should enforce access rules for every app, so safety does not depend on each builder.
Should employees be allowed to build apps that touch customer data?
Yes, once the platform keeps every app inside your company, limits access by role and checks every piece for security. Start with internal workflows, then expand to customer data once your team has a few tools running well.
How do we stop employees from building on tools we have not approved?
Make the approved platform easier and better than the alternatives, publish a short policy naming it, and ask managers to bring tool ideas to it. Bans alone push the work out of sight.
What happens to the app when the employee leaves?
On a company platform, the app belongs to the company. Removing the person's access should leave the tool running and editable by another builder.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
