Most engineering write-ups about adding AI to a product lead with the AI. This one leads with where we chose not to put it.
A partner came to us with a familiar kind of problem: a business-critical process still running almost entirely on spreadsheets. Data arrived daily from a wide network of external partners, each using its own format, with no shared structure and no shared visibility into where anything stood. The bottleneck wasn’t the underlying work. It was coordinating it by hand.
That’s the kind of problem our dedicated IT solutions team builds custom software around: replace the manual process with a platform that imports the incoming data, routes it to the right internal specialists, tracks status end to end, and gives everyone a single, current view of what’s happening.
The stack was set by the partner, and that was fine. Angular on the frontend, NestJS on the backend, Microsoft SQL Server for the database, all matched to what their own small internal technical team already knew and would maintain going forward. Our developers would have defaulted to different choices. It didn’t matter. The team that owns this after we’re gone gets a say in what it’s built with, and that’s a straightforward trade-off: our short-term preference against their long-term ownership.
The interesting problem wasn’t technical, it was structural. Every external partner exported its data differently. Different column names, different layouts, different conventions for the same underlying information. Before any internal specialist could act on a case, someone had to manually reshape that file into something consistent. That reformatting step was mostly operational overhead: not the substantive judgment the specialists were there to make, but tedious, error-prone work standing between the data arriving and the real work starting.
That’s the one place we used AI. It sits at the import step and maps incoming files to a consistent internal structure, even when source spreadsheets use different layouts, column names, or conventions. Ambiguous mappings are flagged for human review instead of being accepted silently. The scope is deliberately narrow: format normalization, not decision-making. It does not make or approve the judgment calls that follow. Those remain with the partner’s own specialists. In a workflow where a wrong decision can have a direct financial or compliance consequence, AI is useful for preparing structured input, not for replacing accountable human judgment. That boundary is something our AI development work comes back to on almost every regulated or high-stakes build.
The rest of the platform is what you’d expect from a well-built internal tool: a queue for routing work across the team, status tracking people can actually rely on, and built-in messaging tied to each case so questions don’t get lost in an email thread.
Working with a small, lean partner team changes how you deliver. There was no room to wait on detailed specs between check-ins, so we didn’t try to get one. The partner gave us a general, high-level brief and regular demo cycles, and our dedicated team made UX and workflow calls directly, then validated them live at each demo. It’s a model that only works with a partner who trusts the team to make practical product decisions quickly, while keeping a lightweight record of key decisions, demo feedback, and acceptance points. It moved faster than a heavier spec-and-signoff process would have, without losing the traceability needed for handover.
The result is a process that used to run on scattered spreadsheets and now runs on a platform with one clear operational view.