Your brochure site can become your management tool

A sports association ran its administration the way many small organizations do: spreadsheets, notebooks, and the memory of whoever handles it. Its website, meanwhile, displayed the timetable and the prices, with a contact form.

That same site now handles registrations, subscriptions, absences and the monthly accounting return. Not a second tool bought alongside it: the site itself became the management software.

Here's what makes that shift possible — and why, most of the time, it isn't.

Why it almost always ends in a rewrite

The usual story is familiar. The brochure site works perfectly well for what it does. You add a registration form, then an attendance table, then payment tracking. Each addition is reasonable on its own. And one day the verdict lands: "we really ought to rebuild this properly."

The cause isn't a lack of skill in whoever built the site. It's structural: a brochure site and a management tool don't rest on the same foundations, and you can't slide the latter under a building that's already occupied without emptying it first.

Hence the one rule that matters here, which sums up the whole article:

Foundations before features. Not the other way round, and not "we'll sort it out later".

First, don't throw away what exists

Step one, before anything new: rebuild the site on a solid base without changing a single thing about how it looks.

The old site was kept as an untouchable reference. The new one was rebuilt behind it — a different engine, content fully editable from a text editor — under one strict constraint: the appearance must stay identical, pixel for pixel. That isn't a promise, it's a check: the old site's screens were captured, and the two versions are compared automatically on every change. A visual difference fails the check.

For the client, the translation is simple: your site doesn't move while the engine underneath is replaced. Your visitors see nothing. You lose neither your search ranking, nor your habits, nor the design sign-off you had already given.

It's the kind of requirement that sounds pedantic right up until a rebuild costs you three months re-validating mock-ups everyone had already approved.

The three foundations, and why they come first

Once the base was sound, three things were put in place before any management feature at all. None of the three is visible on screen. All three decide what becomes possible afterwards.

Multi-organization. One studio's site became a platform able to host several: each with its own contact details, logo, color, domain and its own publishing. Why first? Because converting a single-organization application into a platform after the fact touches nearly every database query. Done at the start it's a design decision; done afterwards it's the rewrite you were trying to avoid.

The interface contract. What the server exposes is written down explicitly, and that contract is verified automatically. The concrete consequence: the visible side and the engine evolve separately without breaking each other, and the day another tool needs to plug in — accounting, ticketing — there's something to plug into.

Isolation. A test verifies that one organization never sees another's data. That's the kind of guarantee you don't bolt on later: either it's verified from day one on every change, or you simply don't know. For members' personal data, that difference isn't theoretical.

Those three arrived together, in a first pass that ships no visible feature. It's counter-intuitive to explain — you pay for a stage the client sees nothing of — but it's exactly what avoids the far heavier bill afterwards.

What "management" actually covers

What follows is taking over, one at a time, the things the association used to do by hand:

• registrations, approved manually, with their successive statuses;
• subscriptions and session quotas;
• pauses, and freezing subscriptions while the organization is closed;
• absences, and what follows from them;
• payments, with no card terminal;
• spreadsheet exports;
• the monthly accounting return.

Each of these is one spreadsheet, notebook or mental note that disappears. And each one is one fewer opportunity to get something wrong.

It's also where the value of having laid the foundations shows: these features are added one after another without touching what already exists. They don't have to renegotiate the architecture — it's already there.

The decisions stay yours

The point that matters to someone running an organization, and that gets glossed over whenever tools are discussed: who decides.

A rule such as "a subscription taken out after a closure is announced is not frozen" isn't a technical question. It's a management decision, with consequences for money and for the relationship with members. It gets decided by the person accountable, then written down, then implemented. In that order.

That's what separates a bespoke tool from off-the-shelf software: your rules aren't the ones a vendor picked for you. But they do have to be written down somewhere rather than living in the head of whoever applies them — and moving to software is precisely what forces that.

How quality is held

The project's design was reviewed by someone independent of whoever designed it, with a real right of refusal. On the first pass it was rejected: one management rule hadn't been carried through everywhere it applied. It passed after correction.

That's worth saying, because it's the kind of detail nobody ever puts forward: the design was refused once before it was accepted. A reviewer who approves everything first time isn't reviewing.

Then, during the build, each item is developed in its own copy of the project, and its integration is conditional on a battery of automated checks: the tests, adherence to the interface contract, isolation between organizations, screen comparison. A red check blocks integration. No judgement calls, no "it's a detail, we'll fix it later".

Finally, each stage ends with a public showcase: the real journey, filmed in a real browser, not a narrated demo in a meeting. Two of those films are online — the manager editing her own site, and booking sessions end to end.

The day-to-day, in one screenshot

Here is my screen during the build. It's the part nobody ever shows, and yet it's the part that decides whether a project like this is sustainable or not.

Three things can be read from it (click to enlarge; the screen is in French).

A backlog cut so it runs without being re-explained

On the right, three streams are progressing at the same time, each in its own copy of the project. That parallelism isn't a feat of tooling: it follows directly from how the work was cut up.

For a backlog item to go off without hand-holding, it has to carry everything needed to execute it and then judge it:

• an identifier and a scope — what's in, what isn't;
• the checks that accept or reject it, decided up front rather than negotiated on delivery;
• its dependencies, written down. That's the point the screenshot illustrates best: one of the streams started later than the other two, because it builds on the base layer and had to wait for it. That isn't a delay, it's a dependency being honored.

This is what's meant by a backlog ready for agents to execute. The difference from a wish list is total: a wish list doesn't parallelize, because every line needs a human to come and re-explain what it means. A backlog cut this way does — and that's where the time is won, not in the typing of code.

In the middle of the screen, the project ledger acts as the source of truth: every stage, every integration, every decision is recorded there. Anyone — another contributor, or me after an interruption — can pick up where things stand without someone having to recount the history from memory.

What I actually do with my day

On the left, the question I asked: "why am I seeing three streams and not four?"

That's a manager's question, not a developer's. And the answer comes back at the right level: the first pass builds only the three foundation pieces — the base layer, the data schema, the interface contract — and the registrations stream has nothing to do until they exist; it starts on the next pass, in line with the plan I had signed off.

Note the shape of that exchange, because it's the heart of the matter: I ask a question in plain language, I get an answer that can be checked against the plan I signed, and I didn't have to read a line of code. That's exactly what makes the decision-maker's role sustainable on a technical project — and what's missing when the answer you get is "it's complicated to explain".

So my day looks like this: I read where things stand, I answer the questions that need a business call, I check the report before authorizing an integration, and I sign off the stages. The decisions stay where they belong. What changes is that I spend my time deciding rather than waiting.

The red failure isn't an incident

One of the checks has just gone down, and it says so plainly on screen.

Nothing integrates until it's back to green: the stream fixes and re-runs, and the report is read before any merge. A dashboard that's permanently all green would prove nothing — except that the checks aren't looking very hard. Seeing a red is seeing the mechanism work: I wrote about that regarding another project where twenty-two errors were introduced deliberately to verify every check knew how to say no.

What this changes for you

If you have a brochure site and your administration lives in spreadsheets, the question isn't "do we need software?" but "what will it rest on?".

Three questions are enough to judge a proposal:

• Does my site change how it looks during the operation — and how do you verify that?
• Is what determines everything afterwards (several organizations, an interface contract, data isolation) in place before the features, or promised for later?
• Have the checks that authorize a release ever actually blocked anything?

The limits, stated plainly

Two things I won't dress up.

This project's code isn't public. It's a client management tool holding members' data: it's the only project I write about here without being able to point you at the repository. What is public is the method framing it, and the filmed journeys of the stages already delivered. If that verifiability matters to you, say so at the outset: it's decided when the work is scoped, not at the end.

Foundations are paid for before they're useful. The first pass ships nothing visible. That's uncomfortable to sell and uncomfortable to buy. The only honest approach is to say so at quotation time rather than discovering it together.

And the human share doesn't shrink. Migrating the real content, checking with the people who will actually use the tool, switching over without losing the history: that work is what sizes the project, and it's yours as much as mine.

If you'd like to look at what this would mean in your organization, let's talk. The method and its safeguards are documented publicly: gilmry.github.io/foyer.