Architecture before tools

A good solution may include automation. But automation is not necessarily the solution.

When I start with a tool — n8n, a framework or an AI model — I inherit its boundaries. The solution becomes shaped around what the tool offers rather than what the problem requires.

I try to follow a different sequence:

1. What is the problem?
2. What system should exist to solve it?
3. What inside that system should be automated?
4. Which tools serve that architecture?

Tools change. Principles remain. A well-designed system survives a stack change; a solution tied to one tool dies with it.