Ancor OS

The operating system for creative and marketing agencies

Role

Founder, product, every line of code

When

March 2026 to now

Status

Live at getancor.com, two agencies in trial

Built with

React, Node, PostgreSQL, Stripe, Gemini agents, Capacitor, Google Cloud

Why it exists

Every agency I worked in ran on the same stack: a project tool nobody updated, timesheets nobody trusted, capacity in a spreadsheet, client approvals in WhatsApp, and a margin view that arrived from the accountant three weeks late. People burned out quietly and resigned loudly. The tools on the market were built for software teams and bent to fit agencies. None of them understood retainers, revisions, or who signs off.

What it does

• Capacity and allocation. Who is on what, at what percentage, for how long, against what the client is paying for. Overload shows up before it costs anyone a weekend.
• Client approvals. The deliverable goes to the client in a portal with structured feedback, change requests, and a record of who approved what and when.
• Money. Billing, cash forecasting, receivables, and margin per client, live.
• Agents that do work. A director agent and a sales agent with tool access over the agency's own data. They staff, summarise, nudge, and write the Monday digest. No chat box.
• Burnout signals computed from hours, allocation, and deadlines, sent to the lead early enough to matter.
• Gmail, Slack, Buffer, Calendly, Zapier, and Stripe, plus an Android app for the day-to-day.

Selling it

A self-serve demo tenant, a sales playbook, and a content pipeline, all run by me. Two agencies are in live trial and both are in paid-pilot conversations. I know who the buyer is because I was the buyer for seven years, and that is the part of the job I want to do more of.

Running it in production

• Tenant separation enforced in shared SQL predicates, so demo and retired tenants never leak into a cross-agency job, digest, or nudge.
• A deploy gate that reads the list of agencies on trial or paid plans and checks every release against it.
• AI spend tracked per feature, so the margin on each tenant is a number, not a guess.
• Integration, end-to-end, and load tests on a seeded demo tenant. A security module, policy violation reporting, data retention, and secrets in a vault.

Maître

A restaurant operating system that keeps serving when the internet drops

Role

Architect and engineer, scoped with the owner

When

Eight weeks, 2026

Customer

A restaurant and bar in Anjuna, Goa

Status

Complete through week eight. The customer's funding paused before go-live

The problem

Indian restaurants run on three or four disconnected tools, and the market leader still goes dark when the Wi-Fi does. A bar in Goa has a second problem that nobody serves: food is billed under GST and liquor under Goa VAT, on separate invoice series, with an excise register to maintain. I scoped it with the owner, priced the competition from their own pages, wrote the week-zero checklist of long-lead dependencies, and built the data templates for menu, recipes, stock, suppliers and staff.

The decision that shaped everything

One server image, two runtimes. The same code runs as the cloud and as a hub, a fanless mini PC in the restaurant with its own database. Every device in the room talks to the hub, so there is one code path whether the internet is up or not. The hub builds itself from the cloud on first start, and a replacement hub restores the same way. I rejected a phones-only offline design because phones cannot see each other's orders offline, and gap-free invoice numbers need a single writer. The reasoning lives in an architecture decision record so the next engineer does not reopen it.

What was hard

• Sync without conflicts. Every table is owned by the hub or by the cloud. Business rows and outbox rows commit together. Pushes carry idempotency keys, pulls read a sequenced change log, order items are append-only, and ledgers are checksummed hourly and at day close.
• Gap-free invoice numbers offline. Series rows are locked per transaction, with separate series for food under GST, liquor under VAT, and credit notes. A finalised invoice is immutable at the database level. An edit becomes a credit note.
• Money that cannot drift. Integer paise, basis-point tax rates, and all arithmetic in a pure domain package covering tax, splits, bar pegs by pour size, recipes, payroll, and tips.
• Printing from a browser. The hub drives thermal printers over raw TCP with a spooler, retries, a backup printer, and snapshot-tested ticket templates.
• Bookings as an agent with a human gate. WhatsApp messages hit a webhook, the agent drafts a reply, and anything that commits a table waits in an approval queue.

Kaan

A laptop that listens to a room, knows who is talking, and speaks only when it has a reason to

Role

Designed, built, and operated it

When

Two days to build. One live run, 4 November 2026

Built with

Python, Whisper on a GPU, speaker embeddings, Gemini, phones as extra microphones

Constraint

Audio never written to disk

What it did

Eight friends, one table, one laptop. Speaker embeddings taken at the door, Hinglish transcription on the GPU, a set of instant rules, and a language model that rated each moment from one to five and was allowed to put a line on the screen only at four or five. Every utterance, model call, rule, and line went into a journal. The morning after, the journal became a report.

What I wrote down afterwards

• One laptop microphone cannot hear a table. Five of six triggers were noise. Attribution was 19 percent with one speaker near the mic and 2 to 4 percent once the room filled. Everything downstream was bounded by this.
• Memory built for callbacks caused repetition. The model re-read its own note and rated the same joke highly every 45 seconds for 23 minutes. The fix is a cooldown per person and treating a note as already said.
• A blank auth token got cached after a Wi-Fi drop and killed a third of the calls. Never cache a blank. Refresh on failure.
• The system heard itself. Whisper echoed its own vocabulary prompt on chip noise and the rule engine believed it.
• The remarks followed the voiceprints, not the behaviour. The two people with the best door samples got nearly all the attention. Fairness was a microphone problem before it was a model problem.

I include this one because the failure report is the most useful thing I made that week. Build fast, run it with real people, measure honestly, write down why it broke.

Seven years in agencies

From junior brand partner to director, on enterprise accounts, before I started building