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 from February 2020 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 CV does not name a sector for this engagement. It writes the client as Dunnhumby (Tesco) and describes internal products, nothing more, so the classification here is inference from the client name and the work described.

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.

His CV states the deliverable and the intent behind it and does not break the internals down further. This record stops where the CV stops.

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.