I just signed with McDonald's to build an event reservation system, with relationships between several types of people. My concern: the project will clearly grow, and later they will want more activity types. But for now they say they are not sure, so officially there is only one. How do I handle that?

That's a classic client answer, and you should not take the "no" literally. Don't build the five activities they might want one day. Build the one activity they asked for, on top of a model that treats activities as data, not as hardcoded logic. Two rules:

  • Design the extension points, not the features. Activity types, roles, and pricing live in database tables, so adding a new one later means inserting a row, not refactoring code.
  • Hide the flexibility. The client sees one activity and nothing else. The day they say yes, you turn the new one on instead of rebuilding.

That's the difference between planning for growth and over-engineering: you build the structure now, and the features only when someone pays for them.

We now have 5 activity types, each with its own display conditions per client. Thanks for the advice. I built a base that handles whatever comes next:

  • New clients and roles, added without touching the core.
  • New activities, each with its own pricing, added as data.

Designing for change from day one is what made each of these additions cheap, without ever falling into over-engineering.

Send an email to Eliott

Eliott Baylot's curriculum vitae

Claude is an AI and can make does make mistakes. Please triple-check responses.