The problem
A property developer runs the same project across four systems that never talk to each other: the portal where listings go, a generic CRM that knows nothing about land parcels, loose spreadsheets for construction progress, and accounting off to one side.
The cost isn't the inconvenience — it's that nobody holds the whole number. Ask what the project is worth today, or how much of the subdivision has sold, and the answer gets assembled by hand over several days. By then it has changed.
Before writing a line of code we talked to four developers. Two things came up every time:
Due diligence is scattered across counters. Moving an operation forward means visiting one site per public body, each with its own procedure, its own login and its own turnaround, then stitching the results together manually. It is the slowest stretch of the process and where most deals fall through.
Publishing is expensive, and onboarding a new client costs more. Showing the full catalogue is already laborious; bringing in a new developer's properties is harder still. Commercial growth ends up throttled by data entry.
What we decided
Integrate with the public bodies instead of asking the user for the data. The easy route was one more form where somebody retypes whatever they pulled from each office. We took the slow road: sitting down with those bodies so the paperwork enters the system at the source. It is harder to build and it is the only way the data arrives trustworthy.
Treat acquisition as a funnel, not as data entry. Adding properties stopped being an administrative chore and became a designed funnel, the same as sales. They are two sides of one business and until now only one of them had been thought through.
Mobile first, no native app. The monitoring panels get checked from the site, from the car, or mid-meeting — not sitting at a desk. A responsive web app covers that from day one; a native app would have added months and an app store in the middle to solve the same problem.
AI to clean the data, not to chat. The system traces and aligns messy data according to what each client needs, then feeds a sales agent or a broker who arrives at the conversation already informed. The underlying call: AI does its work before the conversation with the buyer, not instead of it.
Charge on usage, not on licences. Pricing follows operating volume instead of a fixed per-seat fee. A small developer gets in without an entry barrier they cannot justify, and whoever operates more pays more — which is exactly when the system is saving them time.
Real cadastral data, not a decorative map. Parcels are drawn over the exact planimetry of the Misiones Land Registry. A generic map takes an afternoon and is useless for deciding; real cadastral data is what lets you look at one specific plot and know what is being discussed.
How long it took, and where it stands
The first complete version was built during the Hackathon IA run by Silicon Misiones in June 2026: thirty hours on the clock across five days.
Habita won the Special Mention for Outstanding Project there, awarded by Silicon Misiones together with the Strategic Coordination for Smart Government and the Vice-Governor's Office of Misiones.
It is worth being clear about what that means and what it does not: it is a jury recognising a project built in five days, not a measure of impact in the market. Those are two different things, and the second one does not exist yet.
It is in validation today, not in production. The idea is being tested with the Misiones Real Estate Chamber, and product measurements are running with real users in the province. Access is by waiting list.
I am writing it this way on purpose: there are no impact numbers yet, because the product has not been in anyone's hands long enough to have them. There will be, and they will be here once they exist.
Stack
Next.js and TypeScript on AWS, with Stripe for payments.