Business analysts spend much of their working life describing applications that other people build. The requirements, the edge cases and the reasons behind each rule already sit with them, yet the finished system arrives weeks later, slightly wrong, via a hand-off. This article explains how business analysts can build applications themselves with a no-code platform, what is sensible to build, and which guardrails IT should keep.
The hand-off is where requirements go wrong
A typical internal project runs like this: the analyst interviews the operations team, writes a requirements document, walks a developer through it, answers questions, reviews a build, raises defects and signs it off. Each step is reasonable. Together they introduce a translation at every stage.
Things get lost in translation in predictable ways:
- Implicit rules ("we never approve a supplier without two quotes, unless it is a renewal") are written once and interpreted differently.
- Vocabulary differs: the business says "case", the database says "ticket", and reports stop matching.
- Priorities shift while the work waits in a queue, so the delivered version answers last quarter's question.
- Small changes after launch go back into the same queue, so they wait too.
When the analyst can build the application directly, most of that translation disappears. The person who understands the rule is the person who writes it down in the application.
What a business analyst actually needs from a tool
Not every no-code tool is suitable for business-critical work. An analyst building a system that others will rely on needs more than a form builder:
- A real data model: entities, fields, relationships and validation, not a grid of cells.
- Screens that fit the job: list views, detail pages and forms for different roles.
- Workflows: statuses, approvals, assignments and notifications expressed as rules.
- Permissions: who can see and change which records.
- History: a record of what changed, when and by whom, and a way to undo it.
Vibe generates the data model, screens and workflows from a description, a spreadsheet or an existing database, and then lets you change them by pointing and clicking or in plain language. AI helps while building by proposing the schema, screens and rules and explaining each change before you accept it; the AI while building FAQ covers this. You do not need to write code, as do I need technical skills? explains.
Good first applications for analysts
The best first projects are processes the analyst already understands in detail, that currently live in spreadsheets and email, and that cause visible friction. For example:
- A request intake and triage tracker for a shared services team.
- A supplier onboarding checklist with document collection and approval.
- A contract renewal register with reminders ahead of notice periods.
- An equipment or asset loan log with returns and overdue flags.
- A change request log with impact assessment and sign-off.
Say an operations team runs its purchase requests in a shared spreadsheet with a colour-coded status column. An analyst can import that spreadsheet, let Vibe propose entities for requests, suppliers and approvers, then add a rule that anything above a threshold needs a second approval. The team gets a working application with proper permissions, and the spreadsheet stops being the system of record. Our article on spreadsheet sprawl and shadow IT looks at why that matters.
Guardrails IT keeps
Letting analysts build is not the same as letting anything happen. The point of a governed platform is that IT decides the rules once, at platform level, instead of reviewing each application from scratch. The guardrails worth keeping are:
- Identity: sign-in goes through your identity provider using SSO over SAML or OIDC, so joiners and leavers are handled centrally.
- Access: role-based access on every entity and action, so a builder cannot accidentally expose salary data to the whole company.
- Audit: audit logging of data changes and administrative actions, which gives security teams something to read.
- Change control: every change is versioned and reversible, and deployments move through staged environments with one-step rollback.
- Data ownership: data and generated code remain exportable on any plan, so nothing is trapped in a builder's personal account.
With those controls inherited by every application, IT's role moves from gatekeeper for each build to owner of the platform policy. The FAQ on whether Vibe can pass a security review sets out what reviewers usually ask.
A working rhythm between analysts and IT
A simple arrangement that tends to work:
- Agree the boundary. IT defines which data classifications and integrations need their involvement. Everything inside the boundary, analysts can build.
- Build in a staged environment. The analyst builds and tests with a small group of real users.
- Review what matters. IT reviews roles, sensitive fields and any connections to other systems, not screen layouts.
- Publish and own it. The analyst's team owns day-to-day changes. Because changes are versioned, a mistake is a rollback, not an incident.
- Escalate when it outgrows no-code. If an application needs custom logic beyond the platform, hand it to developers or to a services team, with the working application as the specification.
That last step is worth dwelling on. Even when a project does end up with developers, an application an analyst has already built and used is a far better specification than any document.
What changes for the analyst role
Analysts who build do not stop analysing. They spend less time writing documents that describe software and more time watching how people use the software and adjusting it. Questions like "why do half the requests get sent back?" become answerable from the application's own data, and AI can help people ask questions of that data in plain language while using the application. The broader argument for this shift is in no-code SaaS vs building business apps in-house.
Start with one process you know well
Pick the process you know best and that frustrates people most, and build it. The product page shows what Vibe produces, and how do I start building? covers the first steps. If you would like help on a real workflow ahead of general availability, the design partner programme is open and free during the programme; get in touch.