Discussing SLMs with Olakunle Ebenezer Aribisala of Techparlons

In this interview, we talk with a leading data engineer at Techparlons about the company’s SDKs, purpose-built small language models, and the engineering choices behind their production APIs.

Journalist: For readers new to TechParlons, what problem are you recently solving?

Olakunle: We are solving the highly technical problems. We build purpose-built AI models and APIs, things like an AI Web Scraper, vOCR, translation, search, speech-to-text that return consistent, structured outputs with low latency. The bet is simple: for production work, right-sized models and a clean developer experience beat a one-size-fits-all LLM.

Journalist: Your promise structured outputs, observability, and global performance. What did you personally ship that makes people bet on this solution?

Olakunle: On the TypeScript and Python SDKs, I led the design for typed responses, schema validation, streaming, retries with jitter, exponential backoff, and automatic parsing to the caller’s interface so the JSON structure is stable release-to-release. We instrumented the SDK to surface real-time logs/analytics (latency, error codes, geos, session IDs, IP over 30 datapoints) in the dashboard, and I wired client hints for our smart cache and region selection, so calls hit nearest compute. The platform’s structured data, observability, 160+ languages, 90+ distributed GPUs, smart caching are the constraints I engineered too.

Journalist: Speaking of Prompt Engine: how does it work under the hood?

Olakunle: You define a prompt with an expected return schema. At runtime, the engine runs your prompt across a small bucket of candidate LLMs in parallel, uses a smaller ranking model to score outputs, and merges the top candidates into one response. It also adds prompt optimization and streaming, and we keep it backward-compatible as providers roll new models. For teams, the value is quality and stability without constant prompt surgery.

Journalist: Briefly give me the SDK elevator pitch.

Olakunle: Import, pass an API key, and you get typed methods for Scraper, vOCR, Search, TTS/STT, and Prompt Engine with streaming, timeouts, retries, and first-class error types. We launched the JavaScript and Python SDKs to make “hello world to production” fast.

Journalist: Where can developers meet your engine in the wild?

Olakunle: Besides the SDK, you’ll see Prompt Engine in LangChain integrations, and we publish templates that can run across models with copy-paste code in several languages.

Journalist: Let’s dig into models. What’s distinctive about the AI Web Scraper and your contribution there?
Olakunle: Two things. First, the model is trained to behave like a developer, not a generic LLM. It “thinks” in steps from DOM inspection to network logs to selectors, so it’s robust on modern, dynamic sites. Second, the SDK + API return consistent, schema-true JSON so downstream pipelines don’t break. I worked on the data pipelines and evaluation harnesses,page fixtures, anti-bot flows, and structured fidelity checks.

Journalist: What about vOCR?

Olakunle: vOCR focuses on production-grade extraction: text accuracy, layout fidelity (bounding boxes), multi-language support, and ability to retrieve specific fields (invoices, IDs) consistently. I helped align the SDK’s response types with the model’s layout metadata, so the same code works across document families. Our public breakdown contrasts this with Mistral OCR across real-world docs.

Journalist: Developers love examples. Where do you point them?

Olakunle: The AI Web Scraper docs and a Supabase Edge Functions tutorial are good starting points; they show how to wire secrets, make repeated calls, and map responses in real projects.

You made a bold claim: “serverlessly run billions of models concurrently in <200ms.” What does that mean for SDK and API design?

Olakunle: It means we design for burstiness: idempotent requests, stateless handlers, circuit breakers, and observability baked into the client so we can autoscale globally without sacrificing debuggability. The SDK’s retry rules, request IDs, and structured errors are all there to survive that scale.

Journalist: How do you measure “production-ready” on your team?

Olakunle: Three gates. Schema stability across versions such as SDK types and JSON Schema tests, Latency SLOs by region with cache effectiveness tracked and Truthfulness to spec for Scraper and vOCR we validate that outputs match required fields and formats. Those are enforced in CI before we ship endpoints or SDK releases.

Journalist: Thank you for your time

Olakunle: You are welcome.