Software Architect
The person responsible for the system-level shape of the software: the big structural decisions that are expensive to reverse and the non-functional requirements nobody else owns.
A Software Architect owns the decisions that are hard to undo. How the system is split into services or modules, how data flows through it, where the boundaries sit, which technologies the stack commits to, and how the whole thing holds up under load, failure, and growth. Individual features are cheap to change. These structural choices are not, which is why they need someone thinking at the system level rather than the feature level.
The real value is in the non-functional requirements: performance, scalability, security, reliability, maintainability. These are the things no single feature ticket owns and that quietly sink a product when ignored. The architect’s job is to name the trade-offs out loud. Faster to build now versus cheaper to change later. Simple and limited versus flexible and complex. There is no free architecture, only trade-offs you chose on purpose or trade-offs you inherited by accident.
Most startups do not need a dedicated Software Architect, and hiring one early is usually a mistake. At small scale the architecture is small, and the tech lead or CTO carries it as part of their job. A full-time architect with no code to write and no team to lead tends to produce diagrams and standards documents that the team then ignores. The role earns its keep once the system is large enough that nobody holds the whole picture in their head.
Worked example of why the no-code architect drifts wrong: an architect who left the codebase two years ago designs a “clean” event-driven system with six queues and three databases, because on a whiteboard that decouples everything nicely. The team that has to build it discovers the local development setup now takes a day to stand up, every feature touches four services, and debugging a single user complaint means correlating logs across all of them. The diagram was elegant; the lived experience is misery. An architect still close to the code would have felt that cost coming, because they would have been the one running the six queues on their laptop.
The honest take: “Solutions Architect” on a vendor’s org chart often means a pre-sales role that designs systems they will never have to maintain. A good architect stays close enough to the code to feel the consequences of their own decisions. If the person drawing the boxes never has to live inside them, the boxes will be wrong.