A major American city issued an RFP for a new government website and content management system. The project was worth roughly $180,000 and drew a crowded field of qualified firms — but the city had made one thing explicit: it did not want the type of solution we sold. The RFP required a custom-built Drupal system, and the reasoning seemed straightforward enough. The city wanted control. They wanted their internal team to maintain and modify the site after launch without depending on a proprietary vendor.

Leadership reviewed the requirement and concluded we should walk away. I wanted to know why the requirement existed in the first place.

That’s usually my first move when a solution runs into friction: not to push harder, but to trace the friction back to its source. Who created this constraint, and why? What information shaped the decision, and does that reasoning still hold up? I’ve noticed that when you ask people a real risk question and get an assumption in return — “I’m not planning to leave anytime soon,” or “we don’t really change requirements much” — it’s usually worth paying attention. Those answers sound reassuring, but they don’t actually reduce any risk. They just depend on the present continuing to behave exactly as expected, and the present rarely cooperates with that plan for long.

My skepticism about custom code started as something fairly abstract. I’d trained as a software developer, and I knew firsthand how difficult it is to inherit someone else’s code, understand it, and stay responsible for it years down the line. That abstract concern became more concrete the more I talked to municipal teams and heard the same pattern: the person who understood the system wasn’t planning to leave, the organization didn’t make major changes, and the system worked fine right now. None of that was necessarily false. It just didn’t answer the question.

The city believed a custom-built system would give it control, while buying a proprietary product would create dependence on an outside vendor. I thought that framing left something out. An organization can own every line of code in a system and still not really control it, because control depends on people — on whether the people who understand that code are still around, whether documentation kept pace, and whether a major upgrade eventually collides with years of accumulated customization. The city wanted protection from vendor dependency. What I wanted them to consider was whether their proposed solution might just trade one form of dependency for another, less visible one.

I was also adamant that we couldn’t win this by simply insisting our product was better — they’d already said no to it. Telling a city “trust us, you’ll love it” when they’ve explicitly rejected your category is a bit like offering someone ice cream after they’ve already told you they don’t want ice cream, and waving the spoon in front of their face anyway. That can work when there’s enough existing trust for someone to take a leap with you. With a stranger, you’re more likely to get ignored.

So the first job wasn’t to persuade the city that our product was good. It was to figure out whether their original decision was even worth reconsidering, whether their stance was born out of something they genuinely knew, or because of something they didn’t. Leadership had already decided the RFP wasn’t worth the effort, not because they thought the reasoning was wrong, but because there were bigger priorities competing for the same hours. I saw it differently and made it a personal project, working on the proposal on my own time on the theory that a closed door isn’t enough information by itself. I wanted to know who closed it, why, and whether that reason still existed. So I built the pitch around the operational risk underlying the city’s appeal to control: security maintenance, software upgrades, institutional knowledge, staff turnover, and the long-term cost of supporting a heavily customized system that nobody outside the original team could easily touch.

Not long after, I learned that almost exactly this scenario had already played out in my own backyard. A nearby city had spent more than $500,000 on a custom municipal website. The developer who understood the system left under difficult circumstances, a former colleague was brought in to patch things together, and after another $250,000 in consulting fees, the city concluded it needed to replace the whole site.

I hadn’t predicted those specific events, and another city’s expensive mistake wasn’t something to celebrate. But the abstract risk I’d been trying to describe had just become painfully concrete, and it landed hard, partly because I was still learning, at the time, to trust my own judgment when it ran counter to the prevailing opinion in the room. There’s a real difference between assuming you’re right and believing your questions deserve to be heard. The first is arrogance. The second just takes enough confidence to examine the evidence and say something when the accepted frame looks like it’s missed something.

We won the contract, and during the implementation phase, the city later told us our proposal stood well ahead of the 21 competing bids. But the lesson I carried forward wasn’t that persistence always wins, or that every objection is wrong. It was simpler than that: the most useful question usually isn’t how to overcome an objection. It’s whether anyone still knows why the objection exists.