True Build Design · Dubai

True Build OS

How a small interior design studio built its own operating system with AI, what it does today, and what building it taught us.

951 commits
78% co-authored with Claude
v1.9.2.0 in production
1 founder writing the code

Written to be read on its own, in about ten minutes. Scroll, or use the arrow keys.

The studio

A design studio runs on information.

True Build Design is a boutique interior design studio in Dubai working on villas, apartments and offices from concept to handover. What clients buy is judgement. What the studio moves all day is information: a dimension, a sample, a price, a client’s yes.

Stage 1Concept Design
Stage 2Detailed Design
Stage 3Procurement Coordination
Stage 4Site Coordination
Stage 5Styling & Handover

Client ↔ Studio

Briefs, selections, approvals, changes of mind.

Studio ↔ Vendors

Drawings, dimensions, samples, quotes, revisions.

Vendors ↔ Site

Deliveries, installation, access, sequencing.

Site ↔ Studio

Progress, photos, snags, questions that need an answer today.

Almost all of it travels over WhatsApp: voice notes, photos and half-sentences, in English and Urdu, across two phone numbers and about twenty project groups.

The problem

The decision that never became a record.

Illustrative sequence

DAY 0
In a voice note, the client asks for the cabinet 450 deep, not 420. The designer agrees in the group.
DAY 9
The joinery vendor prices from the drawing he already has. It still says 420.
DAY 38
The cabinet arrives at 420. Everyone acted reasonably, and nobody can point to where the decision lives.

What we found when we checked our own groups · 30 Oct 2026

9

client decisions in recent weeks with no record in the system

12

dimension exchanges with vendors, also unrecorded

Vendors were pricing from chat threads, and chasing was the most common kind of message. The software existed. The information was not reaching it.

What it is

The studio’s system of record.

One place where a project’s decisions, documents, samples, vendors and money live, with a view for each person who works on it. AI turns raw input into drafts. A person turns drafts into records.

Comes in from

WhatsApp and Telegram
Voice recordings from site
Email
Web forms and QR site capture
Contracts and drawings

Held as records

Projects and stages
Site reports, minutes, RFIs
Decisions and approvals
Action items
Issues, snags, NCRs
FF&E and sample library
Vendors and submissions
Budgets, POs, expenses
Timesheets
Zoho Books sync

Drafted by AI, accepted by a person.

Seen through

Studio back office
Client portal
Vendor portal
Consultant portal
Accountant portal
Single-use links for approvals and sign-offs

One Rails application and one Postgres database, with the public website in the same codebase. Clients and vendors never set a password: they sign in from an emailed link, or act on a link that opens exactly one thing.

What it does

Follow one item through the system.

On site
The designer records a site walk, or sends a voice note to the studio’s Telegram bot.
Drafted
It is transcribed and drafted into a site report: decisions with the words they came from, new action items, updates to open ones.
Reviewed
A person edits and approves. The approved version is kept, and the next draft of that kind is written in the studio’s own style.
Approved
Anything that needs the client’s yes goes as a link. No login. What they approve is frozen exactly as they saw it.
Delivered
The vendor sees the item in their portal. Invoices and costs sync from Zoho Books into the project’s money view.

A composite of how items move on live projects

Where AI sits

AI drafts. A person decides.

Job	Model	Who signs it off
Voice notes into text	Voxtral Small	The person filing it
Transcripts into site reports, minutes and RFIs, with action items	GLM 5.2	The studio approves each document
Receipts and scanned documents into structured fields	Qwen3-VL	Staff confirm the expense
Reading drawings for review comments	Qwen3-VL 235B	The designer
Severity and task type for issues and actions	GLM 4.7 Flash	Anyone can reclassify
A prep sheet before a paid consultation	GLM 5.2	Read by the founders, never sent
Taking in vendor submissions (agent)	Claude Sonnet 4.6, falling back to GLM 5.2	A person approves each one

Nothing AI-created is live until a person accepts it.

There is one narrow exception, on the next sheet.

TBOS was built with Claude, but in production it runs mostly on open-weight models through OpenRouter, picked per job for cost and quality. Twenty-eight AI tasks are mapped to models in one file and can be retuned without a deploy.

An agent in production

A coordinator agent, on a short lead.

Since 26 September 2026 a Project Coordinator agent has worked on two live projects. It has three duties, and a different degree of freedom for each.

Duty	Project	How it acts
Files incoming records against the right project and items	Pilot A	Acts, then reports. Only reversible changes, only above 0.85 confidence, undo available for seven days.
Answers vendors and the client asking what is waiting on them	Pilot B	Drafts the reply. A person approves every message.
Takes in vendor submissions	Pilot B	Proposes the record. A person approves it.

Daily digest
Everything it did on its own arrives at 07:30 Dubai time, each with an undo link.
One switch
A single setting stops the agent. Runs for any duty not configured for a project are refused.
Tested first
Before go-live it ran ten real filing cases from the first pilot project. Both models scored 7 of 10, and neither score meant what it seemed. Sheet 13 explains why.

“Sent by True Build’s Project Coordinator Agent, an automated coordination system working under the supervision of the project’s team. A member of the studio reviews every message before it is sent; reply to this email to reach a real person.”

By the numbers

What exists, and what it is used for.

Built

From the repository · Apr to Nov 2026

951

commits over 109 working days

517

merged pull requests

318

versioned releases

~132k

lines of application code

~7,000

automated tests

149

database tables

28

AI tasks in production

34

tools AI assistants can call

Used

From production · 3 Nov 2026

7

client projects run in the system

377

project records, 374 of them drafted by AI

43

of those formally approved so far. Review is still the bottleneck.

1,514

action items, 742 extracted from records automatically

168

issues and snags logged, 4 raised as NCRs

254

inbound emails read and filed

55

agent runs since 26 Sep. 5 changes made on its own, none undone.

5,410

events in the project history, each one a change someone or something made

How it was built

One founder, nine models.

Tariq built TBOS alongside running the studio. Every one of the 951 commits is his, and 741 of them (78%) were co-authored with Claude. The model underneath changed nine times along the way.

Commits per month, with the Claude model most often credited as co-author. October went to a full audit and a new plan rather than new code.

The model was replaceable. The project’s memory was not.

What kept the work coherent across nine models was the repository itself: a house-rules file every session reads first, written plans for each piece of work, and a changelog entry for every release.

The workflow

Specs before code. Review before merge.

Founder + AI
Office hours
What problem, for whom, and why now.
Founder review
Scope
What is in, and what waits.
Engineering review
Design
Data model, failure modes, tests.
Agents
Build
Several sessions in parallel, each in its own copy of the code.
Separate agent
Adversarial review
A fresh session tries to break it.
Founder
Staging
Deployed and checked by eye.
Founder
Production
Only after staging passes.

Claude Code does the building. Gstack turns the planning steps into commands, so every piece of work starts from the same questions. Conductor runs parallel sessions side by side.

Plane holds the tickets, and a ticket is done only when it has been seen working in production. Sessions can be watched and approved from an iPad, so building does not need a desk.

The real constraint

The bottleneck was never writing the code. It was reviewing it.

A 15,800-line money module, designed and approved, waited six weeks for review.
In July the ticket board stalled for 16 days, because every ticket in flight needed the founder.
In August, three parallel build tracks left two pull requests stranded.

Lane A

One item at a time. It starts only when its scope is approved and leaves only when it has been reviewed on staging.

Lane B

Fixes and housekeeping ship on their own, through tests and staging, with no founder review.

Founder lane

Work only the founders can do, listed openly so its cost to everything else is visible.

With review as the gate, six queued items reached production in three days.

24 to 26 September 2026, including the money module and the coordinator agent.

A second agent

Arqis, the founder’s own assistant.

Arqis today

Runs on a Mac Studio, reachable only over a private network.
Reads Tariq’s WhatsApp through a self-built bridge. Anything it sends passes nine checks first.
About 50 tools into TBOS, 36 into Zoho Books, plus Plane, Google, GitHub and the voice recorder.
Knows who it is talking to: Admin, Trusted Colleague, Known, Stranger.
Keeps a ranked plate of what needs Tariq, and sends four briefs a day.

What it taught us

Conversation is the easiest way in. Say it messily, let the agent ask for the one thing missing, confirm a draft. It became the most-used way to put things into the system.
Doing is easier than deciding. Its own review found the execution works and the judgement about what matters most stalled.
One agent cannot serve a person and a studio. Identities, permissions and trust get mixed.

Decision: Arqis stays Tariq’s personal assistant. The studio gets its own agent, forked from Arqis, with its own number, its own database and rules taken from studio doctrine, running on studio servers rather than the Mac Studio.

What went wrong · the AI

Four failures, and none of them raised an error.

25–26 SEP 2026 · EVALS

The model comparison that measured the plumbing.

Before go-live we tested a cheap open-weight model against Claude on twelve cases. Both scored zero. The Claude calls were being routed to a Google-hosted copy of the model, which enforces stricter rules on tool definitions and reports only one broken rule at a time. Four rounds of fixes later, it hit a limit of 50 optional parameters that needs a redesign.

A rejected call now falls back to the default model, and the agent’s single large tool is being split by duty.

26 SEP 2026 · EVALS

The test that passed for the wrong reasons.

The scorer counted a placeholder answer key as a match, and a model that did nothing scored the same as one that correctly found nothing to do. That is how a model whose every call was rejected scored 7 out of 10. The answer key itself had been drafted by AI.

The scoring bugs were fixed. A separate check for “should have acted but didn’t” is open work.

JUN–SEP 2026 · RECORDS

Two hours of meeting became two pages.

Output was capped at 8,192 tokens, so a 94,424-character meeting transcript came back as 6,658 characters, with no warning. Pasted inputs lost 82% on average. Worse, a revision that came back empty overwrote a live record, and its fix sat on an unmerged branch from June to September, 387 commits behind.

Larger output budgets, a truncation check, and a guard that refuses to replace text with nothing.

AUG 2026 · CLASSIFIER

One AI’s notes were too tidy for another AI.

The assistant writes even raw site notes as neat, numbered prose. The classifier that decides “raw transcript or finished document” read that neatness as finished, and parked the records with no retry and no error. A stronger model still flipped its answer between runs.

A plain rule decides when the text has no document structure. The model is asked only when it is genuinely ambiguous.

The common thread: each of these looked like success until someone counted.

What went wrong · around the AI

The model was rarely the weak point.

17 JUL 2026 · PROVIDERS

The credits ran out, and the product went dark.

Every AI task ran on one provider’s API. When the account ran out of credit, drawing review, extraction, transcription and the assistants all stopped at once. About 21 call sites moved to open-weight models through one router in a day, which is why production runs mostly on them today. The same week we found the embeddings provider had been out of quota for two weeks, silently.

One router, one billing account, and a model chosen per task.

AUG 2026 · ADOPTION

Built as a forms app, used as an AI pipeline.

By August, 93% of records were filed by machines and four had a human author. A full RFI module had produced zero RFIs. AI extraction created work faster than anyone could triage it: one meeting produced 46 action items, 41% of 899 were later cancelled, 214 of them in a single day, and 73% of suggested next steps were rejected.

The interface was rebuilt around triage, chasing, a typed records library and a project timeline.

AUG 2026 · CHASING

An AI label decided who got chased.

Chase emails went out only for certain AI-assigned task types. A contractor 17 days overdue on as-built drawings was never chased, because the model had reasonably called that task “admin.” Widening the rule in a dry run showed the opposite problem: one contractor would have received eight identical overdue emails in the same minute.

Who owns the work decides who is chased, and each contractor gets one digest per sweep.

JUL–SEP 2026 · ARCHITECTURE

The agent framework we built and threw away.

In July we built a separate Python agent harness with 56 tests. The agent’s first real job, chasing contractors, shipped in August as plain Rails without any of it. A September review retired the harness, and found its design notes cited figures such as a “71% median gain” that traced back to no source.

The agent loop moved into the main app, and its duties were cut from nine to three.

The common thread: the routing, the scoring, the limits and the interface around the model failed more often than the model did.

Rules we now hold

Six rules, each paid for.

Records are the truth.
Chat is where work arrives. A record is where it lives.
AI drafts, a person accepts.
Written into the data as a state, so it does not depend on anyone remembering.
Merge before you add.
Adding is cheap now, so removing duplication has to be deliberate.
One item in review at a time.
A stalled review shows up as a stalled roadmap, never as a forgotten pull request.
Tests before autonomy.
An agent earns each permission on real cases from our own projects.
Doctrine lives in the repository.
Voice, design rules and commercial terms are versioned documents approved by their owner, and compiled into prompts and templates.

What is next

Closing the gap between the chat and the record.

Phase 0 · 2 weeks · now

Stabilise

The test suite builds the database from empty
A studio WhatsApp number joins every project group
Nothing business-critical left on the Mac Studio

Phase 1 · 4 to 5 weeks

Landing and transmittals

Every inbound message becomes a proposed record: a decision, a dimension, a comment, a request for quote, a payment. Accept or dismiss in one tap.
One decisions table instead of five.
Concept sheets issued with a transmittal, so nothing a vendor prices from leaves the studio without a reference and a revision.

Then · to March 2027

The design spine

Brief, direction and design package as records
FF&E schedule revisions
The studio’s own agent

The test for Phase 1: on two live projects for two weeks, every client decision and every dimension given to a vendor is a record within a day.

The cabinet on sheet 03 is the case it exists to prevent.

For anyone building with AI

Four things we would tell you.

Plan around review.
Writing code is no longer the scarce part. Judgement, review time and a clean data model are.
Keep the memory in the repository.
Models change every few weeks. Plans, decisions and house rules written into files are what carry the work across them.
Make “a person accepts” a rule in the code.
Drafts are where AI is strongest. Acceptance is where accountability lives.
Subtract on purpose.
When adding is cheap, a system grows sideways. Merge before you build.

True Build Design · truebuild.aeos.truebuild.ae

True Build OS

A design studio runs on information.

The decision that never became a record.

The studio’s system of record.

Comes in from

Held as records

Seen through

Follow one item through the system.

On site

Drafted

Reviewed

Approved

Delivered

AI drafts. A person decides.

A coordinator agent, on a short lead.

Daily digest

One switch

Tested first

What exists, and what it is used for.

Built

Used

One founder, nine models.

Specs before code. Review before merge.

Office hours

Scope

Design

Build

Adversarial review

Staging

Production

The bottleneck was never writing the code. It was reviewing it.

Arqis, the founder’s own assistant.

Four failures, and none of them raised an error.

The model comparison that measured the plumbing.

The test that passed for the wrong reasons.

Two hours of meeting became two pages.

One AI’s notes were too tidy for another AI.

The model was rarely the weak point.

The credits ran out, and the product went dark.

Built as a forms app, used as an AI pipeline.

An AI label decided who got chased.

The agent framework we built and threw away.

Six rules, each paid for.

Records are the truth.

AI drafts, a person accepts.

Merge before you add.

One item in review at a time.

Tests before autonomy.

Doctrine lives in the repository.

Closing the gap between the chat and the record.

Stabilise

Landing and transmittals

The design spine

Four things we would tell you.

Plan around review.

Keep the memory in the repository.

Make “a person accepts” a rule in the code.

Subtract on purpose.