I've recently been asked to give the architecture for the second release of a project. I do not know what will be in this second release as the content of that release depends on what tools we'll choose to use.

black chicken on grass area
Photo by Guillaume de Germain / Unsplash

Seems that I have a chicken and egg situation. The UX team doesn't want to introduce a new functionality without knowing what tool will be available to use it properly and how users will be able to interact with it. But how is it possible to select a tool without knowing what it will be used for? Of course, there is a vague idea of what it would be used for. Let's say the UX asks for a catalog tool, something that can contain products, a bit like what Amazon has. With a vague requirement, it's difficult to know what the real objective is.
Since the objective is vague, why not use the most generic product tool out there? Why not use a CRM for example? That should cover most needs and if not, an extension should be feasible.

soldiers on top of battle tanks
Photo by Chuanchai Pundej / Unsplash

Such a tool could fit most needs, but the cost of such a tool is complexity. I'm thinking about installation, deployment, maintenance, onboarding for such a tool. Is it really worth it?
I'm a big fan of the Lean Methodology, which advocates starting small, and do just enough to build a solution to the project's top must-have features. Then iterate. It's very likely that needs will have evolved and that priorities will have changed by the first iteration. In comparison, a Waterfall Methodology would not have had the feedback from iterating and chances are the initial direction was wrong.


Choosing a complex one-size-fits-all tool is to be avoided. Instead, an incremental work on requirements is preferable.

NB : For some, this may be obvious, but it takes implacable arguments to make this clear.