How to Build a Web Platform: The 4 Stages, in the Right Order

A real platform is built in four stages, in this order: requirements, data model, secure backend, and interface. Typing code is mostly the fourth stage.

Skipping a stage doesn't save time. The problem comes back later in its most expensive form, usually as a rewrite.

This guide explains each stage in plain words, what goes wrong in each, and what changes when you build for an Algerian business.

What are the 4 stages of building a web platform?

Think of building a house. First you decide what rooms you need. Then you pour the foundations.

Then you put in the walls, wiring and locks. Only then do you paint and furnish. Nobody paints before the foundations are dry.

Projects rarely die from bad code. They die from a data model that can't represent the business, a feature list nobody cut, or an owner who can't run the platform alone.

How should you write requirements for a platform?

The goal of requirements is not to write down everything the client wants. It is to find the few features that carry the business, and cut the rest.

A first meeting often produces a long wish list, sometimes dozens of features. Usually only a handful matter on launch day.

Building everything does not give the client a richer product. It gives them a product that ships much later and hides the important features under menus.

The useful question is not "do you want this?", because the answer is always yes. It is "if this did not exist on launch day, what would break?" Most features survive that question badly, and that is the point.

Why is the data model the most important stage?

Because code is cheap to change, and a database full of real customer data is not. Changing it means migrating data and updating every app that reads it.

The same mistakes come back again and again:

• Storing the current state instead of what happened. History is destroyed.
• Storing money as decimal numbers. Rounding errors creep in. Use whole numbers in centimes.
• Missing the relationship the business really runs on. It gets faked later with messy workarounds.
• Optimising early for a speed problem you don't have.

Six months later, the symptom is always the same: simple questions from the owner become slow or impossible to answer.

What does a secure backend need?

The backend is the part of the platform that runs on the server, out of sight. One rule matters above all: the server decides, never the browser. Anything the browser sends, someone can fake. If a browser can tell your server which price to charge, you don't have a backend, you have a suggestion box.

In practice:

• Use row level security. It is a database feature that decides which rows each user can see or change, so a leaked key still can't read another seller's orders (PostgreSQL documentation).
• Keep risky operations in one step. Reducing stock and creating the order happen together, in one database transaction, so two buyers can't both get the last item.
• Never let anyone edit money records. Corrections are new entries. I explain why in never edit a money record.

Why does every platform need an admin panel?

Because a platform has two audiences, and the second one gets forgotten. Customers need the store. The owner needs a back office to do their own job without calling you.

That means changing a price, refunding an order, suspending a user, reading yesterday's numbers.

An admin panel is not a nice extra. It is the difference between a platform the client owns and one they rent from your phone number.

When is a template enough, and when do you need custom?

The honest version: for a small shop selling a few items, a good template is the right answer, and I tell clients so. Custom work pays off when the workflow is the business, as it is for cash on delivery, couriers and many sellers. I explain this choice in custom software vs off the shelf.

What changes when you build a platform for Algeria?

Requirements. Clients often ask for the features of a company far bigger than theirs, because that's what they've seen. The job is not to say no, but to sequence: ship the features that bring revenue first. An owner who has been burned before won't believe a twelve month plan, but will believe a working checkout in a few weeks.

Data model. An Algerian order is a series of events over days: placed, confirmed by phone, sent to a courier, out for delivery, failed attempt, second attempt, delivered, cash collected, paid out by the courier at the end of the week minus a fee.

Store it as one row with a status you keep overwriting, and you can't check the courier's weekly payout. Wilaya and commune belong in real reference tables, not free text, because delivery pricing depends on them.

Backend. Most payments are cash collected at the door by someone who doesn't work for you. The hard part is matching expected collections against what the courier actually pays out. Chargily is worth adding for online payment, but making prepayment the main path builds for a customer who isn't there yet.

Interface. The seller uses a mid range Android, in Arabic, right to left, on a connection that drops. Test on a real device. And the admin panel matters even more here, because the alternative is a client calling you at 9pm to change a price.

What mistakes do platform projects make?

1. Building every requested feature. Cut to what breaks the business if missing.
2. Writing code before drawing the data model.
3. Trusting the browser with prices or permissions.
4. Leaving the admin panel for "later".
5. Testing only on a laptop, when users are on mid range phones.

What should you do this week?

• Today: write your feature list, then mark only what breaks launch day if missing.
• This week: draw your data model: the main things you store and how they link.
• This week: for each table, decide: is this a fact about the past, or a current state?
• Before building screens: list what the owner must do alone every day in the admin panel.
• At every stage: show the client a working piece, explained in plain sentences.

If you are early and worried about budget, read why expensive apps die before launch.