An architecture studio building its own software, with AI

Since May of this year, we have been building our own business system in-house. Apps for the everyday work of a design office — envelope performance calculation sheets, duct pressure-loss calculations, and so on — have grown to 28 in 141 days. Five people use it: our own studio and a partner company together.

This is a record of what I presented at a study group session on 19 September. Every number is a measured value as of that date.

What is running now

We call it monosashi. It is used only by our studio and our partner company; we do not offer it outside.

• Calculation — envelope performance sheets / Detail&Calc / structural calculation / duct pressure loss
• Drawings and information — foundation detail drawings / modeler / drawing list / drawing master management / MaterialPedia / spec database
• Money — estimates / accounting / ledger of expenses paid on behalf of clients / outsourcing management
• Site and progress — schedules / construction photos / client requests / work manuals
• Communication — Inbox / Mail / LINE / chat documents / shared-link ledger
• Other — document merge / Freeboard / our own website / Warehouse / system administration

The "structural calculation" in that list produces a pair-check report that cross-checks an existing calculation. It does not produce the structural calculation document submitted with a building permit application (in Japan, kakunin shinsei, the code-compliance review before construction). All judgments come from formulas; the AI returns only the wording of the observations.

The scale: 141 days from 1 May, 113 of them with hands on the keyboard, 2,440 commits, 341,135 lines of TypeScript. Built by one person from a design office.

These 28 were not there from the start. On day one there were only three: a project list, a materials database, and an input box for the AI. Within a month there were 11, and after that one to three a month. They were not planned; each was added after something became a problem.

Who knows what should be built

Slide from the session (in Japanese): left, "people who can build software"; right, "people doing architecture". The last line on the right reads "until now, they could not build."

People who can build software have the skill to build. But which part of a UA-value calculation (the envelope's average heat transmission coefficient) is tedious, which part of the structural input should be automated, what you actually judge by in ventilation and air conditioning — none of that is visible from outside. People doing architecture know it, but until now they could not build.

What is happening now, I think, is not that programmers got faster with AI, but that specialists can now build the software their own work needs. What matters is not the AI's ability to answer, but being able to fix the calculation logic, the data, the screens, and the way you verify them, with your own hands.

What to build with, and where to start

To be clear up front, I chose almost nothing. The foundation — TypeScript, Next.js 16, React 19, Tailwind CSS 4, ESLint 9 — was all installed at the outset by a command called create-next-app. I have never once created a Tailwind config file (Tailwind 4 is built to have none). There are 48 external packages, but I decided on only two of them myself: Supabase and Vercel. There is less to decide at the beginning than you would think.

Slide from the session (in Japanese): the dashed box on the left is what create-next-app installed; the solid box on the right is the only two I decided on. The line below reads "there is less to decide at the beginning than you would think."

We rely on three services.

1. GitHub — where what you write lives (the code, and the history of changes)
2. Vercel — publishes it and runs it
3. Supabase — holds the data (data, login, files)

The three need almost no wiring between them.

Slide from the session (in Japanese): GitHub holds the code, Vercel publishes and runs it, Supabase holds the data.

Several companies can share one database safely because of Supabase's per-row lock (Row Level Security). Every row carries which company it belongs to, and it is the database, not the screen, that refuses access.

From nothing to the first screen is the same six steps for anyone.

1. Create three accounts (GitHub / Vercel / Supabase)
2. Install Node.js locally (just install it from the official site)
3. Generate the scaffold (one command line)
4. Put it on GitHub (history starts here)
5. Connect it to Vercel (just pick the repository)
6. Hand over the Supabase keys (two environment variables)

Slide from the session (in Japanese): the same six steps listed above, as shown in the session.

At that point a screen appears at your own URL. After that, a push automatically runs the checks and the build, and it is live in two or three minutes.

What it costs

Item	Cost	Notes
GitHub	¥0	Unlimited private repositories
Vercel Pro	$20/month	Publishes and runs it. Viewer seats are unlimited and free
Supabase Pro	$25/month	Data, login, files. Billed per organization
Foundation (fixed)	$45/month	Does not change as people are added
AI usage	about $70/month	Pay as used. About 1,800 calls in the last 30 days
Total	about $115/month	At ¥156.26 to the dollar (2026-09-18), roughly ¥18,000 a month

The three foundation items are fixed and do not change as people are added. The only thing that grows is AI usage. Even adding tax and the custom domain (a .space at ¥3,958 a year), the ceiling for the foundation was roughly ¥8,100 a month.

Free plans cannot be used for business. Vercel's Hobby plan is officially non-commercial only, and Supabase's Free plan pauses after seven days without use.

kintone (a Japanese no-code business app platform) charges ¥1,800 per user per month (before tax) on its Standard plan, with a minimum of 10 users, so for our five people that is ¥18,000 a month (checked on the official pricing page on 19 September 2026). The price is almost the same, and whether AI is available is not a difference either. Two things did differ: the foundation cost does not change as people are added, and we can build specialist calculations such as structural and envelope performance ourselves. We did not build it because it was cheaper.

How to ask the AI

It is the same as handing a manual to a new hire. These four points are what I say out loud every time.

• Intent — why it is needed (e.g. estimates cannot be called up per project)
• Expected behavior — what counts as success (e.g. selecting a project shows the past estimates, which can be copied and edited)
• Definition of done — what state means finished (e.g. ☐ Project A's estimate appears in Project A's estimate tab ☐ existing data is not changed)
• What must not be done (e.g. do not rewrite existing documents)

When it goes wrong, one of these four is usually missing. The one that works best is the definition of done. With it, the AI checks for itself before saying it is finished.

Some things are written once and left in place. CLAUDE.md at 855 lines, SYSTEM_CONTEXT.md at 473 lines, 85 documents under docs. The AI cannot hold a long conversation in memory, so I have it read these again every time. It once swelled to 2,187 lines and could no longer be read through, so I cut it back to 855 lines. It is the same as people not reading a manual that is too thick.

The formulas do the calculating, not the AI

The biggest difference from ordinary AI use is that we do not ask the AI directly.

Where you ask	Where the answer comes from	Same input, same answer?
Ask the AI directly	The AI makes it on the spot	Different every time
Ask the AI embedded in the software	The software's formulas, tables, and standards	The same every time

Slide from the session (in Japanese): left, what the formulas produce (zero AI calls on the calculation path); right, where the AI sits — only at the entrance and the exit.

98% of the code is written by AI (442,897 lines came in under AI-authored commits, 8,144 lines did not; what is counted is who committed, not who typed). That is exactly why what the AI writes is never taken as the deliverable as it stands. Every calculation is fixed in formulas and verified by 1,863 tests before use. Structure (net section loss, horizontal diaphragms, mat foundation FEM), the envelope's UA value and ηAC value (Japan's envelope metrics for heat loss and for summer solar gain — even the rounding prescribed by the ministerial notice is a constant), assembly U-values for insulation, duct pressure loss, estimate and invoice amounts and consumption tax. In none of these calculation paths is there a single AI call, or a single random number. The remaining 1.8% is also code whose author record was lost for reasons of history — not evidence that it was written by hand.

I tried to break it and it did not break. For the mat foundation FEM, the 11.2MB result file matches byte for byte even when run in a separate process and with the settings changed. For the envelope's UA and ηAC values, 70,000 reorderings gave zero divergences, and for the structural demand-capacity ratios and OK/NG judgments, 63 configurations across 120 cases gave zero differences.

That said, it is not always identical. There are three places where it breaks down. (1) Across browsers, only the coordinates of "where the maximum occurred" in the structural report change (the demand-capacity ratio and the pass/fail do not). (2) If you correct a λ in the material master, insulation U-values whose revision is not pinned move simply by reopening them. (3) A document's issue date and number are decided by the moment the button is pressed, so they never match in the first place.

The AI is only at the entrance and the exit. The entrance is transcribing numbers off paper; the exit is writing the observations. The AI assistant is given 34 tools covering 16 apps, and all of them are read-only. The pair-check AI returns prose only; its return value has no numeric field. So the demand-capacity ratio, the allowable value, and the OK/NG judgment are all beyond the AI's reach.

Reports that use the AI's assessment are printed with "rule check + AI assessment" on the first page, and each point raised is labeled "AI assessment."

There are 27 actions that change content when requested from the screen, and every one of them goes through an approval screen. Only three are committed without human approval: automatic sorting of email, automatic sorting of LINE messages, and expenses paid on behalf of a client once the amounts have passed a cross-check. Numbers for drawings, structure, envelope, and invoices do not go in unless a person approves them.

We open five ways in for the AI: (1) identify itself, (2) guide, (3) read contents, (4) propose changes, (5) know what is being looked at. (1) and (2) are running; (3), (4), and (5) are still partial. AI calls came to about 1,800 in 30 days, of which 85 were people speaking to the assistant.

How far does this go

Slide from the session (in Japanese): six stages, bottom to top. The red dashed line sits between stage 2 and stage 3, where the real distance is.

1. Use AI
2. Have AI write code
3. Build an app for your own use, together with AI
4. Actually deploy it as a web app
5. Build in database, authentication, APIs, and AI, and keep it running
6. Turn your own specialist work into an app and change daily practice

There is still a distance between (2) and (3). Merely giving something a shape has become incomparably easier than a few years ago. What trips you up is what comes after: how to hold the data, login, publishing, domains, backups, version management, dealing with defects. I stalled here many times myself.

On that score, web apps feel well suited to this path. No app-store review, usable by just opening a URL, running on PC, Mac, iPad, or phone, and a fix reaches everyone on the spot.

In a few years it may well feel like making your own calculation sheet in Excel, but it is not there yet.

Incidentally, this article too was written in Markdown and published as it is. I still have the slides from the study group session, so please get in touch if you are interested.