By name, at least, I’ve now worked at six different vendors of government solutions. There’s a fundamental tension that arises when building for state governments especially, that I’ve seen over and over again:

• On one hand, vendors want to build products that can be deployed repeatedly across states for cost-effectiveness at scale and rapid per-project implementation
• On the other hand, states have wildly-divergent policy landscapes and political realities, even in seemingly similar domains, demanding highly customized solutions

This tension creates numerous challenges. First, how should the system be architected to support configurability in the first place? It adds cost and risk to do so. And then, how should vendors approach communication of configurable features to a paying customer who doesn’t need the options? If you’re collaborating closely during development (as you should) it’s going to come up in planning and status meetings.

A case I’ve made that usually resonates is that having configurable options enables us as a vendor to maintain a (mostly) common codebase across customers. And that means when an improvement is made for any customer, everyone benefits. More succinctly: forks are bad. I can tell at least one tale of a high profile private customer that initially insisted on having their own radically customized copy of our company’s core product line, only to regret it a few years later when it took months to back port newer features to it.

Here’s a few considerations for product and engineering folks to consider when developing a solution for scale through repeated implementations:

• First Project: have scalability in the back of your mind, but don’t fall prey to YAGNI and overbuilding otherwise you’ll price yourself out of your first customer; just do basic foundational configurability and focus primarily on your immediate requirements
• Second Project: don’t make the mistake of thinking you can discount your pricing, you’ve yet to hit economy of scale, and you’ll need any budget saved from reuse to expand your configurability capabilities and begin thinking long-term scaling strategy
• Third Project: this all-important moment is where you can now truly begin thinking about productization, having full configurability (going beyond mere look and feel to business logic) and rapid, repeatable deployments
• Fourth Project: now you should be reaping the efficiency benefits of your configurability and repeatability; if you haven’t yet, act fast and make investments at speed, or it’ll be too late

Finally, an anti-pattern:

if customer == 'Customer 1':
    doAThing()
elif customer == 'Customer 2':
    doADifferentThing()
elif customer == 'Customer 3':
    doYetAnotherThing()

The above might be fine for your first couple projects, but if it’s still in your code by project 3 or 4, you’re doomed.