All work

A client area: purchases, shipments, payments and documents in one place

One client area instead of emailing managers: see where the parcel is, pay, download a document. The same code serves two different services — the differences live in configuration.

Context

The company’s clients needed one place instead of a thread with a manager: see where the parcel is, pay, download a document. All three public websites from the TRT ecosystem case lead the user here.

Solution

The client area and the accounting system speak the same language by construction: the data description for the client area is generated from the system’s own description, so the two cannot drift apart.

Documents and cargo photos are kept in secure storage; links to them are temporary and issued only to whoever is entitled to them.

Scale — 637 source files.

How it is built

One client-area codebase serves two services; the differences live in the management system settingsClient area, shipping serviceown branding · own set of sectionsClient area, forwarding servicesame code · different settingsA third serviceadded by configuration, no code changesOne client-area codebaseon start it fetches its settings and assembles itself for the service: sections, fields, brandingManagement systemservice settings · data description, from which the client-area types are generatedFile storagedocuments and cargo photos · temporary linksOne client-area codebase serves two services; the differences live in the management system settingsClient area, shipping serviceown branding · own set of sectionsClient area, forwarding servicesame code · different settingsA third serviceadded by configuration, no code changesOne client-area codebaseon start it fetches its settings andassembles itself for the service:sections, fields, brandingManagement systemservice settingsdata description, from which theclient-area types are generatedFile storagedocuments and cargo photostemporary links

Why this way — one client area for two services

When the company needed a second client area for another service, the obvious path was to copy the first one and adapt it. Six months later that is two diverging projects where every change has to be made twice, and one of the copies is always behind.

We went the other way: the code stayed single, and the differences between the services moved into configuration that the client area requests from the system at startup. The application learns which service it currently is and assembles itself accordingly.

What it gave: a third client area is added with no code changes at all, only configuration on the system side. A bug fix arrives in every service at once.

What it cost: configuration becomes part of the contract between the client area and the system, and it has to be validated and versioned as strictly as everything else. And every new setting demands an answer to one question — is this really a difference between services, or am I hiding in configuration something that should be code?

The fourth use of one method

The page builder, the platform for industry applications, the processes in the accounting system and this client area — configuration instead of copying, every time. That is not a coincidence, it is how I work.

Other case studies

Case studies and personal projects