The first thing I want you to consider about the APEX framework is all that it gives you for free.

For starters, the framework is highly instrumented via the debug log. Each time a page item has a value changed you get a message in the debug log. Each time an authorization or condition is evaluated you get a message.

Now that may not seem like a powerful message but maybe it will if you just recall all the times you needed to debug something and found yourself adding debug statements to your application.

Here's an extreme opinion to get you thinking about this:

Debug statements are a code smell

Feel free to disagree. It's just a strawman to get you thinking that maybe adding debug statements isn't the best solution.

The framework also is nicely structured for editing, discovery and reporting. If you aren't looking at the APEX Views you are missing out on a lot of the power APEX gives you for free.

Also it is easy to "play computer" in your head about the framework. One can more readily understand what will happen if they change something declarative than something in code.

Every time you go around the framework you are circumventing the natural methods. Other developers will be expecting and looking for the natural methods. You, looking back at your code in a month or two, will be expecting and looking for the natural methods.

So, be intentional about working around or against the framework.

So add those debug statements and other signposts to help others see that you have forged your own path through the garden. Add some comments to explain how it works and why it was necessary. The next time someone, even you, looks at it they might see another path.