Landair broker platform
The internal tool a New York brokerage runs its deals on, built from scratch
- Situation
- A New York brokerage ran its deals through a shared database and many hand-typed steps, and I had never worked in real estate.
- Task
- I had to give the brokers one place for their daily work, and learn the business while I built it.
- Action
- I interviewed the founders and brokers, mapped their work into small changes and built each one with AI coding agents. Every change went live on merge, and their feedback set the next one.
- Result
- The team finds owners, prices properties and moves deals in one place, and the founders want their next tools built on it.
Brokers find owners, price properties and run their deals in one place.
How I built it
Learned the work before I designed anything. I asked the founders and brokers to walk me through a deal, from a new lead to a signed exclusive, and asked why each step existed. I read the formulas in their own comp sheets to learn how they adjust a price, instead of guessing at the method.
Turned what I heard into a written plan. Each pain point became a small change I could test and ship on its own. A question only the founders could answer went to them as a short, plain choice before I wrote any code.
Built with AI coding agents. Claude Code writes most of the code, with agents working in parallel, each in its own git worktree. I write the plan and the checks, read the changes and merge them. Larger changes also get a review from a model that did not write them, and its findings ship as the next small change.
Shipped in small pieces. Each change is a small pull request, and a merge to main puts it live. Before I tell anyone a fix is live, I check that the live site reports the new version.
Used the founders' review videos as specs. They review the tool by recording their screen while they talk it through. I transcribe each video, pull the key frames and turn the asks into a list, marking what was said, what was seen and what I inferred. Each item becomes its own small change.
Put an agent on the team's feedback channel. The team posts a problem in plain words, and a scheduled Claude agent triages it. It opens a fix as a pull request for me to merge, sends me anything that needs a decision, and replies in the thread once the fix is live.
Let the brokers' own edits test the software. The comp picks brokers save on the site became part of the answer key for any change to how comps are chosen, so a change has to match what brokers picked, not what I expected.
Why these choices
Plain words on every screen
A founder told me that the more a screen needs explaining, the less friendly it is. So screens use the team's own words: no database names, record ids, rule numbers or engine terms, and no paragraphs of instructions.
A broker sees it before an owner does
Building a valuation on the site never sends it. Sending is its own step, from the valuation on screen, and the result says plainly whether it was sent, and why not when it was not.
Fewer pop-ups
The team asked for fewer confirm boxes. A confirm now stays only where a click emails other people, such as moving a deal into a signed stage.
The page is the document
The valuation page shows every page of the PDF it prints, in order, and brokers edit it in place. What they see is what the owner gets.
Rulings and rules live in files
Every ruling from the founders goes into a decision register, with who decided and when. Each agent session reads it first, so work starts from what was decided. Rules that must always hold are hooks and tests, not reminders.
On by default, with a kill switch
A change the team asked for goes live switched on. Its switch is there only to turn it off fast if something breaks. A change that measured worse stays off.
What shipped
- One place for the day's work: property and owner lookups, valuations, comps, contacts and the deal pipeline, behind the team's own sign-in.
- Brokers start owner lookups themselves, watch them run, and mark a wrong owner right on the row.
- A valuation is built, edited and sent from one page, priced on the comps the broker picked.
- The deal pipeline is a board brokers drag deals across. A daily sweep merges duplicate copies of a property and leaves any copy that is further along to a person.
- Listing changes made on the platform reach the firm's public website.
- A problem the team posts often comes back as a live fix, with a reply in the same thread.
Failures and limits
- A save on one tool failed for weeks, and nobody reported it. People stop using a broken tool quietly. Now a public health check alerts me when the site goes down, and a test guards the seam that broke.
- A failed lookup once reached the model as an empty answer, and the model wrote a confident summary on top of it. A failure now says it failed.
- Dates showed a day early, because a date with no time was read as midnight in another time zone. Dates now go through one New York date helper.
- The site once said an email had gone to the owner when nothing would be sent. A send now says sent, or not sent and why.
- The site started each valuation from an older tool's comp picks and treated them as the broker's own. The brokers' saved picks showed it. Those picks now start unticked, so the first build chooses fresh.
- The first duplicate sweep merged a property into the wrong record, and I undid it by hand. The sweep now does a dry run unless told otherwise, works in small batches, and leaves any copy that is further along to a person.
- The website has no CI. I run its tests by hand before a merge, and a merge goes straight to production. That gap is real.
What I learned
- Coming in new to the domain made me ask why each step existed. The answers became the spec.
- Building is cheap now, so judging is the job. The agents write fast; I decide what is right and check that it is.
- Silence is not proof that a tool works. People stop using a broken screen before they report it.