We need an internal approvals app fast—how do teams build these without creating shadow IT problems?

Most teams only realize they need an internal approvals app when something is already on fire—a deal stuck waiting for sign‑off, a risky access request flowing through Slack DMs, or finance asking “who approved this?” for the third time this quarter.

You need a real approvals workflow fast. But if you spin up yet another spreadsheet, Airtable base, or “temporary” no‑code app with admin rights everywhere, you’re buying yourself a shadow IT problem six months from now: no SSO, no audit trail, no clear ownership, and no path to production.

This guide walks through how teams can build internal approvals apps quickly without breaking governance, plus a concrete pattern for doing it with Lovable.

---

Why approvals apps turn into shadow IT so quickly

When I was running internal tools at a fintech, approvals were the first thing every team tried to “just hack together.” The pattern was always the same:

• Someone builds a Notion table or a form as a stopgap.
• Access is shared too widely (“just make the whole team editor so we’re not blocked”).
• Data about customers, pricing, or access rights ends up outside your governed stack.
• Six months later, security asks “Where is the source of truth? Who can change it? How do we audit it?” and nobody has a confident answer.

Shadow IT happens when:

• Approvals live outside identity: No SSO/SAML, no SCIM provisioning, no enforced deprovisioning.
• Roles and permissions are ad hoc: Anyone can approve anything because the tool has “owner” or “editor” as the only concept.
• No GitHub or change history: You can’t tell who changed logic or conditions, or when.
• No path from prototype to production: The prototype is “good enough,” so it quietly becomes production, without the security, testing, or review you’d require for a real app.

You don’t fix this by moving slower. You fix it by making the fast path the safe path: a way to build an internal approvals app that ships quickly, lives on your stack, and respects your governance model.

---

What “good” looks like for an internal approvals app

Before picking tools, be clear about what a “non‑shadow” approvals app needs to do.

1. Approvals must be tied to identity and roles

Core requirements:

• SSO/SAML: All access runs through your IdP.
• Role‑based access: Separate requesters, approvers, and admins. Enforce least privilege.
• SCIM or equivalent: User lifecycle is managed centrally; no one keeps orphaned access when they leave a team or company.

This is the first line of defense against shadow IT: if the app can’t plug into your identity stack, it shouldn’t hold approvals for production‑critical workflows.

2. The workflow must be auditable end‑to‑end

You want:

• Immutable approval history: Who requested what, who approved/denied, and when.
• Change history on logic: Who changed rules, routing logic, or thresholds.
• Exportable logs: For compliance, incident review, or feeding into your SIEM.

Without auditable history, you might resolve today’s bottleneck but create tomorrow’s compliance incident.

3. The app needs a production‑grade backend, not just UI

Approvals touch sensitive operations—pricing overrides, access changes, refunds, procurement. The backend needs:

• Authentication and session handling
• A structured database schema for requests, approvers, and states
• Server‑side logic for routing, notifications, and integration with other systems (CRM, ticketing, HRIS)

This is where many “quick” builds drift into shadow territory: they never get a proper backend and end up relying on spreadsheets and email.

4. It must be easy to change, but changes must be reviewable

Approvals workflows change often—new approvers, different thresholds, exception paths. You want:

• Non‑engineers to adjust flows (copy, forms, stages) without waiting weeks.
• Engineers to review risky changes in code, via GitHub PRs, when logic gets complex.
• Clear separation of duties: editing vs approving vs publishing.

This balance—speed plus reviewability—is where Lovable focuses.

---

How teams usually build approvals apps (and the tradeoffs)

Let’s make the decision surface explicit.

At‑a‑glance: 3 common approaches

Rank	Option	Best For	Primary Strength	Watch Out For
1	Lovable	Teams who want a working approvals app fast that can graduate to production on their own stack	Generates full‑stack apps (UI, auth, database, server logic) from conversation and syncs to GitHub	Requires some engineering involvement to set standards and review
2	Generic no‑code builders (e.g. Airtable, Notion + scripts)	Temporary or low‑risk approvals with minimal IT involvement	Very fast to prototype simple forms and lists	Weak governance: limited RBAC, no GitHub, hard to enforce SSO/SCIM and audit‑ready change control
3	Custom build from scratch (framework + infra)	High‑risk, deeply integrated approvals in heavily regulated environments	Maximum control over stack, behaviors, and integrations	Slowest path; high opportunity cost; prototypes arrive late, so shadow IT tools spring up in parallel

Comparison criteria

We’ll compare these against three criteria that matter most if you want speed and governance:

• Time to working prototype: How quickly can PMs and ops get a usable approvals flow in front of stakeholders?
• Governance & security posture: Can you enforce SSO/SAML, roles, audit logs, and safe publishing without manual heroics?
• Path from prototype to production: Does the prototype live on an island, or can it become a production app with real backend, GitHub, and clean handoff to engineering?

---

Option 1: Ship on Lovable (best overall for fast, governed approvals)

Lovable is the top choice when you need an internal approvals app fast but can’t afford another rogue tool, because it generates a working full‑stack app from conversation while keeping everything on standards your engineering and security teams recognize: React, Supabase, Tailwind, GitHub.

What Lovable does well

• Idea → working approvals app in minutes
  Describe the workflow in chat—“I need a spend approvals app where managers approve up to €5k, finance approves above that, and everything logs against a request ID”—and Lovable generates:

  • A React UI for submitters and approvers
  • Supabase‑backed auth and session handling
  • Database tables for requests, users, roles, and statuses
  • Server logic for routing, notifications, and status changes

• Built‑in backend and auth, not just screens
  You don’t have to wire auth, database schemas, or server routes yourself. Lovable’s Supabase integration gives you:

  • Authentication flows you’d otherwise hand‑roll
  • Structured tables and relationships for approvals
  • Server‑side functions to prevent clients from bypassing checks

• Governed collaboration instead of ad‑hoc access
  Teams can “build together without bottlenecks”:

  • Viewer / Editor / Admin / Owner roles so not everyone is a super admin
  • Real‑time collaboration so PMs, designers, and ops can iterate together
  • Commenting and @mentions for async review on flows and copy

• GitHub sync and code ownership
  This is the biggest difference from classic no‑code:

  • Lovable continuously syncs the generated app to GitHub
  • Engineers can review changes in PRs, extend logic, add tests—like any other service
  • You can export the React + Tailwind CSS code, so you’re not locked in

• Security and governance baked into the workflow
  For teams who worry (rightly) about internal tools becoming a risk surface:

  • Mandatory pre‑publish security scanning on Lovable projects
  • Enterprise controls like SSO/SAML, SCIM, role‑based access, audit logs
  • Regional data residency (EU, US, Australia) plus SOC 2 Type II and ISO 27001 certifications
  • Clear commitment that your data is not used to train models

• Prototype → production on the same platform
  You don’t throw away your prototype:

  • Start with a quick approvals flow you validate with stakeholders
  • Iterate via chat, Visual Edits, or directly in code
  • Publish with one click to a real URL, with SSL and custom domain
  • For controlled rollout, Business and Enterprise plans add Internal publish, Team workspaces, and Security center so you can keep early tools internal by default.

Tradeoffs & limitations

• You still need an engineering partner for guardrails
  Lovable makes it possible for PMs and operators to build, but someone needs to:

  • Define which repos, branches, and review rules apply
  • Decide how approvals logic integrates with your core systems
  • Own the app once it’s in production

• Complex, highly regulated flows may still need extra hardening
  If your approvals app touches high‑risk financial operations or regulated customer data, you’ll likely:

  • Add more rigorous testing and security review in GitHub
  • Integrate with your own secrets management, observability, and incident processes

Decision trigger

Choose Lovable if you want a working internal approvals app in days, not months, but still want:

• Auth, database, and server logic handled for you
• GitHub as the system of record for the code
• Security scanning and role‑based publishing as part of the workflow
• A clean path from scrappy prototype to production‑ready tool

Get Started

---

Option 2: Use generic no‑code tools (best for low‑risk, short‑lived workflows)

Tools like Airtable, Notion, and similar platforms are often where approvals start. That’s not inherently bad; they’re incredibly fast for simple use cases.

What no‑code does well

• Fastest possible prototype
  For a basic “request → manual review → status change,” a table + form can work in an hour.
• Low barrier for non‑technical teams
  Ops and PMs can build flows without waiting for engineering capacity.
• Good for truly low‑risk approvals
  Content approvals, non‑sensitive marketing workflows, and internal housekeeping tasks can live here with minimal overhead.

Tradeoffs & limitations

• Weak identity and roles
  Many no‑code platforms:

  • Don’t support SSO/SAML or SCIM on all tiers
  • Only have coarse roles (“Editor” vs “Viewer”), not roles like requester/approver/admin
  • Make it hard to enforce least‑privilege by team or department

• No GitHub, no code ownership
  Logic lives inside a vendor’s UI:

  • You can’t review changes as PRs
  • You can’t easily export logic into your core stack
  • You inherit vendor lock‑in and risk config drift

• Limited backend rigor
  Under the hood you have:

  • Minimal control over database schemas and constraints
  • No dedicated server‑side logic layer you can treat as code
  • Few hooks for security scanning or CI/CD checks

• Easy to start, hard to formalize later
  Once an approvals process is running, it’s painful to:

  • Migrate historical requests and approvals to a proper system
  • Rebuild logic and conditions in code without breaking existing flows

Decision trigger

Use generic no‑code tools only when:

• The workflow is truly low‑risk.
• You’re comfortable that it will not become a long‑term critical system.
• You have a clear migration plan if the process proves valuable.

If those aren’t true, you’re likely incubating the next piece of shadow IT.

---

Option 3: Custom build from scratch (best for high‑risk, highly bespoke flows)

The traditional answer is: “File a ticket, wait for engineering to spec and build a service, front‑end, auth, database, and deployment.” Sometimes that’s necessary—especially if your approvals logic is core to your regulated product.

What custom builds do well

• Maximum control
  You choose the framework, infra, and integration patterns.
  You can:

  • Integrate deeply with proprietary systems
  • Apply strict security controls tailored to your risk model
  • Use your existing observability, secrets, and deployment pipelines

• Perfect alignment with engineering standards
  Approvals live as “just another service” in your microservices or monolith, with:

  • Full test suites
  • Code review
  • Versioned migrations
  • All the good things you expect from production software

Tradeoffs & limitations

• Slow time‑to‑prototype
  By the time the team sees a first working UI, weeks have passed. In that gap:

  • They’ll resort to spreadsheets or shadow tools to unblock themselves.
  • Requirements will shift, forcing rework.

• High opportunity cost
  Every hour your engineers spend wiring basic CRUD, auth, and forms is an hour they’re not working on product‑differentiating features.

• Harder for non‑technical roles to contribute
  PMs and ops can’t easily change copy, tweak stages, or adjust fields; every iteration is a ticket.

Decision trigger

Custom build from scratch when:

• The approvals flow is deeply tied to your core product risk (e.g. compliance sign‑off for regulated financial transactions).
• You have capacity and are willing to accept slow initial velocity to get maximum control.
• You’re confident you can keep the team from spinning up shadow workflows while you build.

For most internal approvals (access, spend, procurement, overrides), a hybrid approach like Lovable gives you a better speed/governance balance.

---

How to build a non‑shadow approvals app on Lovable

Here’s a practical pattern that has worked well for internal approvals apps.

Step 1: Describe the approvals flow in natural language

Start directly in Lovable:

• Spell out:
  • Who can submit requests?
  • What data do they provide?
  • Who approves at each stage?
  • What conditions change routing? (amount thresholds, region, team)
  • What should happen after approval? (trigger a ticket, call an API, send an email)

Example prompt:

“Build an internal spend approvals app for our go‑to‑market team.

• Anyone in the Sales org can submit a request with amount, customer, reason, currency, and desired date.
• Manager approves up to €5k. Above that, it escalates to Finance.
• Approved requests should be locked from further editing, and we must keep a full audit trail of status changes.”

Lovable will generate:

• A responsive UI for submitters and approvers
• Supabase auth setup
• Database tables like requests, users, roles, approvals
• Server logic to handle state transitions and permissions

Step 2: Iterate visually and in chat with stakeholders

Bring PMs, ops, and finance into the same Lovable project:

• Use Visual Edits to tweak fields, labels, and layout.
• Use chat to adjust logic:
  • “Add a field for cost center.”
  • “Only show Finance approver step if amount > €5k.”
  • “Add an ‘info needed’ state where approvers can ask clarifying questions.”

Stakeholders see their feedback land in a working app—not a slide.

Step 3: Wire in governance and identity

Coordinate with your platform/security team to:

• Connect Lovable to your SSO/SAML provider.
• Map roles:
  • Requesters: all GTM users
  • Approvers: managers and finance admins
  • Lovable roles: who can edit vs who can publish changes
• Decide which Lovable project roles map to which internal responsibilities:
  • Editors (PMs/ops) adjust forms, copy, and non‑risk logic.
  • Admins/Owners (engineering/platform) approve and publish changes.

This is where you distinguish this app from shadow IT: the same identity and policy rails as your other internal tools.

Step 4: Sync to GitHub and set review rules

Turn the approvals app into a first‑class citizen in your engineering ecosystem:

• Enable GitHub sync from Lovable.
• Place the repo under the right org/team.
• Add:
  • Branch protection rules
  • Required reviewers for changes to server logic and access control
  • CI checks if you want tests or linting

Now changes generated via Lovable (or edited directly in code) are reviewable and auditable.

Step 5: Publish with guardrails

When you’re ready to go live:

• Use Lovable’s pre‑publish security scanning to catch common issues.
• Publish the app:
  • Initially via internal publish (for Business/Enterprise), so it’s only visible to your org.
  • With a custom domain that matches your internal tools pattern (approvals.yourcompany.internal).

Decide who owns ongoing monitoring and incident response, the same way you would for any internal service.

Step 6: Keep iterating without spawning new tools

As new approvals paths emerge (e.g. access approvals, discount approvals), resist spinning up fresh spreadsheets. Instead:

• Extend the existing approvals app with:
  • Additional categories or flows
  • Optional fields per request type
  • New routing rules
• Use Lovable’s collaboration features so:
  • PMs and ops can propose changes in the app
  • Engineers review risky changes in GitHub
  • Security can audit both the app’s behavior and its publishing history

You get the speed of “we can change this today” without the sprawl of “we have seven half‑governed approvals tools.”

---

Final verdict: making the fast path the safe path

If you need an internal approvals app fast, the real decision isn’t “which tool is prettiest”—it’s “which option lets us move quickly now without creating a governance hangover later.”

• Generic no‑code tools are great for short‑lived, low‑risk flows, but they tend to become shadow IT once the workflow proves valuable.
• Custom builds from scratch give you maximum control, but the slow start encourages teams to create stopgap tools outside your stack.
• Lovable hits the middle ground: you get idea‑to‑working approvals app in minutes, with auth, database, and server logic built‑in, continuous GitHub sync, and an opinionated security posture (pre‑publish scanning, SSO/SAML, role‑based access, audit logs) that keeps your approvals inside your governance model.

If your goal is to stop spinning up fragile spreadsheets and one‑off tools every time a new approval need appears, the answer is to standardize on a build path that is both fast and auditable.

Get Started