Building a property management system that does not collapse at scale

Acredge came to us for a landing page. One page, some inventory on it, a form at the bottom. It was a reasonable ask, and we could have built it in a week and sent an invoice.

We did not, because the page was not the problem. What they wanted that page to do was the job of a property management system, and they had not yet had a reason to see it that way.

The brief was the symptom

Acredge sells premium residential inventory in Gurgaon, where the same tower can carry a dozen unit configurations and the details change week to week. Their property information lived in spreadsheets, in decks, and in the heads of individual relationship managers.

A landing page would have put a snapshot of that online, and the snapshot would have been out of date within a fortnight. Then somebody would have had to update it by hand, and the page would drift from the spreadsheet, and the spreadsheet would drift from what the RM told the buyer on the phone.

The requirement underneath the brief was a place where property data lives once, is edited once, and appears everywhere it needs to appear. That is a system, not a page.

We showed instead of proposing

Arguments about scope are almost impossible to win in a slide deck. The client hears cost, and the firm making the argument has an obvious financial interest in the bigger answer. So rather than write a proposal for a system, we built a first version of one and put it in front of them.

Once you can click through a thing, the conversation changes completely. It stops being about whether a system is warranted and starts being about which parts of it matter. That was the point of showing it early. We wanted the feature argument to happen with something real on the table rather than in the abstract.

The most useful number was how few

By the time they were convinced, Acredge had a long list of features they wanted. Most clients do at this stage, and almost every item on such a list is defensible on its own terms.

The contribution we are proudest of on this project was helping them decide how many features to keep. Not which ones, how many. Agreeing a ceiling first changes the character of the discussion. Prioritisation becomes an honest trade against a fixed budget instead of an open-ended negotiation where everything can be argued in.

A feature you build and nobody uses is worse than a feature you never built. It still has to be maintained, it still crowds the interface, and it still occupied the slot where something useful could have gone.

A property is not a row in a table

The core of the build was modelling property correctly, which sounds obvious and is exactly where most real estate software goes wrong.

A listing is not a single object. A project has towers. A tower has floors. A floor has units and rooms. Each level carries the attributes that are genuinely true at that level. Amenities, approvals, and location belong to the project. Floor plate, facing, and lift core belong to the tower. Price, availability, configuration, and status belong to the unit.

Flatten all of that into one listing record and you re-enter the same amenity list for three hundred units, which is three hundred opportunities for it to drift out of agreement with itself. Model it as a hierarchy and a single change at the project level updates everything beneath it, correctly, everywhere.

This is the decision that determines whether the system still works at ten times the inventory. Adding a tower becomes adding a node rather than starting a data entry project.

The listing flow is the product

The screen the team actually spends its day in is the one that gets a property into the system. We built that flow around the order in which somebody holding the information would naturally supply it, with media, documents, configurations, and availability attaching at the level where they belong rather than all being dumped on one form.

Everything else in a property system is downstream of this. If entry is slow, or ambiguous about where a piece of information goes, the data will be bad, and every screen built on top of bad data is decoration.

Some of it did not work

Not everything we built earned its place. Parts of the system that were correct in design turned out to be more structure than the team needed day to day, and the signal was unmistakable once they were live. People were working around them rather than through them.

The honest thing to do with that is name it rather than quietly leave it out of the case study. We built things that did not survive contact with the people using them.

Which is how the simplified version got designed

What came out of that was worth more than a build that had gone perfectly. Acredge learned, from their own product and their own usage rather than from our opinion, precisely which parts of the system they needed and which were weight.

They arrived at a simplified version, and it was theirs. A team that has watched one of its own requested features go unused does not need to be convinced about scope again, by us or by anybody after us. That lesson transfers to every product decision they make from here, including the ones we are not part of.

Where it stands

Acredge has a property system with a data model that holds as inventory grows, a listing flow their team runs without us, and a clear internal view of what they should and should not build next.

They came for a landing page. What they left with was the ability to decide.