Your finance analyst has built a working app. Your operations manager has automated a process that used to take three people. Neither of them can deploy, monitor or secure what they have made, and neither of them thinks that is their problem.
This is one of the most common conversations Fifty One Degrees has with mid-market leadership teams, and the wrong answer in either direction is expensive. Shut it down and you lose the most valuable thing you have, which is people who understand the process and are motivated to fix it. Wave it through and you accumulate load-bearing software nobody owns.
Fifty One Degrees is a UK and US AI consultancy for mid-market businesses, and we work through an Embed Over Advise model: our senior practitioners sit inside client teams and build alongside them rather than delivering recommendations from the outside. Having scaled Fluro to 4 million credit applications per year, the pattern I recognise here is familiar. The constraint was never enthusiasm. The constraint is the difference between making something work once and running it every day.
The Short Answer
Do not decide who is allowed to build. Decide what each application is allowed to touch. Fifty One Degrees tiers every internally built application by what it touches, publishes the rules before handing out the tools, and hands anything customer-facing or money-touching to an engineer for the production build.
Why the Question Has Changed
AI has collapsed the cost of writing software. Not just the first version: the tenth version is cheaper now too, and so is the rewrite, and so is the thing nobody would have bothered building at all two years ago. That is the genuine shift, and it is why your teams are suddenly producing things.
What has barely moved is the cost of owning software once other people depend on it. Authentication, secrets management, environment separation, error monitoring, access control, and a named person who picks up the phone when it fails at five o'clock on a Friday. Some of that got cheaper as well, in that an agent will happily write your deployment configuration. But accountability does not compress. Somebody still has to be responsible when the thing six people now rely on stops working, and no model does that part.
So the asymmetry is not between the first build and the tenth. It is between building and owning. Your people are feeling the first half of the change and will be blindsided by the second.
The Two Questions Every Builder Is Actually Asking
Before you design a single control, understand what the people in your business are worried about, because it is not what leadership usually assumes. Two questions sit underneath almost every one of these conversations, and neither is often said out loud.
Will it hold up? If the team comes to depend on this, and it breaks, can anyone fix it? Nobody wants to build the thing that quietly becomes essential and then falls over on a Monday morning with its author on holiday. Anything genuinely impactful has to be scalable, sensibly designed and built on ordinary good engineering practice. Those requirements did not become optional because the typing got faster. AI changed who can produce code. It did not change what makes code survivable.
What am I not seeing? Nobody wants to take reputational or regulatory risk on a small automation. The fear is not of a control they can see and work within. It is of a rule they did not know existed, breached in a tool nobody thought was important enough to check.
Answer both and people build with confidence, which is the actual goal. Leave either unanswered and you get one of two failure modes: capable people who will not start, or, more expensively, cheerful confidence in something nobody has checked.
The rest of this article is the practical answer to those two questions.
Answer the First Question with One Road, Not a Policy Document
For "will it hold up", the answer is infrastructure rather than instruction. Build one constrained internal platform and let your teams build on top of it.
Not a sandbox that dead-ends, where good work goes to die because there is no route from prototype to production. Not a free-for-all on the corporate estate either. One approved way to authenticate users, reach approved data, store state, deploy, and be observed. Everything on that road is pre-cleared. Anything off it comes to engineering.
At Fifty One Degrees this is the AI Engineering Spine: version control, code review, tests, staged environments and rollback, with observability standards and reusable reference architectures on top, transferred alongside the permission to build rather than after it. It does more for both adoption and risk than any policy document, because it makes the safe path the fast path. The UK's National Cyber Security Centre makes a version of this point in its secure development guidance: technically capable people will find inventive ways around controls that get in the way of doing their job, so the goal is an environment that is both flexible and secure rather than one that simply forbids things.
Policies tell people what not to do. Infrastructure decides what they can do. Clients tend to measure the engagement by the applications that reach production. The road is the asset that produces the next ten.
Answer the Second Question with Rules, Published Before the Tools
For "what am I not seeing", infrastructure is not enough. People need to know the rules of the game before they start playing, and most businesses hand out the tools first and write the policy after the first incident.
An AI acceptable-use policy is worth having before anyone builds anything, and it needs to be readable by a finance manager rather than by a lawyer. Four things, on a page or two: which tools are approved, which categories of data may go where, what has to be reviewed by whom, and what is never permitted regardless of how convenient it would be.
Counter-intuitively, this matters most at the bottom tier, not the top. Tier 1 applications get scrutiny by definition. The personal tool nobody reviews is where an unwitting breach actually happens: a customer list exported into an unapproved service, a supplier contract pasted somewhere it should not go, a spreadsheet of employee data used to test a prompt. That is a data incident regardless of how few people use the tool, and it is entirely preventable with a rule the person would have followed happily had they known it existed.
The policy is not the brake. It is the thing that lets you take the brakes off everywhere else. Fifty One Degrees writes acceptable-use policy, data classification and a risk register as part of AI Enablement, and the honest reason to do it early is speed, not compliance theatre.
Tier Applications by What They Touch, Not by Who Built Them
Give your organisation three tiers, and let the tier set the governance rather than the job title of the builder.
Tier 3, personal. One user, read-only or disposable data, no external exposure. Anyone builds, nobody reviews, nothing is promised. It sits inside the acceptable-use policy and that is the whole of its governance. Most output lives and dies here, and that is a success rather than a waste. Deliberately, these things are not engineered to last, and trying to make them so is the most common way this initiative gets strangled.
Tier 2, team. A handful of users, internal data, no customer-facing output, no writes to a system of record. Built on the road, with a named business owner. Engineering reviews data access and deployment, and nothing else.
Tier 1, production. Touches customers, money, personal data, or writes to a system of record. A business-built prototype is welcome here as the specification. It does not go live without engineering ownership.
Almost every failure we are asked to clean up is a Tier 1 application being run as a Tier 3 application, because nobody drew the line while it was still small.
Settle the Decision Rights Before the First Line of Code
The most expensive failure in this whole area is not a breach. It is time, lost to a governance question that nobody owned.
Data residency is the recurring example. Not "is US processing acceptable in principle", but the specific version: does storage matter differently to processing and routing, which data classes are actually in scope, and who is entitled to decide. Because the question feels like a formality, it gets deferred, the deferral quietly becomes the critical path, and a build waits weeks on an answer that was never assigned to anyone.
What unlocks it is usually architecture rather than resolution. Build against mocked or scrubbed non-production data, keep live and personal data out of the contested path, and the tooling can be approved on that constrained basis without pre-empting the company-wide position. Where the answer turns out to be that live data genuinely cannot leave the UK or EU, that is a solvable design problem: Fifty One Degrees deploys Claude with UK or EU data residency via AWS Bedrock or Google Vertex, with role-based access and a documented data flow for the DPO. Whatever you decide, name what reopens it, because a decision that holds for mocked data usually stops holding the moment an application wires into live systems.
The same discipline applies to people, and here the trap is subtler: your most enthusiastic sponsor is often not your most empowered one. An energetic champion drives the programme, brings the ideas, builds the first prototype, and cannot approve anything. Nobody behaves badly. The structure is simply never stated. So state it, in writing, before the first line of code:
- Who signs off scope, and how quickly they can do it
- Who owns each application as a product, meaning who decides what good looks like
- Who approves tooling and data access, and what happens when that person leaves
The last one matters more than it looks, because change-control authority tends to sit with one person in a small IT function, and their departure hands the programme a gap it did not plan for.
If your sponsor has enthusiasm and no authority, you do not have a sponsor. You have an advocate, and you need both.
The Prototype Handover Pattern
For anything touching a widely used production application or sensitive data, this is the pattern that works, and it is the one we default to.
An internal team member builds the prototype. It is theirs: their process knowledge, their edge cases, their judgement about what actually matters. Then the prototype is signed off, and it stops being the build. It becomes the specification. An engineer, internal or a forward-deployed engineer from Fifty One Degrees, does the production build on the road and under the agreed rules.
Treating the prototype as input rather than as a nearly-finished product is the discipline that makes this work. It removes the argument about whether business-built code is good enough, because that question never arises. The prototype's job is to prove the shape of the solution and eliminate requirements risk, which is where most software actually fails. The engineer's job is everything that makes it dependable.
We call the crossing point the Promotion Gate, and it needs four answers on one page: a named business owner, a stated data classification, a documented failure mode, and a decision about what happens when the application stops working. If the builder cannot answer those four, the application is not ready to be depended on, however well it demos. It is also the cleanest answer to both of the questions above, because it is where "will it hold up" and "what am I not seeing" get asked out loud by someone other than the author.
Pick Five Builders, Not Fifty
Enthusiasm is not the constraint. Judgement is.
Find the people who already automate their own work in spreadsheets and workflow tools. Give them protected time rather than evenings and weekends. Train them in person, on their real work, in role-specific sessions. Fifty One Degrees measures this through The 85% Rule: giving staff AI tools with no training achieves roughly 20% daily usage, adding online training lifts it to about 50%, and combining online resources with practical role-specific in-person workshops reaches around 85%. The same gradient applies to building, and it applies harder, because building requires judgement about when to stop.
Everybody else gets to be a user of what those five people build. That is where the productivity actually lands, and it is a far better return than fifty half-finished tools.
Where This Sits in a Wider Transformation
None of this is really about applications. It is about what your business reaches for when it hits a gap.
Fifty One Degrees calls that The Build Reflex: in most mid-market companies the instinct is to ask who sells this, and in a technology company the instinct is to ask what it would take to build it. Letting non-technical people build safely is the last of the four shifts that reflex is made of, the move from raising a ticket to having the agency to fix the thing yourself. Its test is a good one to hold your own organisation against: someone outside engineering ships something, and it passes review.
For us, this changes the job rather than shrinking it. We stop being the people who build every application and become the people who own the road, set the tiers, run the Promotion Gate and take the Tier 1 work. That follows the Decreasing Dependency Principle: our involvement should reduce over time, not increase. If your partner resists that, ask why. Their incentive may be to keep the build queue full.
Expect a graveyard, too. Six months in you will have forty half-built tools, several of them quietly load-bearing. Keep a register from day one and cull quarterly. Retiring things is part of the operating model, not an admission that it failed.
The Honest Version
Your teams are going to build regardless of what you decide. The only real choice is whether they build on infrastructure you control, under rules you published in advance. Tier by what it touches, pave one road, write the policy before you hand out the tools, make sure your sponsor can sign, and treat prototypes as specifications rather than products.
Do that and you have answered both questions your people are actually asking, which is what building with confidence means.
If you want a view on where your organisation currently sits, Fifty One Degrees runs this as an embedded engagement rather than an assessment. See how AI transformation works when the capability transfers.