All posts

A short list on a desk, before any code is written

What I settle before the first line of code

· Oussama Fadlaoui · consulting, architecture

A project gets expensive when the team discovers the real requirements halfway through the build. I would rather spend that time up front, on paper, with the people who will use the system.

Start from the outcome

I ask what should be true when the work is done, in a sentence a non-engineer can repeat. "Users can place an order" is a start. "A returning customer can place an order on their phone in under two minutes, and the warehouse sees it without a phone call" is a target we can design against.

From that sentence I write down:

  • Who the system is for, and who it is explicitly not for
  • The one path that has to work on day one
  • What we will not build in this version

The last list is the one that keeps the scope honest.

Name the constraints out loud

Every system I ship sits next to something that already exists: a payment provider, a spreadsheet someone trusts, a hosting budget, a legal retention rule. Those constraints decide the design more often than the framework does.

Before I pick libraries I want three answers:

  1. Where does the data live, and who is allowed to change it?
  2. What happens when a dependency is down?
  3. How will we know the important path is broken?

If we cannot answer those, we are not ready to build the feature. A throwaway prototype is enough, and I delete it afterwards.

Keep the first version boring

The first version should be the smallest thing that proves the outcome. Boring storage, a boring deployment, a single path through the product. Abstraction comes after the second real use, not before the first.

outcome → one path → constraints → smallest version

That order is the whole method. When a later change hurts, it is usually because we skipped a step and let the code invent a requirement nobody agreed to.

How I use this on client work

I bring this list to the first working session. We fill it in together, and it becomes the reference for estimates, reviews, and what "done" means. If you want to work that way on a system you are about to build, send me a message.