Case Study
Japan Property OS
Decision support for buying property in Japan.
Founder / Product Lead
Foreign buyers researching property in Japan can find listings easily. Deciding whether a specific property actually fits their situation is the hard part — that's the gap this product is built to close. It's a real, live product: I own it end to end as founder and product lead, from problem definition through AI-assisted implementation, testing, and release.
View live product ↗The Problem
Foreign buyers interested in Japanese residential property — often rental investors, or people drawn to an akiya (an empty, often abandoned home) for personal use — can find listings without much trouble. What's fragmented is everything after that: weighing a property against your own financial and personal criteria, tracking due diligence across legal, building, and neighborhood concerns that don't map cleanly onto a home-country buying process, keeping a record of open questions to agents and lawyers, and judging whether a given property is actually worth pursuing. That information tends to live scattered across listings, PDFs, email threads, and memory.
The product opportunity isn't another listings marketplace. Japan Property OS's own public positioning states it directly: “We don't list akiya. We help you decide.” It's decision support and acquisition workflow.
The Product
Japan Property OS is a decision-support workspace, not a marketplace. A buyer brings properties they've already found into the app, then works each one through a structured pipeline — Tracking, Interested, Under Contract, Purchased, and so on — while the product organizes everything around the decision: a full property profile, a financial analysis (yield, cash flow, ROI, break-even), a ten-category due-diligence checklist tailored to Japan-specific concerns, documents, notes, and a contact-linked questions tracker for the agents, lawyers, and inspectors involved in an acquisition.
From Readiness to Suitability
The initial Acquisition Readiness Score used a deterministic completion model — a fixed percentage of completed checklist items. As the product evolved, I found that approach too rigid to capture whether a property actually fit an individual buyer's goals.
I replaced it with Suitability Score, which evaluates properties against the buyer's own criteria and provides a personalized rationale. It's LLM-based, reasoning over a buyer's stated criteria against a specific property to return a score, a plain-language rationale, and specific flags a buyer can act on directly — like verifying a local zoning restriction or confirming short-term-rental eligibility.
Designing the Operating System
A pipeline and a comparison view, not just a list
Properties move through an explicit pipeline — Tracking, Interested, Under Contract, Purchased, and more — and once a buyer is weighing several finalists, a side-by-side comparison view lines up the numbers that actually decide a purchase: yield, price, size, station distance. A real trade-off decision shouldn't require reconstructing it by hand from separate tabs.
A due-diligence checklist built for Japan, not a generic template
Ten structured categories — legal, building, rental, neighborhood, municipality, utilities, insurance, earthquake risk, flood risk, and akiya-specific concerns — pre-populated with items curated for the realities of Japanese property, from seismic-standard eras to minpaku (short-term rental) rules. Buyers can add their own items, but the core checklist reflects real domain research, not a generic home-inspection list repurposed for a different market.
Every open question, tracked and attributable
A cross-border, cross-language transaction generates a lot of open questions to agents, lawyers, and inspectors. The questions tracker keeps every one attached to a contact and a property, with status and follow-up dates — replacing the email-thread-and-spreadsheet approach that's the default for most buyers doing this alone.
Building With AI, Deliberately
Japan Property OS was built using AI-assisted development tools throughout — a deliberate, disclosed part of the story, not something to downplay. My role stayed the same as it would on any product I was leading: define the problem, set requirements and acceptance criteria, make the architecture and product trade-off calls, review what got built, decide what shipped. AI-assisted tooling changed how fast a decision could become working software; it didn't change who was making the decisions.
Quality as a Product Requirement
The product carries real testing discipline: automated unit, integration, and end-to-end coverage, run through continuous integration on every change, plus a decision-record trail — over a hundred documented architecture and product decisions — that keeps the reasoning behind the system legible past the point where one person remembers every choice.
Current State
Japan Property OS is live, functional, and actively developed — genuinely early-stage, not a finished company. It's designed around a first-property-free model with a paid tier for buyers tracking more than one property. The core acquisition workflow is operating today, and the story here is the product judgment and execution behind it.
What This Demonstrates
Structuring an ambiguous problem into a real product. Making product and systems trade-offs and living with them. Working fluently with AI-assisted development while keeping the decisions and the verification in human hands. Operating a live product end to end, not just designing it on paper.