Why we build AI-first products — and run them in production

A demo is not a product

Anything can be made to answer one question convincingly. What is hard is the second week: the question phrased in a way nobody anticipated, the answer that is fluent and wrong, the moment the fee it quoted does not match the fee the institute charges. A demo is judged on whether it responded. A product is judged on whether the answer was correct and whether anyone was able to correct it.

That gap is why we build our own products rather than only taking briefs. Running something under our own name for a second year is the only way to find out which of our opinions about software were right.

Three products, all of them live

Pathshala is a modular AI ERP for schools, coaching centres, tuition, colleges and skill institutes — sold product by product, or all together as MJX ONE. MJXCard is a digital business card shared by link and QR code. VahanQR is a windscreen QR sticker that lets somebody reach a vehicle owner without ever seeing their phone number.

They look unrelated and are not. All three are the same two problems: reach the right person on the channel they already use, and do it without handing over more than you have to.

Grounding is an engineering decision, not a setting

The Pathshala AI answers only out of the institute’s own knowledge base. It is not a filter applied to a general model’s output; it is where the answer comes from in the first place. And where a document exists, it sends the document — the fee sheet, the syllabus, the brochure as the PDF it already is.

The same instinct produced the masked-contact design in VahanQR. A scan can place a call or send a message, and on its privacy plans the number itself stays hidden; a caller confirms the last four digits of the plate before anything connects, and abuse is IP-blocked automatically. Reaching somebody and being able to reach them again are different permissions, and most systems grant both because separating them is work.

And then we run it

Hosting is part of the work rather than an afterthought: nginx, TLS, process supervision, backups, log retention, and changes shipped after launch and not only before it. The people who wrote the code are the people a customer reaches when something breaks.

This is also what the engineering work we take is built out of. The service lines on this site are not a capability deck — each one names the shipped product it came out of, which is the only claim about capability worth making.

The interesting part of an AI reply is not that it is fluent. It is that it is correct, that a person can interrupt it, and that somebody notices when it stops.