Customization vs Configuration
One of the great things about CiviCRM is the possibility of tweaking it to match your organization's needs exactly. The possibilities are nearly limitless.
But what does that "tweaking" really look like?
How easy is it to do, and how easy is it to maintain?
Broadly speaking we can divide this into two types of modifications, which I'll call...
Configuration: Using in-application point-and-click workflows (or, changes to settings files like CiviCRM settings.php) to get a desired outcome.
Customization: Creating or modifying computer code (such as PHP and JavaScript files) to add or alter functionality.
Put another way:
Configuration is stuff your non-programmer staff can do, while customization needs software development skills.
CiviCRM, like any other open-source software package, can be customized in literally any way you can imagine — as long as:
It's logically sound (i.e. it can be explained in plain English with a set of rules that don't contradict each other), and
You have access to (and a budget for) the programming skills to do it.
And one more thing: If you're customizing the software, you're on the hook for keeping those customizations working properly into the future.
In other words:
When you upgrade CiviCRM, who will make sure your customizations continue working properly? Nobody but you (and whomever you can get to help you).
Here's the thing:
When you get an idea to make your CRM behave differently, customization (through software programming) is definitely an option.
But if you don't have a business case that justifies ongoing bug-fix support for those customizations, you're probably better off sticking with whatever changes you can achieve through configuration.
All the best,
A.