alidoes.ai

All writing

Build log

I Built Property Management Software With AI. The Prompts Were the Easy Part.

We bought a four-unit building, and AI helped turn plain-English requests into 918TS — a live property portal with resident, manager, and owner views. The prompts were the easy part; the permissions, tests, and maintenance were the real work.

Key findings

  • AI turned plain-English requests into 918TS, a live web app for one four-unit property — first commit July 15, first live deployment July 16, 137 commits at the July 27 snapshot.
  • A hardening review found contact information hidden on the public page but still present in JavaScript sent to every public browser — the interface looked private; the artifact was not.
  • The only new cash cost I can defend is about ten dollars for the domain, from recollection. That does not make this a “ten-dollar app” — the economic cost is not yet measured.

AI helped turn plain-English requests into a live property app remarkably fast. The prompts were the easy part. Defining the workflow, permissions, tests, and maintenance burden was the real work.

We had just bought a four-unit building when I got access to Fable 5.

My first idea was narrow: could I automate tenant onboarding? Put the lease, house rules, move-in condition, insurance, keys, and acknowledgements in one place instead of scattering them across email, texts, PDFs, and memory.

Then it expanded. A resident reports a leak. A manager schedules the repair. An owner approves the cost. The completed work stays attached to the unit. Add a public website, locked portals, documents, compliance, financial views, and a local AI assistant.

What I actually built

918TS is a web app and progressive web app for one property. It opens in a browser and can be installed on a phone. It is not a native app, and it is not yet a SaaS business.

The product combines a public property site with authenticated resident, manager, and owner views. It supports onboarding, documents, maintenance, compliance deadlines, owner decisions, financial reporting, and Ask 918 — a read-only assistant powered by local Gemma 4 through Ollama on my own hardware.

The repository began July 15. The operating record identifies July 16 as the first live deployment.

I remember Fable exhausting my available weekly allowance on day one during that first end-to-end cycle. Git gives a firmer, narrower record: at my final July 27 check, the repository had 137 commits. Forty-six carried a Fable 5 co-author trailer, 59 carried an Opus 4.8 trailer, and 32 carried neither name.

Those counts prove recorded contribution. They do not measure hours, browser work, judgment, or which model "won." This was not a matched model test.

In my judgment, the recent Sol/Codex work materially improved the look and feel. That matters because people route around confusing software. But visual polish is not the same as production readiness.

Hardening began where the first demo ended

One hardening review found a perfect example. Contact information intended for signed-in users was hidden on the public page — but still present in JavaScript sent to every public browser.

The interface looked private. The artifact was not.

We moved that boundary out of the public bundle and expanded the privacy check to inspect fresh compiled output. After a clean build and deployment, the new bundles and both formerly exposed chunk URLs no longer contained those values. The same principle applies to permissions. Hiding an owner button from a resident is not a security control. The database has to reject the resident's direct request, even if the intended screen is bypassed.

That changed my checklist:

  1. Define one complete lifecycle and the states that must never occur.
  2. Start with synthetic data, not copied production records.
  3. Enforce access in the database and server path, not only the menu.
  4. Deploy early enough to expose hosting, authentication, and mobile failures.
  5. Test every role, direct requests, concurrency, send gates, and compiled files.
  6. Keep a public demo isolated from production, with no external writes and one-click reset.
Public proof stays separate from the production portal Two systems, one deliberate boundary PUBLIC WORKFLOW LAB Your browser fictional interaction → Browser-only state resettable → No backend nothing sends PRODUCTION PORTAL Authenticated role resident · manager · owner → Database rules scoped records → Local Gemma 4 scoped · read-only
The public demo has no route into production. The real assistant receives authenticated, scoped context and cannot change a record. Diagram source: this page; maps 1:1 to the demo-isolation checks on the proof page.

Why the public demo is smaller

The 918TS Workflow Lab (archived) lets anyone move one fictional water-heater request through resident, manager, and owner views.

It has no production login, database, resident record, upload, email sender, payment rail, or Gemma connection. State stays in that browser. Reset clears the walkthrough.

That is intentional. A public artifact should explain the operating logic without becoming a new path into the operating system.

What did it cost?

The only new cash amount I can defend today is about ten dollars for the domain, based on my recollection. I have not reconciled it to the registrar record.

Claude and Codex were already covered by plans or weekly allowances I was paying for. Fable exhausted its available allowance during that first day.

That does not make this a "ten-dollar app." A complete cost would include my time, subscriptions, existing computer and GPU hardware, electricity for the local model, future usage, maintenance, backups, and security review. The marginal cash expense was small. The economic cost is not yet measured.

Would I build or buy?

Buildium's July 2026 article on property management and vibe coding (archived) warns against treating generated code as a casual replacement for systems carrying resident data, accounting, compliance, and emergency workflows. That warning is fair.

I would buy when the workflow is standard and I do not want to own security, support, and maintenance. I would prototype with AI when the workflow is specific, the blast radius can stay small, and I can recognize a wrong result. I would move that prototype into production only after the important rules live below the interface and the failure paths are tested.

Proof and limits

This is one active system for one four-unit property. It is not a controlled model comparison, representative cost study, general SaaS, payment processor, or proof that another owner should build instead of buy.

The proof page separates repository facts, my recollections, public-demo checks, and what remains unknown. The demo is synthetic because real resident, owner, document, and financial context does not belong in a case study.

AI can write a surprising amount of an app. The better question is: who will know when it is wrong, and what stops that wrong answer from reaching a resident, an owner, or the ledger?

Try the fictional workflow and tell me where the handoff breaks for your operation. That is more useful than telling me the screen looks impressive.

Method & data

Method: one live AI-assisted build — 918TS, a web app for one four-unit property, plus its isolated synthetic public demo — checked against the repository's dated Git history, the deployment record, and the July 27, 2026 verification snapshot
Data: patterns and methods only; no names, dollar figures, addresses, case identifiers, or confidential content · Last checked: 2026-08-14

How this was made

AI-drafted, adversarially checked, human-directed. My AI assistant wrote this from the system's own records — the repository's dated Git history and trailer counts, the July 27 build-and-privacy verification snapshot, and the sanitized evidence table on the proof page. A separate AI session then tried to break every claim against those records, and automated privacy and readability gates ran before publish. Cost and model-usage details that rest on my memory are labeled as recollection in the text; no tenant, owner, credential, private contact, or real financial record appears in the public demo or this article. I direct this pipeline, own every boundary in it, and audit published pages on a rolling basis — if you find an error, tell me and it goes in the corrections log, dated, never silent.

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

Cite this

@online{ali2026propertyportal,
  author = {Ali},
  title  = {I Built Property Management Software With AI. The Prompts Were the Easy Part.},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/ai-built-property-management-software/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.