CASE STUDY · PRODUCTS & PLATFORMS · ACQUIRED 2026

Built it, ran it, sold it: Lumo, an AI support assistant

Most portfolio projects end with "and it shipped." This one ends with an acquisition. Lumo was an AI support assistant I built, operated as a standalone product, and sold. Jobvious acquired it in 2026, and it now powers their in-product AI support chat.

The product thesis

Every business answers the same customer questions forever. What are your hours, how do I reset my password, what does the plan include, where is my order. The questions change per business, but the pattern never does: the answers already exist somewhere in the company's own material, and a human repeats them all day anyway.

Lumo was built on a simple bet: an assistant grounded in the business's own knowledge base could handle that repetition. Not a generic chatbot with canned decision trees, and not a general-purpose AI that knows everything except your business: an LLM-powered assistant that answers from what the company itself has written.

The product problem: trust

The hard part of an AI support assistant isn't making it talk. It's making it trustworthy. An assistant that invents answers is worse than no assistant at all. A wrong answer delivered confidently, under your company's name, on your own website, costs you the customer's trust twice: once for the mistake, and once for automating it.

So grounding wasn't a feature of Lumo; it was the product. Answers came from the business's own knowledge base. The company's material was the source of truth, and the assistant's job was to retrieve and express it rather than improvise around it. That constraint is what made the widget something a business could actually put in front of paying customers.

Embeddable by design

Distribution shaped the architecture as much as the AI did. Lumo shipped as an embeddable chat widget, a component any company could drop into their existing site without rebuilding anything. Each installation pointed at that business's own knowledge base, so the same product served different companies while every answer stayed specific to the business asking it to speak.

Operating it as a product

Building Lumo was half the work. Running it as a SaaS was the other half: keeping the service up, onboarding businesses onto their own knowledge bases, and watching how the assistant behaved in front of real customers rather than in a demo. A support assistant only earns its keep in production, on someone else's website, answering questions I didn't script. Operating it was where the product got honest.

The exit

In 2026, Lumo was acquired by Jobvious, a US hiring platform I know well from the engineering side (there's a separate case study on that platform). Lumo now runs as Jobvious' in-product AI support chat: the same grounded-answering product, serving the users of a production hiring platform.

I'll say only what the outcome says. A company examined the product, the code, and the way it ran, then chose to buy it and build it into their own platform. An acquisition is the strongest possible code review.

What this proves about Exybit

Most software work is judged on whether it shipped. Lumo was judged on every stage after that too:

• Idea → product: I identified a real, recurring business need and built a focused product against it.
• Product → operation: I ran it as a standalone SaaS, in production, for real businesses.
• Operation → exit: another company acquired it and put it to work inside their own platform.

That full arc, build it, run it, sell it, is the level of ownership Exybit brings to client work. I build things that hold up when a business depends on them, and occasionally when a business decides to buy them.