Why we still ship static sites for real estate launches
No build step, no framework, no server to fall over at 11pm. An argument for boring technology, made from the device report rather than from taste.
Every few months a client asks why their new project microsite isn't being built on the same stack as their corporate platform. It's a fair question. The answer is that a real estate launch site has an unusual job, and the tooling most teams reach for by default is optimised for a different job entirely.
A launch site exists to do four things: load instantly on a mid-range Android phone over patchy 4G, survive a traffic spike the moment an ad set goes live, capture a phone number, and not break at 11pm on a Saturday. That's it. Nothing about that list requires a build pipeline.
The mid-range phone is the real client
Look at the device report for any plotted-development campaign in North India and the picture is consistent: overwhelmingly Android, largely sub-₹20,000 handsets, plenty of sessions on congested networks. That user is one loading spinner away from the back button, and the back button costs you a lead you have already paid for.
A hand-built static page ships as HTML the browser can paint immediately. A framework-rendered page ships a shell, then a bundle, then hydration, and only then becomes interactive. On a fast phone that gap is imperceptible. On the phone that is actually visiting, it is the difference between a form fill and a bounce.
You are not buying a slow site. You are buying the leads that the slow site loses, at the price you paid to acquire them.
Traffic arrives all at once
Property launches don't get gentle traffic curves. A campaign goes live, a hoarding goes up, a broker network forwards the link, and traffic goes from nothing to several thousand concurrent sessions inside an hour. Static files sitting on shared hosting behind a CDN handle that shape without anyone waking up. A server-rendered app on an undersized instance handles it right up until it doesn't.
The failure mode matters here. A static site under load gets marginally slower. An application under load returns errors — during the exact ninety minutes the entire media budget is firing.
The site outlives the team that built it
This is the argument that actually persuades developers. A launch site's realistic lifespan is eighteen months to five years, and during that time it will be edited by whoever is available — a junior marketer, the client's cousin who "knows computers," or an agency that isn't us.
A folder of HTML, CSS and JavaScript can be opened, understood and changed by any of them. A project with a lockfile, a build step and eleven transitive dependencies cannot, not two years later, not without someone first getting the toolchain running again. We have inherited enough abandoned builds to treat this as a design constraint rather than a preference.
What we still build properly
Static does not mean primitive. On a typical launch site we still ship:
- An interactive SVG master plan — clickable plots, availability states, sizes and pricing on tap
- Lead forms with real validation, honeypot spam protection and direct delivery into the client's CRM or sheet
- A floating call and WhatsApp dock, because in this category most conversions are a phone call
- Scroll-linked motion, image galleries, RERA and legal disclosures, and a downloadable brochure gate
- Schema markup, Open Graph cards, and analytics wired to the events that matter
All of it in vanilla JavaScript, all of it deployable by dragging a folder into public_html.
When we don't do this
The honest boundary. We reach for a framework when the project involves genuine application state: user accounts, dashboards, an inventory that changes hourly, a catalogue with hundreds of items and real search, payments with order history. Educare's platform is a framework project. A township launch site is not.
The test we use internally: does the page need to know who is looking at it? If no, static wins on every axis that matters — speed, cost, resilience, maintainability. If yes, pay the complexity and build the application.
Static is the right call when
- Content changes weekly at most, not hourly
- Traffic is spiky and campaign-driven
- The primary conversion is a call, a form or a brochure download
- Someone other than the original developer will maintain it
- Hosting is shared, cheap and already paid for
The uncomfortable part
Choosing boring technology is harder to sell than choosing exciting technology. Nobody's proposal ever won on "we'll write the HTML by hand." But launch sites are judged on cost per qualified lead over a ninety-day window, and on that metric the boring build wins with distracting regularity.
We'd rather hand over something the client's nephew can edit in 2029 than something that impresses another developer in the handover call.
Lakshay founded The Marketeours five years ago and still runs client delivery. He writes about search, positioning and the parts of agency work nobody puts in the deck.
