A coworker from sales asks you if you can help her manage her list of potential clients.
You could start by designing a new kubernetes pod that includes Postgres as the database, Redis for caching, RabbitMQ for the queuing system. One container will run Node.js to serve the React user interface. For the backend, you are wondering if you should code it in .net core or use this as an opportunity to write that first Rust application. You will most likely put it in AWS, but you are open to Azure. The mobile app will be developed using Kotlin for Android and Swift for iOS.
Or you could spend 15 minutes showing her how to use Google contacts.
The first solution is complex. Complexity is expensive. It will take a long time to build. You must pay for the services. The diverse technologies take time to learn. Complexity is expensive in terms of understanding a system, fixing bugs, and maintaining it.
The second one takes 15 minutes.
The first solution makes sense in many situations. For example, if it is vital to keep the list and the privacy of its members private. Or if the plan is that a huge organization wants to have a custom, single contact system for all of their sales people. Or if the idea is that the company is planning on building a sales contact app, using their sales people as the active user base.
We don't know, though. All what we know is that your coworker wants to organize their contacts.
So far, the task hasn't earned complexity. So the task doesn't deserve it. You shouldn't give complexity to it.
Until the task deserve it
A task has earned complexity when it can show that it makes money, saves money, or no solution exists.
One should be aware when the task has earned its complexity. The company website is moving from 4 pages to becoming an active blog, which is key for getting customers. Then it may be a good idea to get a WordPress account. They want some customized widgets? We can build custom modules. The desired features and workflow for the blog are so unique that it is hard to develop? Maybe now it is a better idea to write their CMS from scratch, custom-made for the business.
Keep in mind is that if it is reasonable to add complexity from the beginning because we know that it will be needed, go ahead and do it. We don't need to spend a winter freezing at a house because we needed to freeze during a winter to learn that we needed heat. Put heat from the start. Same with tech. If you gather relational data, use that database from the start.
For those paying attention, this is a different way to express YAGNI. Perhaps a meaner, more Scroogey way of saying it. Should we add Redis because it is cool? You ain't gonna need it. But also, you still don't deserve it.