Their support assistant depended on one AI model. Then the provider retired it, with three weeks' notice.
The email arrived on a Tuesday, addressed to every developer using the model: it would stop answering requests in three weeks. For most of the provider's customers, that was an inconvenience. For Sena Kodjo, it meant Kora — the customer-support assistant his two-person startup had spent six months building — was three weeks from going silent.
Kora answered customer questions for small e-commerce sellers in Lomé, in French and in the local phrasing their customers actually used, over WhatsApp and web chat. It read each seller's product catalog and return policy, and answered "where's my order" and "do you deliver to Kpalimé" without a human typing the reply. Sena and his co-founder had built it as two people, which meant every integration had exactly one person who understood it: him.
The backend was Node.js. Product catalogs and past support conversations lived in PostgreSQL, with pgvector storing embeddings so Kora could search a seller's FAQ and policies for the right answer instead of guessing. The AI itself came from a single model, called directly through that provider's own API — the integration Sena had written first, back when Kora was a weekend prototype, and never revisited.
That was the part the deprecation notice exposed. The prompt formatting, the response parsing, the retry logic, the error handling — all of it had been written against the particular quirks of one provider's API. Switching models wasn't a config change. It was a rewrite of the one integration the entire product depended on, with three weeks to do it and paying sellers already relying on Kora every day.
"He hadn't built a product with an AI feature. He'd built a product that was quietly one vendor's API contract away from not existing."
Kora already ran on Qeda — the Node.js backend deployed from Git, PostgreSQL with pgvector managed rather than self-hosted. What Sena hadn't used yet was the AI Hub: a single OpenAI-compatible endpoint in front of several model providers, billed from the same wallet that already paid for Kora's compute.
Because the AI Hub spoke the same OpenAI-style request format regardless of which model answered it, most of Sena's original integration code didn't need touching. What changed was one configuration value — the model name — and the handful of prompt tweaks needed to get the new model's tone as close to the old one as he could manage. He had Kora answering real customer questions on a different model five days after the notice, not three weeks.
The bigger change was what he stopped worrying about. Compute and AI usage came out of the same Qeda wallet, topped up the same way — Mobile Money, no international card, no separate AI vendor invoice landing in a different currency at the end of the month. One balance covered the servers Kora ran on and the tokens it spent answering questions.
Fun fact: Sena kept the old model's integration code for exactly one week after switching, "just in case" — then deleted it, and left the model name as a single environment variable so the next forced migration is a five-minute problem instead of a three-week one.
I used to think of the AI model as part of my product. It isn't. It's a supplier, and suppliers change terms without asking you first. One API in front of several models meant that when one supplier walked away, I didn't have to rebuild the business — I changed one line.
Join the builders across Africa who ship faster with Qeda.