Skip to main content
TL
Illustration of the B2B ordering portal

B2B ordering portal

Moving orders out of an internal spreadsheet and opening entry to customers.

Role

Technical lead

Period

Technical stack
  • React
  • TypeScript
  • NestJS
  • MySQL
  • TypeORM
  • TanStack Query
  • Azure
orders per season
1 000+
users
~100
to v1.0
5 mois
01

The context

  • The internal team alone handles seasonal commitments, orders and delivery planning, in Excel.
  • Their commercial data already lives in an ERP, and replacing it is off the table.
  • The portal opens order entry to over a hundred customers, each seeing only their own data.
02

My mission

  • Stack selection and Azure infrastructure design.
  • Writing the technical architecture document.
  • Implementing the entire backend.
  • Delivery pipeline on Azure DevOps: build, SonarQube quality gate and no critical vulnerability gate the deployment.
  • Supervising the frontend developer and defining the conventions shared by both applications.
  • Client-facing technical contact: specification alignment and estimation of new work.
03

Decisions and trade-offs

  1. 01

    Delivering in increments instead of one release

    Problem

    The client expects a finished product and keeps revising their requests, while the ERP synchronisation runs late.

    Solution

    Re-cutting the backlog to ship the features that were already ready.

    Why this choice

    Requirements only settle once the client is actually using the product.

  2. 02

    Building the synchronisation ahead of the API

    Problem

    The ERP team's API arrives two months late. The synchronisation depends on it, along with its transaction and conflict-resolution logic.

    Solution

    Development and testing against the interface contract, with data sets produced for the purpose. The feature stays disabled in production until the API ships.

    Why this choice

    The contract is available and frozen. Waiting stalls the most complex part of the backend on an external dependency.

  3. 03

    Recovery driven by hand rather than automatically

    Problem

    The synchronisation fails in two ways: pulling data from the ERP, and pushing to the ERP, which times out when it takes too long to answer.

    Solution

    Inbound, no automatic retry: the administrator sees the status per category and replays only the one that failed. Outbound, an icon flags the failure and an internal queue replays timed-out pushes once.

    Why this choice

    The administrator replays when they need fresh data, whereas a blind retry would resynchronise unprompted. On pushes, a single replay absorbs around 90% of the errors we see.

  4. 04

    Ruling out Next.js in favour of a standalone backend

    Problem

    The team maintains Go, C# and JavaScript. Whatever is chosen has to stay maintainable by them over time. Next.js is proposed to cover both front and back in one place.

    Solution

    A separate React frontend, a standalone NestJS backend.

    Why this choice

    The ERP synchronisation runs on a cron held by the application, and a planned change needs websockets held in that same instance. Next.js's execution model assumes short-lived requests, not that kind of continuous processing. A standalone backend makes that lifecycle explicit, instead of relying on a hosting platform's constraints.

  5. 05

    One architecture across both applications

    Problem

    Two applications for one product, built by different people.

    Solution

    The same split into functional slices on both sides. On the frontend, that means pulling logic out of components into hooks and handing server state to React Query.

    Why this choice

    The business scope can be read from the folder structure, and a developer moves between the two applications without reorienting. The cost is bringing the frontend developer up to speed, on standard React practice.

04

What this project gave me

  • Technically supervising a developer on a client project, after several internal ones.
  • Reframing the delivery method: moving from the expected waterfall sequence to short incremental releases, against a poorly defined need and moving requirements.
  • Handling a blocking external dependency, the ERP team's API having arrived late and pushed the schedule back.
  • Taking over a project estimated by someone else, with the gap between the initial figure and the real need.
  • Producing architecture documentation at a level above the code.
  • Estimating new work, which means assessing what each request implies for the project as a whole.
05

In hindsight

  • Set up an initial deployment pipeline and a minimal functional slice from the start, to confront the product with its real environment early.
  • Run an interactive mockup session with a customer to capture the need before scoping, rather than from a written specification.
See other projects