The Person Who Feels the Pain Can't Sign the Check
Solar drafting automation has a split buyer: the engineer who redraws strings every day, and a decision-maker who hasn't opened AutoCAD in years. How each side gets the other to yes.
The Person Who Feels the Pain Can't Sign the Check
Every software vendor eventually learns that the user and the buyer are different people. In solar engineering the split is unusually wide, and it kills good purchases in both directions: teams that should automate don't, and occasionally teams buy tools their engineers never open.
The user is a solar engineer who strings panels in AutoCAD every working day. They are CAD-savvy — many have written their own LISP routines or tried scripting their way out of the tedium — and they feel the repetition physically. Imagine waking up and drawing the same polylines, on the same layers, project after project. That's the pain.
The buyer is usually a principal, an engineering manager, or an owner who hasn't drafted in years, sometimes since drafting meant pencils. They don't feel the repetition. What they feel is risk: engineering mistakes are expensive, "automation" plus "AI" sounds like a lawsuit with better marketing, and a low-cost employee doing the work by hand at least does it exactly the way the firm wants.
Neither of them is wrong. That's what makes the sale — and the purchase — hard.
What the engineer should bring upstairs
If you're the engineer, your frustration is real but it is not an argument. Your boss has heard frustrated engineers before, and knows frustration passes. Bring numbers and boundaries instead:
Hours, on your own projects. Not the vendor's claim — your log. Track a month of projects and split each one into engineering decisions and mechanical drafting. When the drafting share lands somewhere near two-thirds of your time, that figure carries more weight than any demo. We wrote up why that ratio traps EPC economics in the part of solar engineering that doesn't scale.
The boundary the tool respects. The single fact most likely to move a risk-averse buyer is what the tool does not do. A drafting tool that produces strings, homeruns, and tags — and leaves conduit, OCPD, SLD content, and the stamp with the engineer — is not the liability they're imagining. If the tool shows the arithmetic behind each output, say so, because "I can check every number it draws" answers the exact fear they won't say out loud.
A trial on a real project. Not a sandbox. One live project, drafted both ways, timed. Fourteen days is enough to produce that comparison.
What the buyer should ask back
If you're the one signing, your engineer's enthusiasm is data too — internal advocates are how tools actually get adopted — but ask the questions your position obligates you to ask:
- Does it make engineering decisions, or drafting objects? If a vendor can't draw that line crisply, walk.
- Where does review happen? Automated output that can't be inspected line-by-line doesn't belong in a stamped set.
- What does it cost when we're busy and when we're not? Per-design credits and project caps punish exactly the growth you're hoping for. Flat per-user pricing keeps the math boring.
- What happens to the drawings if we cancel? The work should live in your DWG files, not in a vendor's cloud.
The needle both sides are threading
The engineer wants their evenings back. The buyer wants to never explain to a client why an automated tool drew a violating string. A drafting tool earns both only by being narrow: automate the mechanical work completely, touch the judgment not at all, and show the arithmetic in between.
That narrowness is the whole design brief behind Branch. But the argument above is vendor-neutral — it's how any drafting automation should be bought, including by people who never become our customers.
The trial that settles the argument is 14 days on your own projects. The boundary — what gets automated and what stays yours — is documented in what Branch does and doesn't do.