Notes from a domain software studio
We’ve been running this studio with our heads down for a while — shipping MeterSnap into UAE district-cooling operations, building Seatroom into a real multi-tenant facility platform, and watching what AI-assisted engineering actually looks like inside a small team that has to make money this quarter.
This is where we’ll write about that.
What you’ll find here
Three kinds of posts, mostly:
- Domain notes — what we’ve learned about a specific industry vertical that you’d otherwise have to spend years inside to discover. District-cooling tariffs. SCADA quirks. Why facility operators run on WhatsApp and Excel and what that means for software design.
- Build notes — how we ship. Stack decisions, the bits of infrastructure we lean on, AI-leverage patterns that worked for us and ones that didn’t.
- Field notes — short observations from inside customer deployments. The thing the spec missed. The reason a feature gets built or pulled.
We’ll keep them short. The bar is: it teaches the reader something they couldn’t easily Google.
A small example
Here’s a snippet from the bill-intelligence pipeline that ground-truths every district-cooling bill against a meter reading:
type BillExtraction = {
customerId: string;
meterId: string;
periodStart: string; // ISO date
periodEnd: string; // ISO date
consumptionRTH: number; // refrigeration ton hours
baseTariff: number; // AED / RTH
totalAED: number;
auditFlags: AuditFlag[];
};
type AuditFlag =
| { kind: "tariff-mismatch"; expected: number; actual: number }
| { kind: "consumption-spike"; sigma: number }
| { kind: "missing-meter-read"; daysSince: number };Twenty audit checks run on top of this, and the audit flags drive the entire reviewer UI. The interesting part isn’t the schema — it’s that the schema took eleven iterations with real bills before it stopped surprising us.
Subscribe
There’s an RSS feed for readers, and the blog index lives at /blog. We don’t run a newsletter (yet); the feed is the canonical way to follow along.
More soon.