I’ve seen countless vendor pitches as mayor. Booths at conferences, department heads walking a proposal into my office, cold emails that somehow made it past my assistant. Almost every one of them had a genuinely good product.
I still said most of them ended in “No.”
For years I assumed those founders walked away thinking I/we were slow, or risk averse, or that I just didn't get it. Some of them said so. What none of them understood is that I (and you) were running a calculation nobody in that room ever said out loud, including me.
If you sit in an executive seat in local government, you run that same calculation. You probably have never written it down. I want to write mine down here, because once it is on paper it stops being instinct and starts being a tool you can hand to your staff, your council, and the next vendor who walks in.
Why we are so slow to say yes
Consider a normal decision. Moving from individual Microsoft licenses to Microsoft 365 is about as close to a non-decision as you will ever see. Nobody on staff, nobody on the council, nobody in the community believes that switch damages anything.
Now consider a pitch to that same community to move from Microsoft Office to Google Docs.
Same category. Word processing is word processing. But that second pitch is not a software decision anymore. It touches how councilmembers work, how staff share files, how a decade of institutional habit gets relearned. If it goes sideways it can stall the organization for months over a function nobody outside government would consider a big deal.
Same product category. Wildly different risk.
I lived a much bigger version of this. Probably the largest software win of my time in office was getting the city onto an online utility bill payment system. If you asked me what the hardest part was, you would guess wrong.
It was not vendor selection. It was not the interface, or which bank handled the transactions, or anything a founder would put in a deck.
You are not buying a feature. You are buying risk.
The single biggest debate of the entire project was whether, and how much, to charge residents a convenience fee to pay online. The question that nearly killed it: is it a gifting of public funds to absorb a transaction fee on someone's behalf without a legal basis for doing it?
We spent more time on that question than on every feature of the product combined.
That is the pattern, and it is worth saying plainly because it will save you months. The debate is almost never about the feature. It is about an unglamorous risk or legal question that no vendor raised, that was not in the problem statement, and that was never on the decision matrix.
The vendor is selling capability. You are buying exposure. Until both sides say that out loud, you are negotiating in two different currencies.
More capability usually means more risk
A founder walks in ready to talk about what the product does. More automation, more integrations, more dashboards, more of everything the last vendor lacked. In the private sector that arithmetic works, because more capability means higher productivity or lower cost, which means more value.
In our world, more capability usually means more surface area. More places it can break, more departments that have to relearn something, more ways a records request can reach into it.
You are not pricing value in features gained. You are pricing it in problems avoided.
When a vendor says "I can save you thirty percent of your staff's time," the question you are actually asking yourself is different. When this goes wrong, how fast can I get back to my real priorities, and does this lower my risk or raise it?
That is not obstruction. That is the job.
The asymmetry nobody warns you about
I have written before that the public executive is the de facto Chief Risk Officer. That posture is not a personality trait. It arrives with the office, and even executives who cannot yet articulate it revert to it, because the statutes, the procedures, and the public record all pull in that direction.
Here is the part worth naming, because it explains a lot of behavior in your own organization.
In the private sector, the person who champions a bold new tool that pays off gets a bonus, a promotion, a case study with their name on it. In government, that same person gets a quiet thank you if they are lucky. Nobody writes an article about the permit system that worked fine. But if it breaks, that person gets a council meeting, a reporter's phone call, and their name attached to the failure for years.
Nobody remembers that they tried to do the right thing. The sentiment becomes that they did the wrong thing.
Think of it like holding an options position. Unless you have nerves of steel and an appetite for personal risk, you do not hold a position with unlimited downside. You hedge. Our seat carries exactly that exposure: the upside is capped and shared, the downside is uncapped and personal.
So we trade away the moonshot to cap the loss and settle for a high likelihood of a modest gain.
That is rational. It is also worth knowing about yourself, because it means the person on your staff who keeps killing good ideas may not be obstructing you. They may be protecting themselves, and nobody has ever told them the organization would carry that risk with them.
The demo tells you nothing about the pothole
This newsletter exists to explore the gap between the potholes and the pixels. The real problems on the ground versus the clean checkmarks that tell everyone it is handled.
A great demo is a pixel. Polished, finished, and silent on the only question that matters: what happens eighteen months from now, after every department has touched the tool and something finally breaks in a way the demo never showed you.
The better the demo looks, the less it tells you about that pothole, and the more work you have to do to go find it yourself before you can say yes.
And the cost of getting it wrong is not contained to one purchase. If you champion a new website platform and the migration is rocky, confusing residents and burying half the permit forms for two months, then the next time your team brings forward a utility rate system or a permitting tool, that ask carries the weight of the last failure before anyone hears a word of the new pitch.
Council remembers. Staff remembers. The public remembers.
A vendor thinks they are asking you for one yes. You are deciding how much institutional trust to spend on an entire category, for years.
Why the ugliest system in the building survives
This is why dated systems in government outlive everyone who complained about them, and it is not because nobody noticed.
Look at a city’s municipal code library. I bet you the base code on file still shows something in the 90’s as its foundation year, patched forward through three decades of amendments, the most recent from an ordinance passed this past May. It is not the best tool available. It is not close. But it has never caused a bad headline, and it has been quietly fine for so long that replacing it now reads as a risk nobody asked anyone to take.
I lived a smaller version myself. Our city had a bespoke WordPress site that, in practice, one staff member truly understood. When that person left, or even took a vacation, we had no backup and nothing to fall back on. So we moved to a cookie cutter platform from an established vendor.
I cannot tell you it was a better website. Honestly it may not have been. What it was, was safe. The ceiling was lower. Nothing about it was going to impress anyone, but the floor could not turn into a disaster either.
We traded a shot at something great for a guarantee against something bad. I would make that trade again, and I would also want to know I was making it on purpose rather than by default.
Your best reference is not a reference. It is a twin.
The single strongest signal I ever responded to was not a client list. It was seeing a genuinely comparable community already using the product and doing fine with it.
Comparable means more than population. Size matters, but so do temperament, politics, and the general shape of the place.
A booming, well funded suburb succeeding with a product tells a small, cash strapped rural city almost nothing, because their risk tolerance is not remotely the same. A community with a fractious, closely divided council should discount a case study from a city with a unified, low drama council, because their rollout would face pressure that reference never had to survive.
Which means the biggest logo in a vendor's deck is often the least useful thing in it. A major city has an IT department, a bigger budget, and room to absorb a rough rollout. That logo tells you a story about someone else's resources, not your own exposure.
So ask for the twin. A community at your scale, with your council dynamics, your thin staff, your tight budget. If the vendor cannot produce one, that is information, and it is information you got for free.
Use your risk pool before you commit, not after
Here is the move I wish I had made earlier and more often, and I will die on this hill.
Most cities and counties carry liability through an insurance pool or a risk sharing trust. In my state that is pools like the Washington Cities Insurance Authority or the AWC Risk Management Service Agency, and most regions have an equivalent. Those pools employ risk managers who read vendor contracts for a living, and they read for specific things: indemnification and hold harmless language, insurance minimums, cyber and data breach liability, and what happens to public records sitting in a vendor's custody.
That expertise is already paid for. It is sitting in a building you fund.
Most of us call the pool after something has gone wrong. Send them the contract while you still have leverage, before you are emotionally committed and before a department head has told their team it is happening. A clause your pool will reject is a lot cheaper to find in July than in a claim.
That gifting of public funds fight I mentioned was not a legal curiosity. It was systemic anxiety about uncapped liability, surfacing as a technical objection. If we had put the question to the right people earlier, we would have spent weeks on it instead of months.
Six questions to ask before you say yes
None of this means you should be slower. It means the caution you already feel deserves better instruments than instinct. These are the six questions I suggest asking, out loud, in the first real conversation.
What is the smallest version of this you can sell me? Not the best version. The smallest one, sized so a miss costs a week of somebody's time rather than a headline. A vendor who only has a nine department launch is telling you something.
What is the worst plausible failure, and what does it cost me six months from now in front of my council? Watch whether they flinch. A vendor who has run a pre mortem on their own product answers this without blinking. One who has not will try to reassure you, which is not an answer.
Who is my twin already using this? Not the biggest client. A community that looks like mine. Then call that community's manager directly, without the vendor on the line.
What happens to our data, and who else can see it? A marketing sentence instead of a specific answer is your answer.
What is your rollback plan if this breaks in month one? If they have a real one, they have already done your risk math for you. If they do not, you will be doing it alone at the worst possible moment.
Where does our current system fail us so bad we’d be willing to risk an alternative solution? Ask this one of yourself, not the vendor. If you cannot answer it, you do not yet know what you are risking, and you are not ready to decide.
Get honest answers to the first five and a clear answer to the sixth, and you have done in one conversation what usually takes three procurement cycles and a bad experience.
Size it out loud, early, with the people who will carry it. You will say yes more often, and you will be right more often when you do.
If this is the kind of decision you are working through right now, two things.
I am running "The AI Policy Every Local Gov Needs Before It's a Headline" live and free on September 3. It applies this same posture to the AI tools your staff are already using, and you leave with a policy skeleton you can hand to your attorney or your council rather than a list of things to worry about.
Details at maven.com/joshuapenner.
And if your jurisdiction is weighing a specific decision, a vendor, a policy, or an adoption question you would rather not learn about the hard way, reply to this email. I do advisory work with cities and counties on exactly this, and I would rather have the conversation before the contract than after the claim.
