From prototype to governed corporate asset
The strongest candidates for enterprise vibe coding are the small internal tools that teams already understand but still run through spreadsheets, inboxes and shared documents. Sasha Apps, now available in beta, gives those teams a managed place to create, host and improve their own applications while identity, permissions, data boundaries, audit history, testing and publication remain under enterprise control.
The people closest to the work already know what to build
An operations manager may have spent years running the same weekly process. They know which fields matter, who can approve an exception and what must happen before a record is complete. They lack a safe route from that knowledge to working software.
Traditional development turns a modest internal need into a queue: write a brief, translate it into technical requirements, secure engineering time, review the first version and repeat. Generic AI app builders shorten the build step, but they can create a second problem if the result sits outside corporate identity, data and deployment controls.
That governance gap is now the central enterprise question. Northflank argues that the largest production risks gather at the deployment layer: credentials, broad database access, weak isolation, public URLs and missing audit trails. Vybe makes a related distinction: business teams can describe the tools they need, but governance must sit above generation through access control, audit records and enforced data boundaries.
Sasha takes that separation seriously. The employee describes the application and remains the authority on how the process should work. Sasha creates and maintains the application inside a managed, hosted environment. The platform owns the controls that should not depend on an individual prompt.
The standard for a governed app
1. The requirement starts in business language. A user should be able to say, “We need to record time by project and submit it weekly.” They should not need to design a database, choose a framework or specify an authentication library.
2. Routine behaviour is deterministic. Saving a timesheet, calculating a total, changing a status or recording an approval should behave like ordinary software. AI helps create and change the application. Ordinary transactions do not need AI to improvise them.
3. Governance is part of the platform. Authentication, app-level access, record permissions, data isolation, validated operations, audit history and safe error handling should remain enforced when the application changes. Security-critical controls do not become editable suggestions inside generated code.
4. Changes follow the same controlled path as creation. A request such as “make project code mandatory” produces a draft. The owner sees what changed, tests a preview and decides whether to publish it. The live application is not edited in place.
5. The application remains a corporate asset. It has an owner, a known audience, managed hosting, a controlled data store, revision history and a recovery route. It does not disappear when the person who assembled the first spreadsheet changes role.
This is the difference between an informal prototype and operational software. The interface may still be created quickly, but production authority stays with the organisation.
The prompt
We wrote these five prompts as requests from people who understand the work. Sasha handles the application structure and returns a governed draft for review.
1. Time tracking and project allocation
Build a time-tracking app for our team.
People need to enter hours against a project for each working day, review a
weekly total and submit the completed week. A submitted week must not change
silently. Managers need a view of submission status and totals by project, but
each person should only edit their own draft entries.
Keep an audit history of submissions and corrections. This is for project
reporting, not payroll. Start with a draft, show me the data fields and access
rules in plain English, and let me test the preview before anything goes live.
A later change can be as direct: “Add a required project code and highlight weeks that are still unsubmitted on Monday morning.”
2. Internal requests and triage
Build an internal request app for our operations team.
Staff should submit a request with a category, description, urgency and optional
attachment. The operations team should assign an owner, add internal notes and
move the request through New, In review, In progress and Complete. Requesters
can see their own requests; the operations team can see the shared queue.
Record who changed the owner or status and when. Prevent invalid status changes
and duplicate submissions. Prepare a private draft and explain the permissions
and workflow before I approve publication.
A useful follow-up might be: “Add Facilities as a category and show average completion time by category.”
3. Equipment and asset register
Build an equipment register for laptops, monitors and loan devices.
For each asset, record its asset number, type, serial number, condition,
location and current holder. Staff can view available equipment. The workplace
team can add assets, check them out, record returns and correct details. Keep a
history so we can see who held an item and when.
Serial numbers must be unique. A checked-out item cannot be issued again until
it is returned. Show me a draft with the access rules, validation and recovery
options before the app is made available to the team.
The workplace lead can later ask: “Add an inspection-due date and a view of equipment due for inspection in the next 30 days.”
4. Customer or supplier onboarding tracker
Build an onboarding tracker for new suppliers.
Each supplier needs an owner, target start date and a checklist covering the
documents, security review, commercial approval and system setup that apply to
them. Show what is complete, what is blocked, who owns the next action and which
items are overdue.
Only authorised procurement staff should create or edit supplier records.
Other invited colleagues may update tasks assigned to them. Keep changes
auditable and do not expose one supplier's records outside the authorised team.
Create a draft first and let us test the workflow without changing live data.
When the process changes, the owner can say: “Add a data-processing check for suppliers that handle personal information, but only when it applies.”
5. Lightweight approvals
Build a lightweight approval app for small purchasing requests.
A requester enters the purpose, supplier and estimated cost. Requests move
from Draft to Submitted, Approved or Rejected. The requester cannot approve
their own request. Approvers need a queue, a decision note and a clear record of
who decided and when. Rejected requests may be revised and resubmitted without
losing their history.
This is an internal workflow, not a payment or accounting system. Keep the
approval rules outside the editable page interface, prevent duplicate actions
if someone retries, and show the complete draft and permissions before I decide
whether to publish it.
A policy update becomes a change request: “Require a second approval above our agreed threshold and show both decisions in the history.”
The work these prompts do
- It keeps expertise with the business user. The prompts state outcomes, exceptions and responsibilities without asking the user to impersonate a software architect.
- It gives Sasha the boundaries as well as the happy path. “Not payroll,” “not a payment system” and “only authorised procurement staff” prevent a small app from expanding, unnoticed, into a higher-risk system.
- It makes permissions part of the requirement. Who may view, edit, submit or approve is defined before the interface is published.
- It separates application change from operational action. Sasha can propose a new field or workflow as a draft, while ordinary users continue to create and update records through predictable application rules.
- It preserves the approval point. Creation speed does not grant production authority. The person responsible for the process still reviews and publishes each revision.
Failure patterns
The prototype receives production data before it receives production controls. A useful demo is connected to a shared administrator account because that is the quickest way to make it work. The app now has more access than its users. Lesson: data access must be scoped and enforced by the platform before real records arrive.
Permissions live in the page. A hidden Approve button does not stop a determined user or a broken client from calling the underlying operation. Lesson: identity and record policy belong on the server, outside AI-maintained interface code.
The first version becomes permanent by accident. A prototype earns users, then every change is made directly against the live copy because no draft or preview process exists. Eventually nobody knows which behaviour was intentional. Lesson: every change needs a reviewable revision and an explicit publication event.
A simple workflow grows into a miniature enterprise platform. Time tracking drifts into payroll. A supplier checklist drifts into a procurement system. Complexity and assurance requirements rise without a conscious decision. Lesson: state the non-goals in the initial prompt and keep the app bounded to the process its users understand.
The cost
The human effort moves away from framework selection, database plumbing and deployment work. It goes into describing the process, checking the data and access rules, testing the preview and deciding when the revision is ready. That is work the process owner is well placed to do. The organisation supplies the managed Sasha environment once, rather than asking every department to assemble its own hosting and security stack.
The case for Sasha Apps
Enterprise software demand contains a long tail of small, specific applications. They are too local to win a place on the central roadmap but important enough to consume hours every week. The people doing that work already know the edge cases because they live with them.
Sasha Apps gives those people a shorter route from knowledge to software without creating a shadow deployment estate. Managed hosting, controlled data access, deterministic operations, auditable changes and approval before publication turn a useful conversation into an asset the organisation can own. The next improvement can begin with one sentence rather than another development project.
Sasha Apps is available in beta. This article draws on public analysis from Northflank and Vybe, alongside the operating controls being tested in Sasha.