Your AI feature has been eighty percent done for six weeks: the stream dies at sixty seconds, the bill is unattributable, and nobody owns the wire between the app and the model. What to screen for, in ninety minutes, at 2026 rates.
The demo worked in a notebook in June. Someone pasted the screenshot into Slack, three people said ship it. Since then: the stream dies at sixty seconds behind the customer's load balancer, the staging bill went from $30 to $912 with no way to say which tenant spent it, and security wants a written answer for why tenant B's MSA can't surface in tenant A's summary. Nobody owns the wire between the app and the model, so the feature has been eighty percent done for six weeks.
Almost nobody searching "hire a full stack AI developer" needs research. For most B2B products the first AI hire should be a full-stack engineer who has already shipped a streaming, token-metered, evaluated feature — not an ML engineer. You are calling somebody else's model over HTTPS. The work is retrieval quality, abort propagation, per-tenant isolation, cost attribution, and reproducing Tuesday's bad answer with the exact prompt version, model version, and retrieved chunks that produced it. Application engineering problems wearing an AI hat. Screen for those.
A normal request in your app is 120ms and deterministic. A model call is 2–40 seconds, non-deterministic, billed per token, and returns 429 or 529 on one to two percent of calls under load. Every assumption breaks at that seam. A request-scoped Postgres connection stays checked out for the whole stream, so twenty concurrent chats drain a twenty-connection pool and the marketing site goes down with the chatbot. An ALB's 60-second idle timeout cuts long generations off mid-sentence. Nginx buffers SSE until you set proxy_buffering off, so the user watches a spinner for thirty seconds, gets the entire answer at once, and blames the model. Retry-on-5xx bills you twice for a generation that already finished.
Best single interview question: what happens when the user closes the tab mid-stream? A right answer names three things — the provider keeps generating and keeps billing unless you propagate the abort signal; if the assistant message is persisted only in the onFinish callback, you now have a user turn with no reply and a thread that renders broken on reload; and the reconnecting client fires a second generation against the same turn. People who have shipped this flush partial output every few hundred tokens, or move generation into a job row the client reattaches to by id. People who have read the SDK docs say "the stream just ends."
Cost breaks first. Without a row per model call — feature, tenant, model version, input tokens, output tokens, cached tokens, latency, finish reason — week three brings a $4,100 invoice and no query that explains it. It is one table and one insert next to logging you already do, and it has to exist before launch, not after finance asks. Ask candidates for their four-figure weekend. Everyone who has shipped this has one, usually an agent loop with no step cap that re-read the same 40k-token PDF eleven times.
Isolation breaks second, and it's the one that ends contracts. The pattern we keep inheriting is an agent handed a service-role database key so it can "just query what it needs," which puts the tenant filter in a sentence in the system prompt. One line inside an uploaded PDF and it reads across customers. The filter belongs in the retrieval query, bound to the authenticated session's tenant id and backed by row-level security. Quality drifts third: top-k of five was fine over 200 documents; at 20,000 it returns five near-identical copies of the same contract boilerplate. The fix is dedupe, smaller chunks, and a reranker — not a bigger model.
Skip the algorithm puzzles. Hand them a repo: one API route that calls a model, Postgres with pgvector, five hundred of your real documents, and one failing case where the answer cites the wrong source because the paragraph holding the answer got split across a chunk boundary. Ninety minutes, internet and any assistant open. Watch what they touch first. Engineers who have shipped retrieval print the returned chunks and their scores before changing a line. Engineers who haven't start rewriting the prompt. That tell outranks the résumé.
Then four questions with right answers. How do you hold a 30,000-token thread under budget without silently dropping the system prompt, and what gets summarized instead? Where does the prompt live so a non-engineer edits it without a deploy and you can roll back to Tuesday's version by id? What's your p95, given a stream has two latencies — time to first token and total completion? And how do you know a prompt change didn't break the other forty cases? If the last answer isn't a checked-in eval set with expected citations that runs in CI on every prompt diff, they will ship regressions by feel.
2026 rates, for someone with this on their commit history: $70–140 an hour freelance in the US and Western Europe, $35–70 in Eastern Europe and Latin America, $25–50 in South Asia. A studio retainer with a dedicated engineer plus senior review runs $9k–20k a month. Full-time in the US lands at $170–240k for a strong mid-to-senior. Google and TCS and Deloitte hire full-stack developers by the thousand — that's why the search volume looks like it does — but they're staffing internal platforms. You're paying for scarcity at the seam, not for the title.
Structure it to find out fast. Don't hire full-time before one AI feature is live. Buy a three-week paid scope with a named deliverable: one feature end to end, behind auth, with an eval set, per-call cost rows, and a one-page runbook for the provider outage that will happen in your first quarter. If no real user has touched it after three weeks, three more won't help. This also caps the most expensive failure mode of the hire — a very good generalist who spends a month building a provider-abstraction layer over four APIs you will never call.
The strongest candidates ask about your data before your model: how many documents, in what formats, how often they change, who may see which ones, and what a wrong answer costs you in dollars or in a renewal. Leading with model choice optimizes the one variable you can change in an afternoon with an env var. Leading with your corpus means they know which half of the system is a commodity.
Second signal: they'll tell you when the AI feature is the wrong build. We've talked clients out of a chatbot and into a filtered search box with three facets, because the questions users actually asked were structured and retrieval was doing all the work anyway — it shipped in nine days and gets opened daily. An engineer who can say that in month one beats one who ships a polished agent nobody opens twice.
A software studio that ships and maintains its own products — KeepChats, Gwora and MoveProof — and builds the same way for clients. Founded and led by codewithumar.
Talk to the studio →Send the problem. You get one fixed number and a plan back within a business day.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar