Build feasibility analysis API with provider comparison and recommendation — lab audio overview

Host: Welcome back. You're in AI Solution Delivery — a course about turning business problems into working AI systems that your team can actually ship. This chapter is on use case discovery and data readiness — basically, the early conversations you have with a client before a single line of code gets written. And today's skill — deciding which AI model provider is the right fit for a given job — is something every delivery team wrestles with the moment a project gets real. Expert: Right, and let me paint the picture. Imagine you're a solution architect at a consulting firm. A client comes in — maybe a mid-sized insurance company, maybe a retail chain — and they say, "We want to use AI to summarize customer complaints." Simple ask on the surface. But now you have to answer three questions before you can quote them a price. Which AI provider should run this? How much will it cost per month at their volume? And will it be fast enough for their customer service team? Today, most delivery teams answer those questions with gut feel and a spreadsheet. That works for one use case. It falls apart when you have fifteen use cases across three clients, and each client wants evidence, not opinions. What you need is a small internal service — something your whole team can call — that takes a use case description and gives back a defensible recommendation. That's what you're building today. Host: Okay, so this is the third and final exercise in this sequence. In the previous one, you built the engine that sends the same prompt to several AI providers at the same time and measures how long each one takes and what each one costs. Now we're extending that. So what exactly are we building on top? Expert: You're building a small web service — a piece of software that other tools in your company can talk to over the internet. Someone sends it a description of a use case, like "summarize a two-page complaint letter in three bullet points," and the service sends back a structured answer: here's the recommended provider, here's why, here's how it scored on quality, cost, and speed. The web framework you'll use is called FastAPI — it's a popular tool for building these kinds of services in Python, and it's designed to be quick to write and quick to run. Under the hood, your service will call the benchmarking engine you built last time, then layer something new on top: a scoring step. And here's the key idea — the aha moment. A recommendation is not just "pick the cheapest" or "pick the fastest." A recommendation is a weighted decision across three dimensions — quality of the output, cost per request, and response time. Different use cases weigh those differently. A legal document summarizer cares about quality above all. A live chatbot cares about speed. A batch report generator cares about cost. So your service has to accept the use case, figure out which dimension matters most, score each provider, and pick a winner with the reasoning attached. Host: That makes sense. Before someone starts writing this, what's the part that usually trips people up? What should they watch out for? Expert: The trap is treating the three scores — quality, cost, and latency — as if they live on the same scale. They don't. Cost might come back as fractions of a cent. Latency might be hundreds of milliseconds. Quality might be a score from one to ten. If you just add them up, cost will barely move the needle and latency will dominate, or the other way around. So before you combine them, you have to normalize — which just means rescaling each one so they all live between, say, zero and one. Then you apply weights based on the use case, and then you combine. The second thing to watch for is this: when one of the AI providers fails to respond — times out, hits a rate limit, returns an error — your service should not crash. It should note that provider as unavailable and still return a recommendation from the ones that did respond. Plan for that from the beginning, not as an afterthought. A feasibility service that falls over when one provider is having a bad day is not a feasibility service your team can trust. Host: Good warning. So let's close it out. What will someone be able to do after they finish this, and where does it leave them? Expert: After this, you'll be able to take any proposed AI use case and produce a defensible, data-backed recommendation in seconds — with numbers for quality, cost, and speed, and a clear winner among the available providers. That's a capability your delivery team can plug straight into client discovery workshops. Instead of walking into a room with opinions, you walk in with evidence. And because this is the final exercise in the objective, you now have the complete feasibility analysis toolkit — the routing layer that talks to multiple providers, the benchmarking engine that measures them in parallel, and the recommendation service that turns those measurements into a decision. That's a real production building block you can bring back to your team's architecture discussions, and a solid foundation for the next chapter, where use case selection turns into data readiness — can the client's actual data support the use case you just recommended? Thanks for listening, and good luck with the build.