People ask me what I do now, and the business-card answer is solution architect. It is a real term and it is not wrong. It names what you would hire me to do. But it is the buyer's word for the seat, not the work. The word for the work is older and plainer. Builder. I want to spend this post on what that role actually means, to me and to anyone reading this from inside our industry, because every story currently being told about it is aimed at somebody else.
First, where the word comes from, so you know I did not coin it to flatter myself.
In April 2020, Marc Andreessen published an essay at a16z called "It's Time to Build." The question it put to everyone was "What are you building?" It made building a stance rather than a job posting. Then this past May, on the a16z Show, he described something more specific: a job title actually forming inside the companies he watches. Builder. The old roles of programmer, product manager, and designer used to be three separate people negotiating with each other. AI collapsed the walls between them, and companies have started handing all three to one person who owns a complete product, end to end. His ten-year read is that the job of coder fades and an extraordinary number of builders take its place.
The tech industry hears that and pictures a coder who picked up design. I hear it and picture an operator who stopped waiting for software to fit his business.
Here is what the role means when it stands in our industry instead of theirs.
A builder sees the solution because he lived the pain point. Not gathered requirements about it. Lived it. I spent twenty-two years inside this industry's operations, and when I build for a dispatcher's morning or an estimator's bid week, I am not interviewing a user. I am remembering. That is the half of the role no bootcamp teaches, and it is the half that decides whether the tool survives contact with a real Monday.
A builder automates the workflows the business actually runs on. Every operation is unique in how it does the work, and nearly identical in what the work passes through: the approvals, the handoffs, the moment a decision leaves one person's head and has to land in another's. Those seams are where days get lost. They are also where automation pays, because a workflow built to your seams fits like your own boots, while generic software asks you to walk in someone else's.
A builder turns information into a resource instead of a filing problem. Most companies do not have an information shortage. They have information in folders, named things like FINAL-v3, that nobody opens standing on a job site. The build work is making what the company knows reachable by the people doing the work, at the moment they need it, in the language they work in. A resource a team pulls from, not a cabinet somebody maintains.
A builder converts tribal knowledge into company value. Right now the way your best foreman handles the situation nobody wrote down is an asset that walks to its truck every night, and one day it walks out for good. Captured in his own words and put where the crew can find it, that judgment stops being a risk on two legs and becomes something the company actually owns. Not a binder. A working part of the operation.
A builder treats the language and fluency gaps inside an organization as a thing to solve, not a condition to endure. Crews that work in Spanish while the office writes in English. Twenty-year veterans who will never love a keyboard, standing next to new hires who never learned a filing cabinet. Our industry has struggled on with those gaps forever, as if they were weather. They are solvable now. That sentence alone should change what an owner expects from his tools.
And here is the part that changes the economics: this work is no longer reserved for companies with an IT department and a seven-figure software budget. The corporations always could afford custom systems built around how they run. A builder brings that same fit to the five-million-dollar operation, because the tools stopped charging a computer science degree as the price of entry. Since January I have shipped eight live products across twelve production repositories, measured and dated on August 8, as one person. The walls Andreessen says are collapsing, I never had.
Two rules govern how I do it, and I would hold any builder in our industry to both.
The first: respect the speed. This industry moves at a pace that software people call chaos and we call Tuesday. A tool that asks the operation to slow down and enter data is a tool that dies in a month. The build works with the speed, not against it, which is why voice beats forms and why anything that adds a step had better remove three.
The second: solve for time first. The first layer of any build should hand the operator hours back, with onboarding so light the crew feels the benefit before they have formed an opinion about the software. Ease of use is not a feature on the list. It is the benchmark the whole build is measured against. Then, once the time is real and the operator has the capacity to engage properly, layer two builds for value: the margins, the visibility, the compounding stuff. Stacking a second tool on top of a team that has not yet felt the first one is how the industry got a decade of shelfware, and it is the mistake I refuse on every build.
That is the role. Solution architect is what it says on the card, and builder is what happens between Monday and Friday: an operator's knowledge of the work, finally holding the tools to act on it directly.
I am not telling you to become one. Discovery creates owners, prescription creates dependents, and that rule does not bend just because the discovery was mine. But if you have spent twenty years knowing exactly what your operation needs and waiting for a product company to build it, you should know the wait is over. The role has an open door on the operations side. Some owners will hire a builder. Some will become one. Either way, the fit you have been told to live without is now a build decision, not a budget line.
The title on the card can wait. The work can't.