There's a rule that's been drilled into the head of pretty much every software executive I've ever worked with, and it's one that gets learned the hard way (as I experienced myself, back in the day): don't customize. If you build its capabilities into the product, configuration is good; it is even an opportunity to make your customers a bit happier and stickier. So, give your customers some knobs and toggles so the product feels like theirs, but keep it within the framework you control, and without additional product development required. But avoid customization and avoid that demanding customer that requires one-off customization (and especially that “unicorn” customer that brings an appealing logo or big contract but isn’t really your ideal customer profile, or ICP, and which can crush your product roadmap).
But I think AI might rewrite those rules a bit. Not erase them, but move the line quite a bit. AI coding tools, when put in the right hands, might just allow for a level of customization that was previously best avoided, and a level of bespoke “development” that was just a bad idea.
Why We All Learned to Say No (often learning the hard way)
The old logic here was sound, and it's worth reviewing before we talk about what has changed. Customization has helped land many an account … sometimes it was the big one you dreamed of, and one that feels like a “company maker,” especially for an early-stage business. But that customer wasn’t quite interested in what you built; they wanted something else, and you didn’t want to lose the account. So, you acquiesce and deliver.
Occasionally that works out because what they want is on your roadmap, but most of the time it is not. Sometimes that’s because this particular customer really isn’t in your ICP, which starts to box out your product roadmap for your true ICP. But (and perhaps worse) sometimes that customer is just asking you for what they want, not what they need. They’re the right profile of customer, but you are so willing to appease them that you don’t push back, and you build what they want; not what they (and the rest of your target customers) need.
The result: you focus on building for them; you can wind up delaying your roadmap and sometimes even forking your code. You build a feature exactly one customer will ever use; and sometimes one they won’t even use. Most importantly, you burn product development cycles that should've gone toward the product everyone else needs, and then you have to manage and maintain these features that exactly one customer uses. It is a time suck and a cost suck, and it can ultimately really harm the long-term roadmap and the business.
Enter Agentic Configuration! (basically, agentic customization … 😊)
But as we are seeing with so many things, AI shifts the picture. Agentic coding tools can not only rapidly accelerate product builds, but they also make it easier for non-technical folks to do the building. And if your development team puts some framework and walls around it, you could start to have your Customer Success (CS) team, your sales engineers (maybe even mid-sales cycle), and sometimes even your customers build on top of your core platform. Suddenly, these parties can spin up a custom front end, a bespoke workflow, or a purpose-built app, all still living inside the sandbox of your platform.
Don’t get me wrong, you still probably have some management headache, but you mostly get real customization without the product development time suck and without the dislocation of your product roadmap. And maybe you even learn a thing or two about how your customers want to use the product, while they get something that genuinely feels built for them. That is a very different trade than what it was in the past.
I'd think about the implementation options on a spectrum, roughly in order of how much you're willing to let go of the wheel. On one end, full self-service: give customers the tools to build their own customized front end or feature directly, no developer required. In the middle, your CS team becomes the build layer, using AI to construct bespoke components for customers without CS quietly morphing into a professional services organization. And on the more conservative end, CS or sales engineering vibe-codes something lightweight that still routes through product and engineering before it ships; the least efficient of the three, but really with the greatest control (though maybe losing a lot of efficiency).
Where you end up probably depends on how much you trust your own guardrails and how sensitive the underlying data is. But the direction is the same regardless.
Product Discovery (an exciting byproduct)
I made a quick mention earlier about “learning from your customers,” and maybe that is where this gets even more interesting. If you've built a genuinely differentiated piece of underlying technology and made the disciplined decision to focus it on one specific application and end market (at least to start, to maintain focus; exactly the kind of decision I personally applaud), agentic configuration can give you a cheap way to find out what else that technology could do, without spending much of your engineering team’s time finding out. Open the platform up and let customers, or your team working alongside them, build custom applications on top of your core tech. Want to try out a new market? Have a founder or product leader sit with a prospect in that new space and really test some ideas; in a way that wire diagrams never could. If it clicks, and the opportunity is there (and I’ll repeat, not too distracting), maybe that is your next growth vector.
Some points of caution and some final thoughts
None of this is free of risk, though. Once you have different customers building different things on your platform, or your team jamming away on new designs or front ends, you're going to get more variance, more weird edge cases, and almost certainly more customer success load than you're budgeting for today. That’s part of the concern that made customization a bad word in the first place … but done right, maybe that impact can be limited, while you can get some upside from pushing out the boundaries of “configuration.”
Get it right, though, and you've found another version of the same pattern from my prior blog post series (Defensibility of Software in the Age of AI): encoded software providing the walls, the governance, and the security, and AI providing the flexibility that used to be prohibitively expensive to offer. Not AI instead of your platform. AI + encoded software leading to an even more powerful outcome for your customers.
