Thousands of users and one contract

Most requirements are a conversation. These were a contract, and the difference changes how you build.

The client represented multiple brands, so this project had to be multi-tenant right out of the gate.

The stack was React on the front, ASP.NET Core APIs behind it, Azure Cosmos DB underneath, and single sign on across thousands of users who were not employees of the company I was working for.

They wanted to see their video lead data to gauge the performance of video marketing over time. This was a new program for them, but they still held to old data ingestion using csv import from a secure file transfer location.

The interesting work was not the dashboards. It was what I found under them: data access written as SQL strings, assembled by hand, working perfectly and completely untestable. You cannot write a unit test against a string.

So it became expression builders. Composable, typed, and testable one piece at a time.

The trickiest aspect of this approach was turning it into a lakehouse in Microsoft Fabric. The data was taken raw, then cleaned up through a medallion pipeline so that the expression builder only operated on gold data. Normalizing csv vendor data in a new cloud architecture and programming language took a lot of learning, trial and error.

Was it worth doing before the feature work rather than after? Yes, and I would argue that on any project. The feature work was going to touch every one of those queries anyway. Doing it in the old style would have meant writing the thing twice, once badly.

All of this was identified with the client and project management up front, to set realistic delivery expectations. Project shipped, client happy.