Skip to content

A paved road for worker-built apps

A paved road (a golden path) is the supported, pre-approved way for citizen developers and other staff to build, host and run apps. It covers approved builder and AI tools, company sign-in, private-by-default hosting, a secrets manager, approved data connectors, separate test and production environments, logging and backups, templates, and a hook into the app registry. Start thin, even with one page that lists the approved services, and grow it from what builders actually use. It only works if it's faster than the alternatives, as of October 2026.

Who this is for

Platform, DevOps and IT infrastructure leads, and IT managers who have been asked to "set up a platform" for employee-built apps. You get a component list, a default path that needs no platform team or pipelines, and a way to make the road the one builders choose. Reading time: about 12 minutes.

What does a paved road contain?

The table shows each capability, why it's there, the least you can start with, and what it grows into. "Minimum" means something a typical IT function can set up with bought services and admin consoles.

Capability Why it's there Minimum version Grows into
Approved builder and AI tools Builders use what they're given; unapproved tools hold your data with no contract A one-page list of approved tools by data class (approve tools) A reviewed catalog with an exception path answered in days
Company sign-in Everything private by default; one place to remove access Single sign-on (SSO) and multi-factor sign-in on every approved tool Group-based access and automatic removal when someone leaves
Private-by-default hosting Public-by-default data is the most common documented exposure One approved hosting pattern that needs company sign-in More patterns, including a reviewed public-facing one
Secrets manager Keys in front-end code or prompts are the next most common A secrets manager you already own, or the builder platform's secret store kept server-side (secrets) Short-lived credentials and scheduled rotation
Approved data connectors Controls what an app can read and send A short allow-list of connectors, with new ones off by default Per-data-class policies
Separate environments Test changes without touching live data Team: try changes away from live data. Important and above: separate test and production Automated promotion from test to production
Logging and backups You can't support or recover what you can't see The platform's own audit log and scheduled backups, with a restore you've tested Central logs and alerting
Templates The fast path: start from something already safe One starter template per builder tool, with sign-in and data rules set A small library, owned and versioned
Registry hook Ownership, tier and retirement depend on it A spreadsheet registry the intake form writes to Automatic discovery from platform inventories

Fast-moving

As of October 2026. Builder platforms change their sharing defaults and licence tiers often, so recheck what each one can enforce at the licence you buy. Check the review date.

The paved road with no platform team

This is the default path, for any business that has an IT function but no platform engineers and no build pipelines. Every part is bought, configured once and checked on a schedule.

  1. A business-tier builder. Pick one low-code tenant, or one AI app builder on a business plan that offers SSO and admin controls. Examples of the two kinds: a low-code tenant from a large business-software vendor or a workflow-automation platform; a hosted AI app builder with team workspaces. Check whether SSO needs a premium licence tier before you commit, because on many tools it does.
  2. A managed backend with row-level security. Use the builder's managed database, or a managed database from your cloud provider, with data rules that deny access unless a rule allows it. Stop vibe-coded apps exposing data explains the rules and the negative test.
  3. A secrets manager you already own, such as your cloud provider's secrets service, or the builder platform's secret store where values stay server-side. Builders get keys from it; they never paste keys into prompts or code.
  4. A spreadsheet registry. One shared sheet with an owner, tier and retire-by date for every app. It's enough until discovery is automatic. See the app registry.
  5. A scheduled exposure scan. IT (or the technical reviewer it delegates to) runs an external exposure scan, monthly by default, against the URL and data endpoints of every app at Important and above, and records the date and result in the registry. Including Team apps is good practice where IT can: it's the only check that catches a Team app's Floor 2 breach after launch. A passive crawl of the pages isn't enough: the scan must search the shipped front-end code for keys and query each data endpoint signed out, with only the public key, and as a second test account. What the exposure scan must check lists the checks and the kinds of tool that run them. It backs up the negative access test; it doesn't replace it.
  6. An exceptions path. One mailbox or form, answered within days, because a slow exception path sends builders to unmanaged tools.

What this setup enforces without pipelines is on guardrails.

Depends on your circumstances (C5)

If nobody owns identity or access today, fix that first: a managed identity provider with SSO and multi-factor sign-in is the base for every other part of the road. Without it, "private by default" has nothing to check against.

How do you start a paved road thin?

The thinnest viable platform can be as small as a wiki page that lists the approved services and how to use them, grown only as demand appears.2 A large platform built before there are users is a common way to stall: the CNCF maturity model treats a platform pushed on users as an early, fragile stage.1 Research on developer-portal adoption, from the vendor that created one portal product, found that clear ownership was the outcome people wanted most, and that culture was a harder barrier than technology.3

Don't: build a big platform before there are users

A large build with no demand produces a platform nobody pulls on.12 Start with the list, one template and the registry sheet. Then add only what builders ask for, or what the exposure scan shows is missing.

If nobody owns this work yet, the single starter sequence is what to do if nobody owns this today. It isn't copied here.

Pave the desire paths

A desire path is the route people wear across the grass when the planned path doesn't take them where they need to go. Campus planners have long read these paths as evidence of demand: many of Michigan State University's north-campus sidewalks follow dirt paths students wore before there was money to pave,7 and UW–Madison's planners still pave heavily used ones.8 Unsanctioned AI tools and untracked worker-built apps are the same signal. They show a job the official route doesn't serve.

Your discovery work already maps these paths. Find the AI-built apps you already have turns up the apps, their owners and the data they touch, from expense data, sign-in logs, OAuth grants and platform inventories. The shadow AI policy's detection rules add which unapproved tools people reach and how often. Read each finding as three facts: the job, the tool, and the data class.

Prioritize the road from those findings:

  1. Group findings by job, not by tool. Ten people using four different AI app builders to make intake forms is one path.
  2. Rank by use and by risk together. Pave first the paths that many people walk and that carry Confidential or Restricted data or reach the internet.
  3. For each, either pave it (approve the tool, or add a template for that job) or offer a better route that is faster than what people use now.
  4. Re-run discovery and check whether people moved to the paved route (A-002).

Planners don't pave every path, and neither should you: paving everything people do moves the support load onto the platform.10 Some paths need a better route instead. But a path with no alternative stays a path. Signs and barriers against everyday desire paths have mixed results,9 and bans on AI tools hide use rather than stop it (A-004). This is the thin platform grown by pull: the road grows where people already walk.

Don't: fence off a desire path without a better route

Blocking a tool people rely on, with nothing as fast to replace it, moves the path out of sight: to personal accounts, where discovery can't see it. Offer the route first, then close the old one. See why enable first instead of banning.

Day-one controls

Put these in place before the first app goes on the road. They're defined once, so follow the links:

See guardrails for AI app deployment for the enforcement matrix: which layer enforces each control. What each risk tier needs at deploy is in the deploy gates of the gate matrix. The road should make those gates the easy route, not a form to fill in.

How do you make it the fast path?

Adoption works by pull. The CNCF application-delivery group's maturity model treats mandated platforms as an early, fragile stage, and platforms that users choose "because of the clear value they provide" as the goal.1 The road has to beat the unmanaged alternative on time, not only on safety.

  • Time to first running app: a builder should reach a private, signed-in starter app in one working session.
  • Time to an answer: intake and exceptions get an answer within days (the target is on intake).
  • Safe defaults that need no decision: the starter template already has sign-in, private sharing and data rules set. Microsoft's guidance for its low-code default environment has the same shape: sharing limits (which need its premium managed-environment tier) and connector blocking on by default, plus a request path for more.4
  • Reuse: show builders what already exists before they build a duplicate.
  • A clear next step: when an app is ready for other people, the builder's next stop is to make an app production ready.

Don't: make the safe path slower than unmanaged tools

If the road takes weeks, builders go to personal accounts and free tiers and you lose sight of their apps. See find the AI-built apps you already have for how that looks in practice.

Don't: mandate a platform nobody wants

A mandate without value pushes use underground.1 Offer the road, measure how often builders choose it, and fix what drives them away.

Hypothesis to test

We expect builders to use a low-power default path if exceptions are answered within days and the path is faster than unmanaged tools (A-002). Test it in your pilot: compare registered apps with apps found by discovery, and track the median days from request to answer. Track IT's own effort too: record how long the monthly exposure scan takes across all registered apps, because that cost grows with every app.

How do you run a paved road as a product?

Name an owner (a role, with a backup). Keep a short list of what builders asked for and what you decided. Publish a small roadmap, review it quarterly, and retire services nobody uses. DORA's 2025 research, as reported by InfoQ, treats internal platform quality as one of the capabilities that decides whether AI-assisted building speeds delivery or amplifies instability.5 CISA's secure-by-design guidance asks a supplier to own the security outcome for its customers; read for an internal road, your defaults, not each builder's choices, carry the security.6

When your circumstances differ

Depends on your circumstances (C6)

If you already run a platform team or build pipelines, this is where pipelines, a dependency proxy, supply-chain provenance levels (SLSA) and an AI model gateway belong. They're covered on guardrails and hosting. They aren't the default, because most readers can't maintain them.

Depends on your circumstances (C9)

If several AI tools are already in use, start from the approved tools list and the low-code vs. AI app builders comparison. Pick the fewest tools that cover your data classes, and move builders to them with the fast path rather than a ban.

Record the decision

Record the scope of version 1 of your road once, as a program-level decision, using the decision record template.

Illustrative composite

Title: Adopt paved road version 1 · Status: accepted · Date: YYYY-MM-DD · Owner: platform or IT infrastructure lead (a role) · Sponsor: the executive sponsor named in the leadership charter

Context. Staff build apps with AI tools. We have no shared approved route and no platform engineers.

Decision. Version 1 is the approved tools list, SSO on the approved builder, one private hosting pattern, the cloud secrets manager, a spreadsheet registry, one starter template and a monthly exposure scan run by IT for Important and Critical apps (Team apps too, while the volume allows).

Alternatives considered. Build a self-service portal (rejected: no users yet, nobody to run it). Ban AI app builders (rejected: bans push use underground). Do nothing (rejected: apps already exist with no owner).

Consequences. IT owns the road and its roadmap. Builders get a starter template and an answer within days. We review scope at six months.

Review by: six months from the date above, or sooner if the share of unregistered apps found by discovery isn't falling.

Assumptions and evidence

  • A-002 (Low): we expect builders to use a low-power default path if exceptions take days and the path is faster than unmanaged tools; test this by comparing registered apps with those found by discovery.
  • A-013 (Medium): we expect the benefits of AI-assisted building to depend on foundations such as testing, review and platform quality; test this by tracking failed changes alongside speed.
  • A-038 (Low): we expect the builder platform to enforce SSO, private-by-default sharing and deny-by-default data rules at the licence you buy, or compensating controls to suffice; test this by checking each approved tool's admin console before approving it.

Evidence: mostly vendor guidance, a standards-body whitepaper and survey reporting. There's no independent measurement of paved roads for non-developer builders. Facts on this page are as of October 2026.

  1. CNCF TAG App Delivery, "Platform Engineering Maturity Model", v1, Oct 2023. https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ [primary], accessed 2026-10-21. ↩↩↩↩

  2. Team Topologies, "What is a Thinnest Viable Platform (TVP)?". https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp [primary], accessed 2026-10-21. ↩↩

  3. CNCF, "Backstage Insights Summary" (2022 research on developer-portal adoption, measuring desired outcomes and barriers, not failure rates; the research originates with the vendor that created the product). https://contribute.cncf.io/techdocs/analyses/2023/backstage/insights-summary [vendor], accessed 2026-10-21. ↩

  4. Microsoft Learn, "Secure the default environment" (Power Platform adoption guidance, updated 26 Aug 2026). https://learn.microsoft.com/en-us/power-platform/guidance/adoption/secure-default-environment [vendor], accessed 2026-10-21. ↩

  5. InfoQ, coverage of the DORA "State of AI-assisted Software Development" report, Sep 2025. https://www.infoq.com/news/2025/09/dora-state-of-ai-in-dev-2025 [survey; secondary coverage of the report], accessed 2026-10-21. ↩

  6. CISA, "Secure by Design". https://www.cisa.gov/securebydesign [regulator], accessed 2026-10-21. ↩

  7. Michigan State University, Spartan Magazine, "The ABCs of MSU", Fall 2024 (section D, desire paths). https://spartan.msu.edu/spartan-story-hub/magazines/fall-2024/the-abcs-of-msu-8705 [primary], accessed 2026-10-22. ↩

  8. University of Wisconsin–Madison News, "Desire paths: the unofficial footpaths that frustrate, captivate campus planners", 24 Apr 2019. https://news.wisc.edu/desire-paths-the-unofficial-footpaths-that-frustrate-captivate-campus-planners/ [primary], accessed 2026-10-22. Older than 18 months; cited for a durable planning practice. ↩

  9. 99% Invisible, "Least Resistance: How Desire Paths Can Lead to Better Design", 25 Jan 2016. https://99percentinvisible.org/article/least-resistance-desire-paths-can-lead-better-design/ [secondary: design journalism], accessed 2026-10-22. Older than 18 months; cited for a durable principle. ↩

  10. Octopus Deploy, "Paved versus golden paths in platform engineering" (undated). https://octopus.com/blog/paved-versus-golden-paths-platform-engineering [vendor], accessed 2026-10-22. ↩