Nano

Turning five people into a hundred

A workspace that lets a small team operate like an organization of hundreds, using LLMs to cut through the bottlenecks that slow traditional systems down.

Nano Operations: a chat channel where an agent turns a signed customer into an onboarding plan, with the customer record alongside — Operations. A signed customer becomes an onboarding plan: tasks, a booked kickoff and a drafted email, all linked to the customer record.

The Northfield Clinics customer record in Nano: one timeline with the call and its transcript, a portal request, a finished task, a scheduled invoice, emails and the signed contract — The customer record. Calls, requests, tasks, invoices and email land on one timeline, so the deal is already the invoice.

The customer portal Northfield sees: their setup steps, booking time with their account lead, their requests, invoices and help center — What the customer sees. The portal is a view onto the same data, so Dana's request is already on the team's plan.

Search in Nano: a question about front-desk training answered from five sources across calls, email, chat and customer requests — Search across everything the organization knows. One question, answered from calls, email, chat and requests, with sources.

The problem

Do large language models let a team of five operate like a team of a few hundred?

It would be foolish not to take the question seriously. If the answer is no, it's worth knowing exactly why not. If it's yes, the interesting part is how. Nano is my attempt at the how.

What I built

Nano has two faces and a hinge between them.

Inside: Operations. The team and its LLMs work in the same apps: chat, email, CRM, tasks, calendar, calls with transcripts, docs and decks, search, prospecting, research, billing, customer success and delivery. The LLMs act in those apps, on the same data, rather than beside them.
Outside: the overlay. What customers and visitors meet: booking pages, guest calls, a help center, support and feature requests, marketing and lead capture, a customer portal and public docs.
The hinge: management. Scheduling links, a customer console and admin decide what the outside sees. The external overlay is a view onto the same data the team works in, so nothing is copied between an internal tool and a customer-facing one.

How it works

Everything runs on one platform: hybrid search over everything the organization knows, an event queue that workers act on, mail in and out, LiveKit for calls, Stripe for billing, and Postgres with vectors. The inside, the outside and the hinge are all views onto that one set of data.

The highlighted path follows a customer request from the portal onto the team's plan.

What was hard

Recognizing the cost in the first place. Handoffs don't show up as a line item; they show up as a week that felt busy and moved nothing, a customer who had to explain themselves twice, a decision nobody can find. Most organizations never measure them, so they never remove them.

The engineering is the easier part. The harder part is looking at how work actually moves, naming each handoff out loud, and asking whether a shared system could make it disappear.

What I learned

Nano teams are the way. LLMs have made building so much easier that I expect a new wave of companies to start like this: a few people on one shared system, doing work that used to take hundreds. I think this way of organizing will spread with them.