I did not begin in systems architecture. I began in graphic design, taking whatever work came, learning the business by being close to clients who needed something and could not describe it precisely.
Design taught the part of the job that engineering training often skips: that a deliverable is only good if it solves the problem the client actually has, which is rarely the problem they first stated. Getting to the real requirement — through questions, sketches, and being wrong a few times cheaply — is the same skill whether the output is a logo or a data model.
The transition happened gradually and for unglamorous reasons. Clients kept asking for things that could not be solved with a design file. They needed a booking flow, then a way to track inventory, then to know why two reports disagreed. Each answer required going one layer deeper, until the work was no longer decoration on a system but the system itself.
What changed most was the time horizon. A design is judged when it ships. A system is judged for years, by people who were not in the original conversation, under conditions nobody anticipated. That shifts the priorities: naming things clearly, keeping modules genuinely separable, writing down why a decision was made rather than only what was decided. Work that looks like overhead on day one is what makes month thirty tractable.
The freelance years turned out to be the useful preparation, not the detour. Doing everything yourself — the pitch, the scope, the build, the invoice, the awkward conversation when something slipped — teaches where projects actually break. It is rarely the code. It is the gap between what was promised, what was understood and what was needed.