Custom platform development

Most platforms are not hard because of their features. They are hard because of what happens between them: the order that is paid but not yet fulfilled, the import that failed halfway through, the two users editing the same record a second apart. Those states exist whether or not the system models them, and the ones a system does not model are the ones support ends up fixing by hand.

Custom development starts there. Before any screen is designed, the work is to name the entities, the transitions between their states and the guarantees each operation has to keep when something fails midway. Once that is settled, the interface is the easy part, and it can change without putting the data at risk.

Business rules are resolved on the server, in one place. A rule enforced only in the browser is a suggestion: it disappears the moment someone calls the API directly, and it drifts the moment a second client is built against the same backend. The same applies to authorisation, which belongs where the data is read and written, not where the button is drawn.

This is the discipline behind platforms serving 24 million users a year and internal tools used by a 30,000-employee company. That work is covered by non-disclosure agreements and is described without client names, but the engineering is the same one applied here, scaled to what a given project actually needs rather than to what sounds impressive in a proposal.

One detail decides more than it looks: roles and permissions are enforced on the server, never by hiding buttons in the interface. A hidden screen is a suggestion; a rule checked before the data is touched is a guarantee. The same applies to anything involving money, where the operation has to be idempotent - the same payment processed five times must leave the system exactly as it was after processing it once.