Skip to content
Case Studies

The engineering behind the screenshots

Each case study below sets out the client's challenge, the solution we built, the architecture behind it, the technologies used, the outcome and the timeline — so you can judge whether we would be a good fit for your problem.

Client names are withheld where our agreements require it. Outcomes describe the capability delivered — we do not publish performance figures we cannot substantiate. References can be arranged for serious enquiries.

Book Free Strategy Call View Full Portfolio
FBR Digital Invoicing AI Sales Automation Zentori ERP Enterprise SaaS AI Business Automation School Management
Case Study 01 Tax & Compliance

FBR Digital Invoicing Integration

Real-time statutory e-invoicing between a business billing system and Pakistan's Federal Board of Revenue.

Client Challenge

The client was required to submit every sales invoice to the FBR digital invoicing service in real time. Their existing billing system had no integration path, and the compliance team was manually re-entering invoices into a government portal — slow, error-prone, and impossible to reconcile at month end.

The submission API also failed unpredictably: intermittent timeouts, occasional schema rejections, and no reliable way to tell whether a timed-out invoice had actually been recorded. Duplicate submissions were a real compliance risk.

Timeline

  • W1–2Discovery, API analysis, field mapping
  • W3–5Validation engine & submission service
  • W6–7Retry queue, reconciliation, audit log
  • W8UAT, parallel run, production cutover

Our Solution

  • A validation layer that checks every invoice against the FBR schema and business rules before submission, so rejections are caught locally.
  • An asynchronous submission service backed by a durable queue, with exponential backoff and a bounded retry policy.
  • Idempotency keys per invoice so a retried submission can never create a duplicate filing.
  • A reconciliation job that queries submission status for anything left in an uncertain state.
  • An operations dashboard showing submitted, pending, failed and reconciled invoices with full request/response history.

Architecture

Billing system adapter

Captures invoice events via API or database change feed

Validation & mapping service

Schema checks, tax-rule validation, payload construction

Queue + submission workers

Idempotent, retried, rate-limited FBR API calls

Audit store & reconciliation

Immutable attempt log, status sweeps, ops dashboard

Technologies

Python FastAPI PostgreSQL Redis Celery Docker

Results

Manual re-entry eliminated

Invoices are submitted automatically at the point of issue; the compliance team reviews exceptions instead of typing every record.

No duplicate filings

Idempotent submission and reconciliation removed the duplicate-filing risk that manual retries created.

Audit-ready by default

Every attempt, response and status change is recorded, so month-end reconciliation is a query rather than an investigation.

Case Study 02 AI Agents

AI Sales Automation Platform

An agent pipeline that researches prospects, drafts personalised outreach, and waits for human approval before anything sends.

Client Challenge

A small B2B sales team was spending most of its week on research rather than conversations. For each prospect someone had to find the company, understand what it did, identify the right contact, and write something specific enough not to read as a template.

Off-the-shelf automation tools solved the volume problem by removing the personalisation entirely — which produced worse results and put the sending domain at risk. The team wanted the research speed without the generic output.

Timeline

  • W1–2Workflow mapping, data sources, evaluation criteria
  • W3–5Research & enrichment agents, prompt/eval harness
  • W6–8Drafting agent, approval UI, CRM sync
  • W9–10Sequencing, deliverability controls, rollout

Our Solution

  • A research agent that gathers public company information and normalises it into a structured prospect profile.
  • An enrichment step that fills contact and firmographic gaps from third-party APIs, with source attribution.
  • A drafting agent constrained to reference only facts present in the profile — reducing plausible-sounding fabrication.
  • A review queue where a person approves, edits or rejects each draft; nothing sends without that step.
  • An evaluation harness scoring drafts against a labelled test set, run on every prompt or model change.

Architecture

Lead intake

CRM sync, CSV import, inbound form capture

Agent orchestration

Research → enrich → draft, with tool calling and retries

Human approval queue

Review, edit, approve or reject — the mandatory gate

Send & sequence

Rate-limited sending, follow-ups, reply detection, CRM write-back

Technologies

Python FastAPI LLM APIs Next.js PostgreSQL Redis

Results

Research time collapsed

The manual research-and-draft step became a review step — the team spends its time deciding, not digging.

Personalisation preserved

Drafts cite specific, verifiable details about each prospect rather than falling back on template language.

Nothing sends unreviewed

The approval gate keeps a human accountable for every outbound message and protects sender reputation.

Case Study 03 ERP

Zentori ERP with Asset Management

A modular ERP replacing spreadsheet-driven operations across sales, purchase, inventory and fixed assets.

Client Challenge

Operations ran across several disconnected spreadsheets and a legacy accounting package. Stock figures disagreed between locations, purchase approvals happened over email with no record, and producing a management report meant a day of manual consolidation.

A previous attempt at an off-the-shelf ERP had stalled because it forced workflows the business did not use, and the team had rejected it during rollout.

Timeline

  • M1Process mapping, data model, module priority
  • M2Inventory & multi-location stock go-live
  • M3Sales, purchase & approval workflows
  • M4Asset register, reporting, training & handover

Our Solution

  • Deployed our modular ERP core and configured it to the client's existing processes rather than the reverse.
  • Phased rollout starting with inventory — the module with the clearest pain — so the team saw value in month two.
  • Multi-location stock with transfers, adjustments and a full movement history per item.
  • Purchase approval workflow with role-based limits, replacing email chains with a recorded decision trail.
  • Fixed-asset register with assignment, depreciation schedules and disposal tracking.
  • Role-based dashboards so operations, finance and management each see their own view of the same data.

Architecture

Web client

React SPA with role-scoped navigation and dashboards

Modular ERP services

Sales · purchase · inventory · assets · finance

Shared data layer

PostgreSQL with per-entity audit history

Containerised deployment

Docker images, per-client environment, automated backups

Technologies

Python PostgreSQL React Docker Redis

Results

One source of truth

Stock, sales and purchase data live in one system, so location figures reconcile without manual comparison.

Approvals on record

Purchase decisions carry a recorded approver, timestamp and value limit instead of sitting in an inbox.

Reporting on demand

Management reporting became a dashboard view rather than a day of spreadsheet consolidation.

Case Study 04 Enterprise SaaS

Multi-Tenant Enterprise SaaS Platform

Taking a single-customer application to a sellable, multi-tenant SaaS product.

Client Challenge

The client had a working application built for one customer and a pipeline of others who wanted it. But the system assumed a single organisation throughout: no tenant boundary, shared configuration, hard-coded settings, and onboarding that meant a developer deploying a separate copy per customer.

There was also no billing, no self-service onboarding, and no way for support to look at a customer's account without direct database access.

Timeline

  • M1Tenancy model design, migration plan
  • M2Tenant isolation, auth, roles & permissions
  • M3Billing, plans, onboarding flow
  • M4Admin console, metering, monitoring, launch

Our Solution

  • Introduced a tenant boundary through the data model with enforced scoping at the query layer, plus tests that fail if a query can cross tenants.
  • Migrated the existing customer's data into the new model without downtime or data loss.
  • Role and permission system supporting team accounts, invitations and per-tenant configuration.
  • Subscription billing with plans, trials, upgrades, proration and usage metering.
  • Self-service onboarding so a new customer no longer requires a developer.
  • Internal admin console with scoped, audited support access — no more direct database queries.

Architecture

Next.js application

Tenant-aware routing, onboarding, billing portal

API services

FastAPI with enforced tenant scoping and RBAC middleware

Data & metering

PostgreSQL with tenant keys, Redis cache, usage events

Kubernetes platform

Staged environments, CI/CD, autoscaling, monitoring

Technologies

Next.js TypeScript FastAPI PostgreSQL Redis Kubernetes

Results

Onboarding without engineering

New customers sign up and configure their own workspace instead of waiting on a developer deployment.

Revenue operations in place

Plans, trials, upgrades and invoicing run automatically, with usage metered per tenant.

Support without database access

The admin console gives support scoped, audited visibility — a material reduction in operational risk.

Case Study 05 AI Automation

AI Document Processing Automation

Turning a high-volume manual document queue into an automated pipeline with human review only where it's needed.

Client Challenge

An operations team received documents continuously — as email attachments, uploads and scans — in inconsistent formats. Each one was opened, read, categorised and re-keyed into an internal system. The backlog grew whenever volume spiked or staff were away.

Accuracy mattered more than speed: a mis-keyed value downstream was expensive to unwind, so any automation had to be measurably safer than the manual process, not just faster.

Timeline

  • W1–2Document sampling, field definition, accuracy baseline
  • W3–5Ingestion, classification & extraction pipeline
  • W6–7Confidence scoring, review queue, write-back
  • W8–9Shadow run against manual process, then cutover

Our Solution

  • Unified ingestion from mailbox, upload and API into a single processing queue.
  • Classification by document type, then type-specific field extraction rather than one generic prompt for everything.
  • Per-field confidence scoring; anything below threshold routes to a human review queue instead of being written.
  • A labelled evaluation set built from real documents, so accuracy could be measured before go-live and tracked after.
  • A shadow period running automation alongside the manual process to compare outputs before switching over.
  • Structured write-back to the internal system with a link to the source document on every record.

Architecture

Ingestion

Mailbox poller, upload endpoint, API intake

Classify → extract → score

Worker pool with per-type extraction and confidence output

Review queue

Low-confidence items surfaced side by side with the source

Write-back & archive

Structured records, source links, immutable processing log

Technologies

Python LLM APIs Celery Redis PostgreSQL Docker

Results

Review, not re-keying

The team's role shifted to handling exceptions, and volume spikes no longer create a backlog.

Accuracy measured, not assumed

A labelled evaluation set and a shadow run proved the pipeline's accuracy before it replaced anyone's work.

Traceable to source

Every extracted record links back to the original document and the processing decisions behind it.

Case Study 06 Education

School Management System

Admissions, attendance, results and parent communication in one system, with an assistant for routine queries.

Client Challenge

Administration ran on paper registers and spreadsheets. Attendance was compiled by hand, results were assembled per term under time pressure, and parents phoned the office for information that existed but was not accessible to them.

Staff had limited appetite for a complex system — anything requiring lengthy training was unlikely to survive the first term.

Timeline

  • M1Requirements, data migration plan, role design
  • M2Student records, attendance, staff portal
  • M3Results, reporting, parent access
  • M4Assistant for routine queries, training, handover

Our Solution

  • Central student record covering admission, class assignment, attendance and results history.
  • Attendance capture designed for speed — a class marked in under a minute on a phone or tablet.
  • Results entry with automatic aggregation, grade calculation and printable report cards.
  • Parent access to their own child's attendance, results and announcements.
  • An assistant that answers routine questions ("when is the next holiday", "what is my child's attendance this month") from the school's own data, reducing office calls.

Architecture

Role-based portals

Admin, teacher and parent views over shared data

Core services

Students, attendance, assessment, announcements

Assistant layer

Answers scoped strictly to the requesting user's permissions

Data layer

PostgreSQL with per-record change history and backups

Technologies

Python FastAPI React PostgreSQL LLM APIs

Results

Registers replaced

Attendance and results are captured once, at source, and available immediately rather than compiled later.

Fewer office calls

Parents self-serve the information they used to phone for, with the assistant handling routine questions.

Adopted, not abandoned

Interfaces were designed around the fastest path for each role, so the system survived past the first term.

Ready to Build Your Next AI Product?

Book a free 30-minute call. We'll go through your requirements and tell you what it would realistically take to build.

Schedule Free Consultation Talk to an Expert