The problem, the approach, the numbers
Four engagements described honestly — including what was harder than expected. Figures are shared with client permission; identifying details are generalised where requested.
Nine-day month-end close cut to two
The problem. A three-plant components manufacturer ran production on paper job cards, stock in one spreadsheet, and costing in another. Nobody could answer "what did that order actually cost us" without two days of reconciliation, and month-end close consistently took nine working days.
What we did. Eight weeks of process mapping across all three plants first — deliberately slow, because the plants worked differently and pretending otherwise would have sunk the rollout. We then built a single ERP with plant-specific workflows on a shared data model: production planning, BOM-based costing, quality checkpoints, stores and dispatch. Rollout was plant by plant over four months.
What was hard. Historic stock data was unreliable. We ran a full physical count before go-live at each site rather than importing numbers we could not trust — it delayed the second plant by three weeks and was still the right call.
- Month-end close: 9 days → 2 days
- Order costing available same-day
- Stock accuracy: 71% → 98%
- Four spreadsheets retired
Engagement snapshot
| Sector | Manufacturing |
| Duration | 7 months |
| Team | 6 people |
| Stack | .NET, SQL Server, Azure |
| Model | Fixed scope + AMC |
Engagement snapshot
| Sector | Logistics |
| Duration | 10 weeks |
| Team | 4 people |
| Stack | AWS, Terraform, Docker |
| Model | Time & material |
Zero-downtime cloud migration, 34% lower hosting cost
The problem. A logistics operator's tracking platform ran on two ageing physical servers in a Mumbai data centre. Peak-season load caused daily slowdowns, there was no tested disaster recovery, and the hardware was out of warranty.
What we did. Rather than lift-and-shift everything, we containerised the application, moved the database to a managed service with automated backups, and put the static assets behind a CDN. Infrastructure was defined in Terraform so the whole environment could be rebuilt from scratch. Cutover ran at 02:00 on a Sunday with a rehearsed rollback plan we did not need.
What was hard. A scheduled job written eleven years earlier depended on a local file path nobody had documented. We found it during the second rehearsal — which is exactly why we rehearse twice.
- Hosting cost down 34%
- Zero downtime at cutover
- Peak page load 4.1s → 1.3s
- DR restore tested quarterly
A mobile app that reached 4.6 stars and stayed there
The problem. A regional retail group had a loyalty programme running on plastic cards and a call-centre helpline. Redemption was manual, and the marketing team had no way to see what worked.
What we did. Six weeks of design first — including usability testing with actual customers in two stores, which changed the checkout flow substantially before any code was written. The app shipped on Flutter for both platforms, with offline card display, real-time points, personalised offers and store locator. Marketing got a self-service campaign console so they never need to raise a ticket to launch an offer.
What was hard. Migrating twelve years of loyalty history with duplicate customer records. We built a merge-review tool and had the client's own team adjudicate the ambiguous cases rather than guessing on their behalf.
- 4.6★ average store rating
- Delivered on the promised date
- Redemption handling time −80%
- Campaigns launched without IT
Engagement snapshot
| Sector | Retail |
| Duration | 5 months |
| Team | 5 people |
| Stack | Flutter, Node.js, PostgreSQL |
| Model | Dedicated team |
Engagement snapshot
| Sector | Distribution |
| Duration | 12 weeks |
| Team | 3 people |
| Stack | Python, OCR, AWS |
| Model | Fixed scope |
1,400 invoices a month, processed without typing
The problem. A distribution business had two full-time staff keying vendor invoices into the ERP and matching them against purchase orders. Errors surfaced weeks later during payment runs.
What we did. Built an extraction pipeline that reads incoming invoices — PDF or scanned — pulls line items, matches them against open POs and pushes clean records into the ERP. Anything it is not confident about goes into a review queue with the original document alongside, rather than being auto-approved.
What was hard. Handwritten annotations on delivery-linked invoices. We deliberately did not try to read them; those documents route straight to human review, which keeps the automated path trustworthy.
- ~1,400 invoices/month automated
- 82% straight-through processing
- Data entry effort reduced ~70%
- PO mismatches caught at entry
Want a reference call with one of these clients?
For serious enquiries we are usually able to arrange a direct conversation with a client in a comparable sector.