Before the development of any feature, we ask ourselves:
1) What problem are we solving?
2) How will we know we solved it and brought value once we’re done?
When a customer approaches your company and says, “If only your product could do X, we’d be thrilled”, you know the exact problem to solve and value it will bring.
But this means veering away from the roadmap, shipping out quick hacks, and piling technical debt.
Let’s get the best of both – building custom code fast while staying in the CI/CD world.
——
I’m going to tell our story of how developing customer-specific solutions brought the company to a billion-dollar evaluation, but also left us with a huge pile of garbage code that we had to manually keep track of, maintain, and continuously update for years.
And then how we took a step back.
But, instead of changing our approach and deciding we’re stable enough of a product to stop saying yes to what customers want by tomorrow (like most companies do), we built amazing tools and infrastructure to continue doing so in a responsible way.
We developed three automated systems for custom code:
1) Feature flags
2) Plugins
3) Custom libraries
All three have different use cases, architectures, and relationships with the main code base’s “master” branch.
I am going to explain the business drivers of each one — when you would use it and how, as well as the technical design of each one — how it’s built and how it stays in line with the production release.
What are the key takeaways from this talk?
You’ll walk away realizing that it’s possible to ship out fast custom solutions responsibly, and you’ll finally understand how
