Before price, a Tamil Nadu buyer asks the guideline value, because stamp duty is charged on it. The registration portal has no API. Mirroring it street by street, on a schedule, made the answer instant for the desk and the public site.
By Mohammad Jamnagarwala · Simply Five Studio
Sit with a property agent in Chennai for an afternoon and count the questions. Price comes up, of course. But very often the first serious question, the one that tells you the buyer has done this before, is about the guideline value of the street.
The guideline value is what the Tamil Nadu registration department says land on a given street is worth per square foot. It matters because stamp duty and registration charges are calculated on the guideline value or the sale value, whichever is higher. A buyer comparing two flats at similar prices on different streets is also comparing two registration bills, and a buyer purchasing land wants to know how the asking price sits against the official figure.
The department publishes these values on TNREGINET, its registration portal, street by street. When we built the operating system for Evrnest Vista Associate, a Chennai and Dubai real-estate channel partner, answering that question took an agent several minutes on a slow government site, often on a phone, often in the middle of a site visit.
The obvious approach is a live lookup: the agent types a street, the system asks the portal, the answer comes back. It fails on contact with the actual portal.
The registration site offers no API. It is a session-bound, form-driven website that loads a heavy homepage before it will answer anything, and it walks a cascade, district, then registration office, then village, then street, one dependent request at a time. Making a business screen call it live would make the screen exactly as fast and as available as the government portal. On a bad afternoon, that is not at all.
There was a second reason. Evrnest's application serves no content from any external host, by design, so the browser could not call the portal even if we wanted it to.
So the system keeps its own copy. A scheduled job walks the registration portal's cascade and writes every district, office, village and street into the firm's own database. The screen reads the database, which answers in milliseconds whether or not the portal is having a good day.
A few decisions made the mirror trustworthy.
It walks in two passes. The first pass lists every district, office and village, a few hundred small requests. The second fetches the street table for each village. Doing the list first means the job can report real progress, 412 of 15,300 villages rather than a spinner, and the person checking on it from the dashboard is not the person who started it.
It resumes. A statewide crawl is a night's work, and a night is long enough for something to go wrong once. A run interrupted at three in the morning picks up where it stopped and skips anything read in the last day.
It never deletes. A street missing from tonight's read is far more likely to be the portal having a bad minute than a road that stopped existing. Rows are only ever added and refreshed.
It keeps the dates. Every row carries the date the department made the value effective and the date we read it. Guideline values are revised, and "what was the rate when we sold that flat?" is a question an auditor will eventually ask. A live lookup can only ever answer with today's figure.
It keeps their identifiers. Street names typed by a registrar are not stable. The department's own codes for districts, offices and villages are, so a re-crawl matches what it made last time by code, not by spelling.
And when an agent needs to be certain about one village today, a refresh button on the dashboard re-reads just that village on demand.
There is an obvious next feature, and the system deliberately does not build it. Rate times area is stamp duty. It is tempting to multiply the guideline value by the unit's area and print an estimated registration cost on every listing.
Evrnest's system follows one firm rule about figures: it stores them as published and never computes money from them. We explain the reasoning in Software that stores prices and does not do money. A stamp-duty estimate depends on the document type, the buyer's category, the composite value of land and building, and rules that change. A wrong estimate on a listing becomes a figure the firm has to defend. The guideline value, shown exactly as the department published it with its effective date, does not.
Market rates follow the same discipline. The system holds what public sources published for each Chennai locality, one row per source per locality, with the period each figure covers. It is reference material for a conversation, never multiplied by an area, never used to call a property cheap or dear.
The mirror started as a desk tool, a search on the dashboard. In October it moved onto Evrnest's public site, evrnest.org, as part of a property tools drawer, beside an area converter, because land in Chennai is still quoted in grounds and cents as often as square feet. A buyer can look up the guideline value for a street, see market value for a locality as a range rather than a single number, and convert the units the seller used into the ones they think in.
That is a small feature with an outsized effect on trust. A buyer who finds the official figure on the broker's own site, current and dated, has one less reason to doubt everything else on it.
Indian businesses depend on a long list of government and industry sources that publish data without offering it as a service: registration rates, GST rates and HSN codes, tender notices, commodity prices, regulatory registers. The temptation is either to send the team to the source every time or to call it live and inherit its downtime.
A mirror is usually the better answer. Fetch on a schedule, store with dates and the source's own identifiers, never delete, show exactly what was published, and let the business query it instantly. It is the kind of India-specific plumbing we wrote about in our piece on operational software built for India, and it is often what turns a system from a record of the firm's own work into the screen the team opens first.
Warehouse apps are usually built as if the network is always there and treat its absence as an error. At the back of a packed godown, absence is the normal case. Seven rules for stock software that keeps working when the signal does not.
Most business desktop tools do not need Rust. The Lucky Traders Stock app did: one codebase for Windows and Android, a barcode gun heard while Tally has focus, and signed self-updates. Here is the test we use to decide, and what the choice actually costs.
We have argued for years that WooCommerce plus a custom ERP beats every all-in-one for distributors. That is still true as a starting point. This is the other half of the argument: the signals that tell you WooCommerce has become the liability, and what to rebuild it as.
The contact form takes about two minutes. The reply comes from the founder within two working days.
