For a SaaS company, the cost of sudden API changes aren’t measured in your developers’ time, but your clients’ trust and goodwill. Worse, the burden doesn’t fall on small clients at your lowest tier, you are placing the burden squarely on your most valuable enterprise customers, who have invested in custom API integrations. API changes are unexpected hits to your client’s timelines and budgets. Nothing will change your image from a trusted partner, to a flake that needs to be replaced, faster than a developer spending a day doing a hotfix because their API integration stopped working.
At the same time, you need to keep improving and expanding your service. How do you keep moving forward? The answer is extremely low tech: set expectations and communicate your API Obsolescence plans.
By law, auto manufacturers have to make parts for 10 years after they stop selling a car. Microsoft typically guarantees 5 years of support for Windows as part of the purchase price, with an option to pay for 5 additional years.
Unless you publish a sunset date for an API feature, your clients will expect you to keep supporting it for the life of the contract. Most SaaS companies offer discounts for annual renewals; your API is locked in until a year from tomorrow!
Can you afford to support your current API for another year? Can you afford to change it?
If you don’t have an Obsolescence strategy, here are 5 tips for getting started:
- Notify early! A year is ideal, but a week is better than nothing. Your goal is to be a trustworthy and stable partner. Putting notifications on your website will give you clarity and your support reps something to bring to your clients.
- The less lead time you can give, the more important it is to reach out and talk to your most important clients. Make sure you have a way to communicate with your client’s developers. Email lists, documentation, even a notice on login. From your client’s perspective, all outages from missed notifications are your fault so you have to take responsibility for notifications.
- Know which clients are using which features. Metrics around which clients use which pieces of your API are critical for making prioritization and communication decisions. These metrics don’t need to be real time, you can generate them nightly or weekly from your server log files. But if you don’t know who uses what, you have to assume everyone uses everything.
- API versioning makes everything easier. If you aren’t using a versioning scheme, that should be your first change.
- An endpoint is a contract, not code, and you should only communicate contract changes. You can create a new endpoint that uses old code, or completely rewrite the code behind an existing endpoint. Endpoints are a decoupling point, and they give you a bit of freedom and wiggle room.
Taking control of your APIs lifecycle is key to managing your tech debt. Tactical obsolescence may be your Best Alternative to a Total Rewrite.
