I just signed with McDonald's to build an event reservation system, with relationships between several types of people. My worry: the project will obviously grow and they'll want more activity types later. But right now they say they're not sure, so officially it's just the one. How do I handle that?

Classic client answer, and you should quietly ignore the "no." Don't build the five activities they might want one day. Build the single one they asked for, on top of a model that treats activities as data, not hardcoded logic. Two rules:

  • Design the seams, not the features. Activity types, roles, and pricing live in tables, so adding one later is a row, not a refactor.
  • Hide the flexibility. The client sees one activity and nothing else. The day they say yes, you switch it on instead of rebuilding.

That's the line between planning for growth and over-engineering: you build the structure now, the features only when they're paid for.

We're at 5 activity types now, each with its own display conditions per client. Thanks for this, I built the base to absorb whatever comes next:

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

Designing for evolution from day one is what made each of these cheap to add, without ever tipping into over-engineering.

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