Data and Backend Staff Augmentation Case Study

The challenge

PoochPay provides end-to-end invoice management, with the aim of taking its clients off paper-driven manual accounts payable processes, reducing the cost of running AP, keeping vendors accountable and giving a company a view of what it is actually spending. Delivering that meant two pieces of work at once that its team was not sized for. The application itself needed an overhaul, and underneath it the platform needed a backend capable of holding client invoice data on its servers and processing it on demand rather than in batches. The second gap was analytical rather than an engineering one. A product whose value proposition is visibility into spend needs somebody who can read the data itself, both to shape the reporting clients see and to inform the development decisions being taken around it.

The approach

We staffed both gaps as one team. Three .NET developers took the application work, two Python developers and an AWS developer built out the backend and the infrastructure it runs on, and two QuickSight developers, one senior and one junior, covered the reporting and visualisation layer, with the senior analyst working on the data itself rather than only on charts. Placing the analytics capability alongside the engineering rather than after it is the point of the arrangement, because decisions about how invoice data is stored and processed are difficult to revisit once a platform is live. The team joined PoochPay's own development pipeline and was resized as the phases of the year demanded.

The outcome

Eight dedicated remote developers were augmented for twelve months, over which the invoice management solution was delivered and the data visualisation the product depends on was built alongside it rather than added at the end. PoochPay scaled the team up and down through the engagement against its own requirements, and the bottlenecks the augmentation was brought in to clear were cleared without the rest of the development pipeline being interrupted.

Two things are usually staffed separately that should not be. The engineers decide how the data is stored and the analysts later discover what that decision costs them, by which point the platform is live and the answer is a migration.

What accounts payable software is actually being asked to do

Accounts payable is a matching problem before it is a workflow problem. An invoice arrives claiming that something was ordered, delivered and priced at a figure, and the system’s job is to establish whether all three of those are true before money leaves. Paper-driven AP is expensive not because filing is slow but because the evidence for each claim sits in a different place from the claim.

That is the category PoochPay set out to replace, and it explains why the product’s value proposition is visibility into spend rather than faster approvals. Approvals are the visible part. Knowing what a company is actually committed to, per vendor, per period, is the part that is hard to produce from paper at all.

Why processing on demand rather than in batches changes the architecture

A batch pipeline gives an answer that is as old as the last run. For an approvals queue that is tolerable; for a spend figure someone is about to make a commitment against, it is not, because the number on screen is confidently wrong by exactly one cycle.

Processing invoice data on demand means the storage layer has to support reads at the grain a user asks questions at, not only at the grain the loader writes them. That is a decision taken when the backend is designed. Two Python developers and an AWS developer built that layer and the infrastructure under it, which is where the choice actually lives.

Why the analytics seat sat inside the team rather than after it

Two QuickSight developers covered reporting and visualisation, and the senior of the two worked on the data itself rather than only on charts. That is the whole point of the arrangement.

The failure it avoids is well known and rarely designed against. Schema decisions constrain the questions a reporting layer can answer — the grain a fact is stored at, whether history is kept or overwritten, whether an amount carries its currency and its date. Every one of those is cheap to choose correctly while the tables are being written and expensive to change once a platform holds live client invoice data.

A reporting requirement discovered after go-live is not a dashboard task. It is a migration.

What the shape of the team was doing

Eight developers over twelve months, in three groups against three distinct problems: three .NET developers on the application overhaul, three people on the backend and its infrastructure, and two on the data. The team was resized as the phases of the year demanded rather than held at its starting size.

Putting a senior data person in the room while the backend is being designed is cheaper than any amount of reporting work afterwards, and it is why we treat data capability as part of the delivery team in an AI-ready ODC rather than as a service bolted on to custom software development.