Anatomy of a four-week build

Key takeaways

• What a typical four-week build looks like for a small property operation: four systems covering inquiry intake, maintenance triage, lease renewals, and owner reporting.
• The stack is deliberately boring: a small Python service, Postgres, the Anthropic SDK, Slack for the operator, and thin clients for the property software.
• None of it makes decisions for the operator. Every system prepares work, keeps a paper trail, and leaves the call to a human.
• The client owns the source code, the credentials, and the documentation from day one. If they fired us the day after handoff, everything would keep running.

The shape of the engagement

This is a walkthrough of the build we most often scope for small property operations, written as one engagement so you can see how the pieces fit together. Picture an operator with a few dozen doors, a couple of staff, and an owner working evenings to keep up. The details change from client to client. The shape doesn't.

The bottlenecks are almost always the same four: inquiries arriving on too many channels, maintenance chaos, renewals tracked by memory, and month-end reporting that eats a week. Two weeks of audit, then roughly four weeks of build. Here's what gets shipped.

1. Inquiry intake

Inquiries arrive from a website form, a Gmail address the owner has used for years, and whichever listing platforms the buildings are on. Each channel has its own format, and each lead gets retyped by hand into the property software.

The build is one ingestion service that normalizes every channel into a common schema, runs a structured model call to pull out the fields that matter (move-in date, budget, household size, pets), and checks new inquiries against recent ones for duplicates.

What the operator sees is a Slack message: a structured summary, a link to the original, and a suggested next action. They pick the action, and the next step fires. The model isn't making the leasing decision. It's removing the copy, paste, and classify that every inquiry used to require. (There's a fuller guide to this piece in [how to automate lead intake](/blog/automating-lead-intake).)

2. Maintenance triage

Maintenance is usually the messiest workflow in the building. Issues arrive by email, text, and voicemail, classification depends on who happens to read the message, and the history lives with whoever handled it.

The build is a triage service that ingests all of those channels, classifies each issue by urgency and category using a tight prompt, and writes everything to a database the operator owns. Urgent items page the on-call vendor. Everything else lands in a daily digest. Every ticket keeps its full trail: original message, classification, confidence, vendor dispatched, resolution.

The classifier will get some tickets wrong. That's expected and designed for. Low-confidence classifications go to a human review queue each morning, and the operator can flip any category back to manual routing at any time. Having a written policy for the wrong ones is what makes the right ones trustworthy.

The quiet payoff is the paper trail. When an insurance carrier or a tribunal asks how a specific report was handled eight months ago, the answer is a database query, not an afternoon of digging through Gmail.

3. Lease renewals

Renewals usually live on a calendar and in someone's head. Ninety days before expiry a letter should go out, follow-ups should happen, and a decision should get made. It works, right up until the one month it doesn't.

The build here is boring on purpose. The system watches lease dates, drafts the renewal at 90 days, schedules the follow-ups, and escalates to the operator the moment a tenant replies with anything that needs judgment. Nothing goes out without approval in the early months. The point is simple: no renewal ever again depends on someone remembering.

4. Owner reporting

At month-end, each property owner gets a one-page report: occupancy, rent collected, maintenance summary, notable events, a look at the next 30 days. Assembled by hand from software exports and scattered notes, each one takes half an hour or more, and they all come due in the same week.

The build generates first drafts from the data the other three systems have been keeping all month. The operator reviews, edits the ones that need a human paragraph, and sends. The reports that need attention get it. The rest stop costing an evening.

The stack, in one paragraph

For the engineers reading: a FastAPI service on a single small VPS, Postgres for state, the Anthropic SDK for model calls, thin custom clients for the property software (auth, pagination, and rate limits handled properly), Slack as the operator surface, and a simple dashboard for the review queues. A few thousand lines of code, all in a repo the client owns. No fine-tuning, no exotic infrastructure. The work that matters is in the operations design: what the system does, what the operator does, and where the handoffs are. (How we pick the orchestration layer for each piece is covered in [Make vs n8n vs custom Claude](/blog/make-vs-n8n-vs-custom-claude).)

What a build like this is for

The point is not to cut staff, and in operations this size there's usually no staff to cut. The owner is doing this work themselves, at night. The point is to hand the constrained person their hours back so the business can grow. That's the standard we hold every build to, and it's why [we named the company "the system"](/blog/why-we-named-the-company-the-system): the deliverable isn't a clever model, it's an order of operations that holds up on its own.

If some version of these four bottlenecks sounds like your week, [book a discovery call](/book). Thirty minutes, and you'll leave knowing which of the four to build first.