The idea
A small web app for teams that have outgrown "just ask in Slack" but are too small for real procurement software. Anyone submits a purchase request with an amount, category, and reason; it posts to the approver's Slack as an interactive message with Approve/Deny buttons. Approved requests land in a running ledger, broken out by category and month, so a manager can see spend against budget without opening a spreadsheet.
Why build this
Teams of 5-30 people hit an awkward gap: too big for informal "hey can I buy this" DMs, too small to justify Ramp, Brex, or a corporate procurement suite with multi-week onboarding. Finance ends up reconstructing spend from Slack threads and card statements after the fact. Slack's Block Kit makes it cheap to build approval flows that live where people already work, and most of these teams already have a Slack workspace and a Postgres instance lying around. The gap isn't tooling capability, it's that existing tools are built for companies ten times the size.
Stack sketch
- Next.js (App Router) for the request form, ledger dashboard, and admin settings
- Postgres for requests, approvals, and category budgets (Supabase works fine, or plain Docker Postgres)
- Slack Bolt SDK for posting interactive approval messages and handling button-click webhooks
- Auth.js with Slack OAuth so login doubles as workspace identity, no separate user database to seed
- Resend for email fallback when a request sits unapproved for 24 hours
- Deployed as a single container behind whatever reverse proxy the team already runs
Scope for v1
- One Slack workspace, one default approver per category (no approval chains)
- Request form: amount, category, vendor, one-line reason, optional link/attachment URL
- Slack message with Approve/Deny buttons, writes back to Postgres via signed webhook
- Ledger view: running total per category per month, filterable by requester
- CSV export of the ledger for finance to reconcile against the actual card statement
- Out of scope for v1: multi-level approvals, budget threshold auto-routing, direct card issuing, accounting system sync, receipt OCR
Where it could go
The natural next step is budget-aware routing: requests under a category's remaining monthly budget auto-approve, requests over it escalate to a second approver, which starts to look like real procurement policy without the enterprise weight. After that, a QuickBooks or Xero sync would close the loop so finance never re-keys anything, and turns the ledger from "a list of what was approved" into the source of truth for the books.
A second direction is card issuing: partnering with Stripe Issuing to generate a virtual card the moment a request is approved, capped at the requested amount, removes the step where someone still has to expense a personal card purchase. That's a bigger lift (compliance, KYC) but it's the feature that would make a team actually switch off spreadsheets for good.
Watch out for
Slack's interactive message payloads must be verified against the signing secret on every webhook call, and button clicks need idempotency handling since Slack retries on any non-200 response within seconds - a naive handler will double-approve requests. The bigger product risk is scope creep toward becoming a full expense-report tool; the value here is the approval queue and the ledger, not reimbursement workflows.