Skip to content

What we have built, and where it runs

Each write-up gives the problem, what we built, the stack it runs on and our part in it. Where we measured a result, the figure is here with how it was measured.

Every write-up on this page

Each engagement written up on this page, its outcome, the service it sits under and where it runs
EngagementOutcomeServiceWhere it runsDetail
Polaris ERP and POSOur productOutcome19 Pakistani businesses run their day on Polaris. One reporting path went from 750ms to 230ms on the same hardware.ServicePolaris ERPWhere it runsRetail and wholesale shops in Pakistan, on their server or oursDetailRead
ObeliskClient systemOutcomeOne assistant in front of more than 15 specialised agents. The first streamed token arrives in 8 to 10s, down from 22s, and each workspace's material stays inside it.ServiceAI automationWhere it runsMarketing teams, on Google CloudDetailRead
RISQClient systemOutcomeEach intake call is scored for authenticity and routed to a closer, to review or to quarantine.ServiceAI automationWhere it runsIntake for US mass tort law firmsDetailRead
AnatomiaClient systemOutcomeCalls are scored for urgency, so the case that cannot wait is read first.ServiceAI automationWhere it runsA healthcare provider, on AWSDetailRead
Bonnet.aiCo-owned ventureOutcomeA brief becomes one document of research, strategy and moodboards, and a weak step reruns on its own.ServiceAI automationWhere it runsCreative and brand teamsDetailRead

Polaris ERP and POS

Our own ERP and POS. Billing, khata, stock and books for Pakistani retail.

The problem

A Karachi retailer kept stock and customer balances in Excel. Reconciling the day took the morning, and a customer who wanted to know what they owed had to call and wait while someone looked it up.

What we built

  • One system of record across branchesStock, billing and reporting for every branch sit in one PostgreSQL database. A transfer between two shops is one row.
  • Questions in Urdu or English, answered from live dataThe owner types a question in the language they think in. Polaris resolves it against the live schema and returns the matching rows. Nobody on the floor writes SQL.
  • Every write gated, logged and reversiblePermissions decide who can take each action, an audit row lands with every write, and a mistake caught within five minutes can be undone in one step.
  • Your server or oursThe deployment target is a decision the business makes. The data stays wherever it is put, which is the answer most owners want before anything else.

Where it stands

19 Pakistani businesses run their day on Polaris. Each figure below is traced to the system it is read from.

Polaris ERP and POS at a glance

Industry
Retail and wholesale
Who it is for
Shop owners and their counter staff, in Pakistan
Our role
Our own product, built and deployed by us
Stack
Vue, PostgreSQL
We switched from Excel last year. Reconciliation that used to eat the morning now happens before chai is finished, and our customers check their balances on their own phones.
Hassan TradersRetail, Karachi
Hardware is a lot of small parts in a lot of sizes, and we used to find out something had run out when a customer asked for it. Now I check stock in Polaris before I order. When something did not fit the way we work, Hassan changed it.
Muhammad BilalOwner, hardware store, runs it on Polaris

Where the Polaris figures come from

If a number here cannot be traced to a system we can open in front of you, it should not be here. Ask us to show any of these on a call.

The Polaris figures and the system each is read from
FigureValueHow it is counted
Live businessesValue19How it is countedBusinesses running Polaris in production today.
PermissionsValue157How it is countedCounted from the permission table that gates every action.
Built-in reportsValue52How it is countedReports shipped in the product, run against the live ledger.
Report response timeValue750ms to 230msHow it is countedOne reporting path, timed before and after its query was reshaped. No hardware was added.

Obelisk

A marketing platform where more than 15 specialised agents, from SEO and email to brand voice and strategy, work from a team's own documents, analytics and Slack. One orchestrator coordinates them, so a marketer talks to a single assistant and never picks an agent.

The problem

Answers were slow to start, and one organisation's material could never be allowed to reach another's.

What we built

  • One assistant, one orchestrator behind itThe marketer asks one assistant. The orchestrator hands each request to the specialist that owns it, out of more than 15, so nobody has to know which agent to pick.
  • Four retrieval streams at onceReferenced documents, semantic search, web content and business context are queried in parallel, after a fast model rewrites the question. The merged results are deduplicated and re-ranked.
  • Documents as teams actually keep themPDFs, slides and spreadsheets are converted with Docling and chunked along their own structure. Image-heavy pages are embedded as images as well as text.
  • Isolation in the data layerEvery query is scoped to a workspace by the repository it goes through, and a request without a valid workspace stops at the middleware. Every endpoint inherits it from that one layer.
  • Agents that stop and resumeRetrieved text is checked for injected instructions before an agent acts on it, every run has hard stop conditions, and conversations checkpoint to PostgreSQL so a restart resumes them.

Where it stands

22sto8 to 10s

Time to first token, before and after parallel retrieval

More on running marketing agents in production:Multi-agent LLM middleware: lessons from Obelisk

Obelisk at a glance

Industry
Marketing
Who it is for
Marketing teams working from their own documents and analytics, through one assistant
Our role
Retrieval pipeline and agent runtime
Stack
FastAPI, LangGraph, Vertex AI, Gemini Flash, PostgreSQL, Redis, Google Cloud

RISQ

Fraud scoring for legal intake. RISQ listens to each call a mass tort law firm takes from a potential claimant, scores it for authenticity and recommends a disposition: transfer to a closer, flag for review, or quarantine.

The problem

A significant share of mass tort intake calls are fraudulent. Some callers are coached and read from a script, some never used the drug or product in question, and some call again under different names.

What we built

  • The caller's words, separated outAssemblyAI transcribes each call and separates the speakers, so the caller's answers are scored apart from the intake agent's questions.
  • Claims extracted and checked against registriesClaude Sonnet pulls structured claims from the transcript, each tagged with a confidence level, and flags language that reads as coached. Named doctors are checked against the NPI Registry and named facilities against the CMS database.
  • Photo proof, verifiedWhere a campaign asks for proof, RISQ texts the caller, receives the photo through Twilio or Telnyx webhooks and has Gemini Vision check that it shows what the caller claims.
  • A chain of gates before any dispositionCampaign rules can disqualify a call outright. A weak intake session sends the call back for re-screening, hard thresholds on integrity and qualification come next, and callers who hit every checklist item with no genuine recall are caught as coached. Only then does the composite score choose the outcome.
  • Campaign rules as configurationRequired questions, disqualifying answers, indicator weights, verification sources and thresholds are set per campaign. The legal team writes them, and a new campaign launches with no code change.

How the scoring and the gates work, in more depth:Scoring fraud in legal intake calls

RISQ at a glance

Industry
Legal intake
Who it is for
US mass tort law firms
Our role
Scoring pipeline and disposition logic
Stack
Python, AssemblyAI, Claude Sonnet, Gemini Vision, Twilio, Telnyx

Anatomia

A care workflow for a healthcare provider. Nurses call patients back, review the case and escalate to a doctor when they need to.

The problem

Every step handles patient data, and products like this are judged on trust long before polish.

What we built

  • Patient data protected from the first tableEncryption, access control, audit logging and retention were part of the first schema. Transcripts and recordings are treated as sensitive by default.
  • A case that moves in stagesNurse review, doctor review, waiting and done. A handoff keeps the assignment and the patient's context, so the doctor picks up where the nurse left off.
  • Transcripts scored for urgencyCalls are transcribed and analysed, and each gets an urgency score, so the case that cannot wait is read first.
  • Voice follow-up tied to the recordAn outbound voice assistant calls the patient back and writes what it hears to the same case the nurse is working.

Anatomia at a glance

Industry
Healthcare
Who it is for
A healthcare provider's nurses and doctors
Our role
The care workflow, its data layer and the voice follow-up
Stack
FastAPI, React, PostgreSQL, AWS Cognito, S3 and KMS, Redis, OpenAI, Vapi

Bonnet.ai

Bonnet.ai is a venture we co-own and build. A brand development platform: a creative brief goes in, and research, strategy, creative direction and moodboards come out as one document.

The problem

The model call was the easy part. A run takes minutes, so it had to stay readable while it ran and easy to stop.

What we built

  • A run you can watchEach step's state lives on the server and streams to the browser over websockets, so a run that takes minutes shows which step it is on.
  • Cancel or rerun one stepA weak strategy section is rerun on its own. The research before it stays, and nobody starts the brief over.
  • Retrieval over real case studiesA targeted vector lookup over case study material, so the strategy draws on comparable work.
  • One project, one exportText and assets hang off the same project record, so the PDF says what the screen says.

Bonnet.ai at a glance

Ownership
Co-owned venture
Industry
Brand and creative
Who it is for
Creative and brand teams
Our role
Co-owner; we design and build the platform
Stack
Next.js, React, Django, Channels, PostgreSQL, OpenRouter, Supabase

Check it yourself

  1. A call with someone already running it

    We ask the customer first. If they agree, you get a number and a time, and nobody from our side sits on the call.

  2. The live system, on a screen share

    A screen share of Polaris on a demo dataset shaped like a real shop. You pick the questions and we type them in front of you, in Urdu or in English.

Tell us what your evenings are spent fixing.

We look at how the work moves through your business now and say where the time goes. Ask for the reference call or the screen share and we will set it up.

Book a call
First reply
same working day
Hours
Set to your time zone
Built in
Lahore, Pakistan
WhatsApp+92 335-0706014