A note on honesty: these are internal builds and capability demos, not client case studies — most client work sits under NDA, and we won't invent logos to fill a page. Each one is a real, working system you can ask us to demo on a call.
Pulls vendor, dates, line items, and totals from scanned invoices in mixed formats. Built on a fine-tuned open model — and when it isn't sure about a field, it flags it for a human instead of guessing.
Scanned PDFs and photos in mixed layouts
Structured fields: vendor, dates, line items, totals
About 96% of fields read correctly on a 400-document test set
Handwritten invoices go straight to human review
Ask questions in plain language over a folder of PDFs and internal wikis; get answers with citations back to the source page. Built for teams that can't send documents to external APIs.
A folder of PDFs and internal wiki pages
Plain-language answers, each cited back to its source page
Runs entirely on-prem — documents never leave your network
Answers are only as current as the documents you index
Classifies e-commerce product photos by category, colour, and angle, and catches common listing errors like wrong-category uploads before they reach customers.
E-commerce product photos, any resolution
Category, colour, and angle tags, plus flagged listing errors
Public datasets; adapts to a catalogue with a few hundred labelled examples
New product types need a small labelling pass first
A forecasting harness that pits classical methods against gradient boosting and neural approaches on your sales history — and tells you which one actually wins. Spoiler: it's often the simple one, and knowing that saves money.
Your historical sales or demand data
Side-by-side accuracy scores for classical, boosted, and neural methods
To settle "do we need a fancy model?" with numbers, not opinions
Forecasts degrade on sparse or very short histories
A validation layer that sits on top of an existing warehouse and alerts when incoming data drifts: missing fields, sudden distribution shifts, duplicate spikes. Built because bad data broke one of our own projects, twice.
Tables in your existing data warehouse
Alerts on missing fields, distribution shifts, and duplicate spikes
Bad data silently broke two of our own projects — this is the fix
Alert thresholds need a short tuning period on your data
Our starting point for deployments: a containerised API with request logging, drift monitoring, cost tracking, and rollback. Every production project we do begins from this template, so nothing ships without observability.
Any trained model — ours or one you already have
A containerised API with logging, drift and cost monitoring, rollback
The foundation of every production deployment we ship
It's a template, not a product — it's adapted per project
Don't take a webpage's word for it. Here's how to check whether any of this holds up.
Every demo on this page runs live on a call, on real inputs — not a pre-recorded video. If something breaks, you'll see that too. That's the point.
Each build has a short written evaluation: what it was tested on, where it fails, and how often. We'll share it before you commit to anything.
The strongest test is your data. Send a small, non-sensitive sample and we'll run it through the relevant demo while you watch.
Want to see any of these running, or talk about whether the same approach fits your problem? Curious what hardware each demo actually runs on? That's documented too, on our compute page.
Book a Demo Call