A real-estate CRM that calculates prices, tax and brokerage will one day show a buyer a figure nobody in the firm ever said. The safer rule is narrower: a figure exists only if a person recorded it.
By Mohammad Jamnagarwala · Simply Five Studio
Every real-estate CRM pitch includes a slide about pricing. Enter the base rate per square foot, the floor rise, the preferential location charge, car parking, the club membership, GST, and the system builds the cost sheet for every unit in the tower. Add a brokerage slab and it works out what the firm earns on each sale. It looks like leverage.
For a channel partner it is a liability. When we built the operating system for Evrnest Vista Associate, a Chennai and Dubai channel partner, we settled on the opposite rule in the first week, and wrote it into the system as a hard constraint: the application stores prices. It does not do money.
A developer owns the price. The channel partner relays it. When Evrnest quotes a flat to a buyer, the figure on that quote is the developer's figure, on the developer's sheet, as of the day it was sent. The firm's credibility rests on that quote being exactly what the developer said.
A pricing engine changes whose number it is. The moment a system multiplies a stored rate by a stored area, the figure on the screen is the software's figure. It is correct on the day the rate was entered. It is wrong the day after somebody edits the rate for the next release, because every unit that reads that rate quietly changes with it, including units already quoted.
That is the failure that matters. Not an arithmetic error. A figure that nobody in the firm ever said, shown to a buyer who will hold the firm to it.
The constraint is narrow, and it has to be, or the team works around it.
Inventory records what a property is priced at, as quoted, line by line as the developer wrote it. Nothing is ever computed from that figure. No total derived from a rate. No tax derived from a percentage. No brokerage of any kind: not seller side, not buyer side, not on a resale mandate, not as an indicative estimate. No receivables, no payouts, no invoices. A resale mandate records exclusivity and expiry, because those are operational facts. The commercial terms stay in the agreement, where they belong.
The screen may show a sum of lines that were each recorded, labelled indicative. That is as far as it goes.
Rules like this get tested. Ours was amended twice in its first month, and each amendment made the rule clearer rather than weaker.
The first came when the directors wanted a developer mandate to report what its book was worth: total value, sold, remaining. That is addition, and addition of recorded figures cannot invent a number. So the rule widened by exactly one operation. A mandate may add up the sale values already transcribed off the developer's sheet. A unit with no figure is reported as unpriced, never silently counted as zero.
The second came when the desk started describing towers on screen instead of uploading the developer's workbook. Typing two hundred cost sheets by hand was not acceptable either. The question was whether the system could suggest a GST amount from a rate, or a basic price from a figure per square foot.
The answer clarified what the rule had protected all along. It was never "no arithmetic". It was no figure exists that nobody recorded. So a multiplication may happen once, when a person asks for it. The result is shown, overtypeable, and stored only when it is accepted. After that, nothing ever reads the rate again. A rate edited today cannot rewrite a quote sent last week, because no quote depends on the rate. It depends on the figure someone accepted.
A subtotal is computed on read from stored lines and stored nowhere, so it can never disagree with the lines it claims to sum.
Founders sometimes read a constraint like this as a missing feature. Look at what the pricing engine actually costs.
It has to model every developer's charge structure, and no two developers structure a cost sheet the same way. One charges floor rise per floor from the fifth. Another charges a flat premium above the tenth. A third bundles car parking into the basic price for some configurations. Each one is a branch of code that must be maintained, tested and explained, for a figure the firm does not own and cannot change.
Brokerage is worse. Slabs vary by developer, project, volume and negotiation, and change mid-year. Encoding them puts the firm's most sensitive commercial terms inside a system the whole field team can see parts of, and creates a second ledger that will drift from the accountant's.
Recording the developer's figures as written costs a transcription. That is the whole of it.
None of this leaves the desk short of information. The cost sheet for every unit is on screen and on the share card PDF a buyer receives. The payment schedule says what falls due at each construction milestone. The mandate reports its value, its sales, and its remaining stock. The public site shows the government guideline value for a street and a range of market value for a locality, both displayed as published and never used to value a unit.
What the firm does not get is a number it would have to defend without having said it.
If you run a brokerage, a developer's sales desk, or a property portfolio, ask one question of your current software, or the one you are being sold. When a rate changes, which figures already shown to a customer change with it?
If the answer is anything other than "none", the system is pricing on your behalf, and the first time it is wrong, it will be wrong in front of a buyer.
The fix is not a better formula. It is a smaller promise, kept exactly. That is the shape of the systems we build for founder-led firms: narrow where the business is exposed, and fast everywhere else.
Adding a payment gateway to a distributor's store is not a binary upgrade. The right design keeps the enquiry path for orders that need a human and adds a live checkout for orders that do not. The same cart, two ways to finish.
Accounting software produces statutory output. ERP automates the workflows of a generic business. Neither is the same as the structured truth a founder needs to run a specific business. That third thing is decision infrastructure, and it is what founder-led firms eventually outgrow SaaS to acquire.
Every six months a founder asks why they need another system when Tally already runs the books. The honest answer is a diagnostic, not a sales pitch. Here is how to run one on your own business.
The contact form takes about two minutes. The reply comes from the founder within two working days.
