01
Consolidate
Staff see open orders, committed spend, and delays across suppliers — including phone deals that never existed on any vendor portal.
Internal case study
Buddi Procurement Intelligence
Multi-Source Purchasing Layer
Buddi already buys across supplier platforms, calls, quotes, and invoices. This layer unifies that operational picture, automates the repetitive capture, and lets staff query both live orders and internal documentation.
Next.jsFastAPINeonLangChainLambda
- Role
- Full Stack · AI · Cloud Engineer
- Domain
- Procurement / Operations Intelligence
- Users
- Buddi Limited internal operations
- Market
- United Kingdom
- Stack
- FastAPI · Lambda · Neon · LangChain · pgvector · EventBridge
Problem
Each supplier platform knows its slice of purchasing. Nobody has the whole operation in one place.
Buddi buys through multiple supplier portals, plus phone negotiations, quotes, invoices, and later commercial documents. The individual platforms can work well. They still cannot answer company-wide questions.
Integrate before rebuild
If a supplier portal already shows orders, products, statuses, and quantities, Buddi does not need a clone of that portal. It needs that information inside one defensible picture.
Open orders, committed spend, delayed deliveries, last paid price for a SKU, and which deals happened by phone required hopping across systems — or retyping an invoice that already contained the data.
Operational facts and internal procedure lived in different worlds. Staff could see a delayed order in one tool and still had to hunt the policy for incomplete shipments in another. The shipped product is a consolidation and intelligence layer — not a replacement ERP.
See the fragmentationThen see the consolidation layer
Solution
Four modules over systems Buddi already uses — not another purchasing portal.
Normalize every order into one model, ingest off-platform purchases from documents, answer questions with tools plus RAG, and run syncs and exports on a schedule even when nobody has the app open.
02
Ingest invoice
A phone purchase arrives as invoice.pdf. The employee drops the file; the system proposes vendor, SKU, qty, unit price, and total instead of retyping the document.
03
Confirm
Deterministic checks flag qty × price mismatches. A human corrects and confirms. Only then does the order join the consolidated history.
04
Ask
“Which orders are late, and what procedure applies?” hits live data tools plus cited internal documents — or abstains when evidence is missing.
What the platform does
Operational consolidation
Adapters pull supplier A, B, and C into a unified order model — original status preserved, normalized status shared — so open spend and delays are visible in one view.
Document intelligence
Invoices, quotes, POs, and packing lists become structured fields after parse → extract → normalize → validate. The original PDF stays in S3 with the confirmed record.
Human-in-the-loop persistence
AI never writes blindly into the operational database. Extraction is reviewed, math is checked in code, then a person confirms before history is updated.
Hybrid operations assistant
Not RAG-only. A query router chooses structured tools, document retrieval, or both — so delayed orders and the incomplete-shipment procedure can land in one answer.
Four integration levels
API first, then CSV/XLSX/JSON exports, then documents, then manual entry. Capability of the supplier — not a single happy-path integration — drives the design.
Automation that outlives the browser
EventBridge schedules syncs and Monday exports. SQS fans out invoice batches. Short jobs run on Lambda; heavy reprocessing uses a Fargate task that starts, works, and stops.
Impact
One operational picture. Less retyping. Answers that cite evidence.
The platform is in internal use. Staff work from one operational picture: invoice review instead of retyping, a Monday consolidado that writes itself, and supplier-spend questions that no longer require three portals.
01 - Operational reality
Purchasing was split across supplier A/B/C portals plus phone deals that never appeared in those systems. Documents already held the missing fields; people retyped them anyway.
02 - Engineered response
Adapters, a unified order model, document intelligence with human confirmation, and a hybrid assistant that uses data tools and RAG. Scheduled syncs update the picture at 02:00 without anyone opening the app.
03 - In daily use
An employee opens the internal app, sees open orders, delayed ops, and committed spend, filters by supplier, drops an invoice instead of digitizing it, and asks both “what is late?” and “what procedure applies?”
What shipped
4
Integration levels
API, structured export, documents, then manual — so a supplier without an API is not a blocker.
16
V1 capabilities
From multi-source orders through human confirmation, hybrid Q&A, scheduled export, RBAC, and AWS production deploy.
5m → 30s
Invoice capture
The operational shift the product was built around: retyping an invoice versus reviewing an extraction. These before/after figures are the value criterion, not a measured KPI report.
AI that duplicates what supplier portals already do
The six-month delivery is a consolidation, document, data, AI, automation, and cloud layer in internal use — not a RAG demo and not a generic CRUD app.
Architecture
How the purchasing layer is engineered.
Serverless AWS, supplier adapters, document workers, and a query router that treats structured data and RAG as different tools — not one chatbot over everything.
System Overview
Employees hit a private Next.js app on CloudFront. API Gateway fronts FastAPI on Lambda. Neon holds the unified order model and the RAG vectors; S3 holds originals. LangChain runs chunking, embeddings, and retrieval in the application. EventBridge and SQS keep work moving when the UI is closed.
Employees
Web app
API + FastAPI
Neon + S3
Async workers
AI service
| Layer | Role | Stack |
|---|---|---|
| Employees | Authenticated internal staff — purchasing, analysts, admins, read-only. | Cognito / SSO · RBAC |
| Web app | Private SPA/static frontend for consolidated orders, review queues, and the assistant. | Next.js · S3 · CloudFront |
| API + FastAPI | Familiar HTTP app inside Lambda via Lambda Web Adapter — no event-shape rewrite. | API Gateway · Lambda · FastAPI |
| Neon + S3 | Normalized orders, users, events, chunks, and embeddings in Neon Postgres; binaries and exports in object storage. | Neon · pgvector · S3 |
| Async workers | Invoice batches and long jobs leave the request path: SQS → Lambda or Fargate. | SQS · Lambda · ECS Fargate |
| AI service | Application RAG: LangChain chunking, embeddings, and retrieval, plus tool calling for live orders. | LangChain · Tool calling · RAG |
Next.jsFastAPILambdaNeonLangChainSQSEventBridgeFargate
Decisions
Lessons
Design constraints
Constraints the delivered product keeps.
- Integrate before rebuild — the product risk is cloning working supplier tools.
- Human confirmation on extracted commercial numbers is cheaper than a polluted price history.
- The assistant is a router over tools and evidence, not a chatbot with a vector index glued on.
Eval before “it seems to work”
How production AI on this platform is judged.
- Document parsing is scored on a labeled invoice set — vendor, number, currency, qty, price, total.
- RAG is scored on a golden Q&A set: retrieval, answer, citation, and correct abstention.
- End-to-end covers drop invoice → confirm → order appears → assistant can query it → export contains it.
Cloud judgment
What this architecture is for — and not for.
- Scale-to-zero fits internal idle time; keep Neon compute warm if the workday is always hot.
- Skip Kubernetes until there is a problem it uniquely solves.
- AWS covers Lambda, S3, SQS, EventBridge, and Fargate. The database is Neon, and the RAG pipeline is LangChain in the application.
Next step
Want to walk through a procurement intelligence layer?
This is Buddi’s internal platform, built and in use. Reach out to discuss adapter design, document-intelligence eval, hybrid assistants, or serverless AWS for operational tools.
Keep exploring