What a platform needs before code is written

It helps because a question answered early does not have to be answered later, by a developer, in the middle of the work. When it is written down how an invoice is cancelled or who sees a customer's file, the platform is built the way your business means it from the first time.

The difference is clear in rebuilds of old systems. The code is usually fine. What is missing is a written description of what it was meant to do. When that description exists, every discussion about a "bug" becomes simple: we check what it says and we know at once what applies.

Writing down the answers takes one or two weeks. It costs far less than a rule discovered in the fourth month, when the screens and the data already rest on a wrong assumption. This is why our process starts with a requirements stage. You approve it before the structure, the design or the build begin.

Six things get written down, and none of them needs technical language. The table shows each one, the question it answers and a short example of an answer, clear enough to build on. An answer that fits in a few plain sentences shows that everyone has understood the topic.

The last row is the most important. A requirement is worth something when it can be tested. This is why we rewrite every general wish with you, until it becomes one clear check.

They become a specification through a fixed order of five steps. Each step ends in a text you can read and approve. The build starts after you approve the fifth step. Whatever is still open at that moment is written down as open, so that you decide it and not whoever is building.

1. We talk to the people who will use it. We listen to the business owner, but also to whoever will use it every day. They know the exceptions.

2. We write the rules in plain sentences. One rule in each sentence. "A refund above a set limit needs approval" is a clear rule that can be tested.

3. We define the roles and what each one sees. A simple table of roles and actions finds most permission mistakes before they appear.

4. We record the limits and the open questions. The legal, technical and operational limits go on one page. Every question that is waiting for an answer gets an owner and a date.

5. We agree the acceptance checks. Every rule gets at least one check. You read the list and approve it.

The result is a written scope that describes your business accurately. Our own build tools also work from it. This is why the care taken at this stage shows in the rest of the project.

It means we choose the technology once we know what you need. The requirements set what the platform must do, how many people will use it and which systems it must connect to. Then we pick the tools that fit those facts. We explain in writing why we chose them, so you always have the reasoning.

A small internal tool for ten colleagues and a platform for thousands of customers from many organisations are different projects, even when the screens look alike. The first needs a simple setup that is easy to hand over. The second needs separate data for each customer, careful access rules and monitoring. When we know from the start which of the two you need, the system has exactly the size your work requires.

On the page about SaaS platforms and business applications you will find what such a project includes. The requirements stage is the clearest way to find the right solution for your case together.

The requirements that do not show on any screen deserve attention: security, accessibility, error handling, handover. Usually nobody asks for them, but they make a big difference in daily use. We go through them one by one from the start, because then they are easy to write, while in a finished product they cost more to add.

• Security. Who can log in, how passwords are stored, what happens after many failed attempts. The OWASP Application Security Verification Standard is an open standard of technical security requirements. We use it as a checklist to see which ones apply to your platform.

• Accessibility. If the platform must serve people with disabilities, this is written down now. The W3C's WCAG is the international reference, with levels A, AA and AAA. That way the goal is written as a requirement that can be tested.

• Error handling. The payment provider does not answer, a file is too large, the user closes the window halfway. For each case we agree exactly what will happen.

• Handover. How the accounts, the code and the data are handed over on the day the project is finished.

• Growth in use. No forecast is needed, only one question: if the users become ten times more, what must keep working?

More is checked than people expect. A written scope is read for contradictions. A table of roles is tried out with real scenarios. The acceptance checks become automated tests before the feature they check exists. This is the logic of "test first": the check is the specification itself, in a form that can be run.

We follow the same approach in our own work. The Planner case study shows how a written specification becomes an application, with checks at every step and in a real browser. It also shows what becomes possible when the texts are so precise that a tool can follow them.

If you already have notes, a spreadsheet or an old system, bring them. They are valuable material for the specification, even when they are not organised. You can start with a project request and tell us what you already know and what you want us to clarify together.

You decide the purpose, the rules, the data and the priorities, because they are business decisions. We suggest solutions, explain the pros and cons, and record every decision. We decide the technical approach once the requirements are approved, and we explain it in plain language.

This keeps responsibilities clear. If a rule needs to change later, there is a written record of who set it and why. The correction becomes a simple, calm conversation. If a technical choice needs to change, the same record shows which requirement it serves.