A shared portal for Dunnhumby's internal products, implemented on a fixed ten-week remote contract so front-end and back-end code could be re-used across whatever came next.

Dunnhumby had several internal products in play and wanted one portal underneath them. We took a fixed ten-week remote contract to implement it. The recorded goal is code re-use across both the front-end and the back-end, so that new products and new features could be put together faster than by starting each one from an empty repository.

The sector here is our own classification, inferred from the client and the work rather than given. The engagement was internal products for Dunnhumby, which is part of Tesco.

The contract was fixed at ten weeks and worked entirely remotely. A shared portal earns its keep only when other teams build on it, which pushes the design decisions to the front of a short engagement and leaves very little room to change direction at week six.

The stack spans two runtimes. React, Node and TypeScript on one side, .Net Core on the other, deployed on GCP and split into microservices, so anything shared had to hold up in both places.

We implemented the portal and the shared layer beneath it across the ten weeks. Front-end in React and TypeScript, back-end across Node and .Net Core, tests in Jest, source and pipeline through Git and GitLab, all on GCP with a microservice split.

We can evidence the deliverable and the intent behind it. The internals are not something we can break down further, and this page does not try.

What is on record is the shape of the thing and the time it took: a portal several internal products could sit on, built inside a fixed ten weeks by one developer working remotely.

No adoption or performance figures exist for this engagement, and none have been added. Read it as a short, well-defined piece of platform work, not a scale story.