Use case

A purchase order system that fits how you actually buy.

Most PO processes live in email threads and a spreadsheet named FINAL_v3. Requests get approved twice or not at all, nobody knows what's been received, and month-end is archaeology. Describe your buying process in plain language and get a system shaped to it - thresholds, approvers, suppliers, receiving - with every decision logged.

What your generated system includes

Data model

  • Purchase orders: items, amounts, supplier, cost center, status
  • Suppliers with terms and contacts
  • Receiving records tied to each PO
  • Budget references per department

Approval flow

  • Under your threshold: auto-approve and log
  • Over threshold: route to the right approver
  • Multi-step for large amounts (manager → founder)
  • Full audit trail on every decision

Automations

  • Email or Slack alert to approvers with one-click context
  • Reminder when a PO sits unapproved for 2 days
  • Notify the requester on approval or rejection
  • Flag POs received but not matched to an invoice

AI steps (optional)

  • Extract line items from an emailed supplier quote
  • Flag unusual amounts vs. supplier history
  • Draft the PO from a plain-language request
  • All with human approval before anything commits

Try this exact prompt

Paste into Chromoly

Build a purchase order system. My team submits PO requests with supplier, items, and amount. Under $2k auto-approves; $2k-$10k goes to the department manager; over $10k comes to me. Approvers get a Slack alert, requesters get notified of the decision, and remind approvers after 2 days. Track receiving against each PO and flag anything received without a matching invoice.

Adjust the thresholds and route names to your reality - the generated preview shows the whole flow before anything deploys, and changing a threshold later is one sentence in chat.

Why a real PO system beats the spreadsheet

The spreadsheet version fails quietly: an approval given verbally, a PO paid twice, a committed spend nobody rolled up. The failure isn't discipline - it's that a spreadsheet has no process state. A generated PO system carries each request through explicit stages, so "what's awaiting approval" and "what did we commit this month" are views, not investigations.

And because approval rules live in the system definition, changing them - new threshold, new approver, new cost center - is a described change with a previewed blast radius, not a quiet edit that breaks three formulas.

Frequently asked questions

Can approval thresholds change later without breaking things?

Yes - that's the point of the architecture. Thresholds and routing live in the system definition, so changing them is a plain-language request that shows exactly which workflows and screens are affected before it applies, with one-click rollback if needed.

Can suppliers or external accountants see anything?

If you want - client-facing views are included. A supplier portal showing open POs and received status, or read access for your accountant, is part of the same build. End users are included in your plan, no per-seat charges.

Who maintains the system after it's built?

Chromoly does - monitoring, security patches, AI model upgrades, and integration migrations are platform-owned for the lifetime of the account. Changes you request run through a dependency-aware preview showing the blast radius before anything ships.

Can I import my existing data?

Yes - export your current spreadsheet or tool to CSV and import with column mapping, or attach the spreadsheet to your prompt and Chromoly shapes the data model from it directly.

Stop approving purchases in email threads

Describe your process in plain language. Preview the working system free - deploy when it's right.

Start free →

150 credits/month free forever · EU-hosted · maintained for life