Dholera Pratham

Dholera Pratham sells plotted-development land in the Dholera Special Investment Region. We built the entire operating system around that business: the public marketing and listings site, an admin console that doubles as the site CMS, an Express API, an Expo mobile app the field sales team runs on, and a Tauri/Rust desktop app for tracking the money side of each project.

The interesting work is in the domain model — property sizes and rates arrive as bigha, acre or square-yards and have to normalise into one comparable unit — and in the desktop app's payment-funding logic, which stops an allocation from ever exceeding the payment it draws from.

Dholera Pratham sells plotted-development land in the Dholera Special Investment Region — India's first greenfield smart city. Selling that land is only the visible part of the business. Behind it sit inventory that changes hands, a field sales team chasing follow-ups, channel partners, and the money side of every project: token payments, byana, registry, vendors, purchase partners.

Algotrax built the operating system for all of it. Five applications across four platforms: the public marketing and listings site, an admin console that doubles as the site's CMS, an Express API underneath both, an Expo mobile app the field sales team runs on, and a Tauri desktop app on Windows for tracking the finances of each project.

The site is the shopfront. The other four are the business.

The backend is Express 5 on Mongoose — eighteen models, seventeen route groups — with AWS S3 and presigned URLs for media, Firebase Cloud Messaging for push, and Winston daily-rotating logs. It's Dockerised, and it went through an S3-and-Mongo infrastructure migration mid-engagement without downtime the users noticed.

The config layer is deliberately data, not code: villages, zones, town-planning schemes, lead types, customer types and lead groups are all editable lists. The sales team's vocabulary can shift — a new zone, a renamed stage — without a deploy.

Land in this market is quoted however the seller thinks about it. Plot sizes come in bigha, in acre, or in square yards. Roads are measured in metres or in feet. Asking rates are per full plot, or per bigha, or per acre, or per square yard.

None of that is comparable until it's normalised. The Property model parses every one of those forms and converts to square yards and square metres and a single per-square-yard rate, so a listing page can actually sort and filter by price and size.

One line in that model reads TODO: confirm with client, on the bigha-to-square-yards conversion factor. That's the right instinct: a domain constant that varies by region is a question for the client, not a guess in the code.

There is no separate content system. The same console the sales team opens to work leads and inventory is where the website's hero media, public listings, FAQs, and news and blog articles are edited — the articles in a TipTap rich-text editor, the map locations through a Google Maps picker.

Everything routes through an approval workflow. New leads, property changes and lead-assignment requests all land in a pending queue with a badge on the console, so an admin signs off before anything reaches the public site or gets reassigned.

The Expo mobile app is what the field team actually carries. Property and lead management with search, filter and sort; a Google Places map picker for pinning plot locations; a follow-up badge on the Leads tab so nothing slips; image, video and file capture on site; push notifications; auth that persists between sessions. Redux Saga drives the sync.

The lead search behind it is modelled on how the team talks. It normalises Dealer, Selling Dealer and Buying Dealer, parses requirement flags, and understands follow-up windows the way a salesperson does — today, tomorrow, this week, this month, or a custom range — on top of the usual stage, group, budget, location and assignment filters.

The finances of each project live in a separate Tauri and Rust application for Windows. It tracks vendors, purchase partners, seller and client parties, outgoing and incoming payments both due and made, payment links, project documents and expenses. Local storage is SQLite encrypted with SQLCipher, keyed with Argon2 and AES-GCM, because this data doesn't belong on a shared server.

Project summaries roll token, byana, intermediate and registry balances, plus purchase-partner and seller-party balances, into one dashboard. And funding an outgoing payment from a source is validated on both sides: the allocation can't exceed the outgoing amount, and it can't exceed the source payment's remaining balance. You cannot over-allocate money that isn't there.

An Excel backup and import carries the project's records, its computed totals and its attachments — chunked as base64 — so a whole project can move to another machine intact.