Initiative 03 — Platform practice: from websites to systems

01Why a website and a platform are different jobs

A website answers a question a visitor asks. A platform holds state that several people change at once, and every change has a consequence somewhere else. Once roles, permissions and integrations enter the picture, the cost of a wrong decision moves from the design phase to the database — and that is the expensive place to be wrong.

Most failed internal tools were not badly built. They were built from a description that nobody tested against real work.

02What the practice will offer

A short, serious discovery stage that ends in something a team can react to, rather than a proposal document nobody reads.

1. Workflow research — sitting with the people who do the work and writing down what actually happens, not what the process diagram claims.
2. Data and role model — entities, ownership, permissions, and the audit trail a business will need later.
3. Integration map — every external system named, with a decision on who owns each record.
4. Clickable prototype — the three screens that carry the whole product, built to be clicked, not admired.
5. Build specification — scope, phasing and risk, ready to be quoted honestly.

03How discovery will run

Four weeks, four outputs, one rule: every stage ends with something written down that the next stage depends on.

1. Week 1

   Map

   Interviews and observation. Output: a workflow map with the exceptions written in.

2. Week 2

   Model

   Entities, roles and permissions. Output: a data model the client's own team can correct.

3. Week 3

   Prototype

   The critical three screens, built and clicked with real data shapes.

4. Week 4

   Specify

   Phasing, integration plan, risks and a build estimate grounded in the prototype.

04Our architecture stance

Boring where it counts. The stack is chosen for the team that will maintain the system, not for the demo.

1. Typed end to end, so a change in one place fails loudly instead of silently.
2. A real database with a real schema, before anyone reaches for a clever cache.
3. Roles enforced at the data layer, never only in the interface.
4. Integrations behind a boundary, so a vendor can be replaced without surgery.
5. Background jobs for anything a user should not wait on.

05How this shows up in the portfolio

The five platform studies on our portfolio page — logistics, procurement, scheduling and the rest — are the thinking this practice will apply. They are labelled as concept studies because they are exactly that: our approach made visible, not a record of deliveries. As real client work is approved for publication, approved case studies will replace concept studies on that page.

06Who should start here

A platform engagement begins with a problem that costs money weekly: scheduling conflicts, purchase approvals stuck in email, a spreadsheet that three departments cannot agree on. If that is your week, write to Code@codexon.eu with the sentence you would use to complain about it to a colleague. That sentence is a better brief than a specification.