Technology

One engine, three products.

One engine runs a vehicle database, a price catalogue and a study library. We run AI in production every single day.

The pipeline

01

Ingest

Distributed crawlers and serverless scraping fleets on AWS Lambda, running continuously against merchant catalogues, distributor sheets and news sources.

02

Extract

Layout-aware OCR and document AI over scans, handwriting and PDFs, with confidence scoring and human-in-the-loop correction where accuracy is non-negotiable.

03

Reconcile

Entity resolution and schema-constrained normalisation, so contradictory sources collapse into one canonical record with its provenance attached.

04

Serve

Retrieval augmented generation and agentic tool calling, behind rate limiting, authentication, cost accounting and provider failover.

Capabilities

Retrieval augmented generation

Answers are grounded in retrieved source documents and structured records, not in model recall. This is the difference between a useful assistant and a plausible liar.

Agentic tool calling

Models call real search tools against our databases and compose an answer from the results, with the tool loop orchestrated server side.

Document AI and OCR

Layout-aware extraction from scanned handwriting, exam papers and dealer PDFs, including Devanagari source material.

Embeddings and semantic search

Vector retrieval for entity resolution across product catalogues and for finding the right passage in a study corpus.

Speech synthesis

Narrated explainer shorts, generated from the study corpus. Working today on selected topics, not yet across the whole library.

Provider failover

A provider abstraction over inference lets us switch or fail over between hosted models without touching product code.

Infrastructure

Models

Llama 3.3 70B on Groq, AWS Bedrock (Claude, Nova)

Backend

Python, FastAPI, AWS Lambda, API Gateway

Data

MongoDB Atlas, DynamoDB, S3, CloudFront

Frontend

Next.js, React, Tailwind, AWS Amplify

Mobile

Capacitor, Android, Chrome extension

Practice

Infrastructure as code, CloudFormation, CI/CD

How we build

We use the same approach internally that we sell externally. Day to day, five or more teams of AI agents run in parallel: one cleaning and normalising scraped data, another writing and running tests, another rebuilding a page or a pipeline. Each team gets a narrow brief and a way to check its own output, and a human reviews and owns everything that ships.

It is why three products stay in production and improve every week without a large payroll.

Where the compute goes next

Today every model we run is a hosted API, on AWS Bedrock and Groq. We expect that to change, because we are sitting on data those models handle badly.

  • Handwritten Devanagari from thousands of scanned pages. General-purpose OCR still fails on it, and our study corpus is the labelled data needed to do better.
  • Nepali-language answers, a domain where frontier models are weak simply because the training data barely exists.
  • Local product and vehicle names, which generic embeddings match poorly, so entity resolution needs a model tuned to how Nepali sellers actually write.

Fine-tuning on that corpus is the obvious next step, and it is the point at which we become GPU-bound. We are not there yet.