EC sales systems for property developers.

We built an Executive Condominium (EC) sales and reporting system for a Singapore property developer, after HDB pushed EC e-application onto developers’ own systems. The build covered hardened server posture, SFTP integration with HDB via Reflection for Secure IT, SHA-256-encrypted columns for buyer data, real-time generation of Option to Purchase (OTP) docs and side letters from Word XML templates, both cloud and on-prem deployment, and post-launch data purging.

The system ran three EC launches without incident. It’s still in production. Here’s what carried over and what we changed.

What carried over unchanged

• The launch-day surge profile. ECs sell out in hours; the system has to absorb that without complaint. The original capacity plan held.
• SHA-256 column encryption + key custody in HSM. PDPA-defensible; auditor-defensible.
• Word-XML templates for OTPs and side letters. Boring, deterministic, easy to update without code changes.
• Auto-purge of personal data once the sales process completes. PDPC continues to hammer on retention; we’re glad we shipped this from day one.

What we’d change

1. SFTP to HDB is now usually IBSS-fronted

The early design used a dedicated SFTP server at the developer’s edge. Most developers now route HDB integration through their corporate IBSS / API gateway, which sits in front of the SFTP transport. The actual data plane is the same; the developer’s IT team gets a single audit point.

2. We sign every generated OTP

The original generated password-protected PDFs. We added signed generation — every OTP is a digitally-signed PDF with the developer’s certificate. It made post-launch dispute resolution dramatically simpler the one time we needed it.

3. Eligibility checks are not the agent’s job

A few developers asked us whether an LLM could pre-screen EC eligibility (the classic income / household / Singaporean-citizenship / first-time buyer matrix). We tried it. We do not recommend it. Eligibility is a deterministic-rules problem, the rules change in policy windows, and a wrong “yes” costs the developer real money. We use deterministic logic with a versioned rule set and a regression test suite.

Where an agent does help: drafting buyer-facing emails when an application is incomplete or rejected. The agent reads the rejection reason, drafts a clear explanation, and a sales staff member signs and sends.

4. On-prem is no longer the default for new launches

We originally offered both on-prem and cloud; on-prem was popular among developers nervous about cloud. Most new EC launches are now cloud-only. Cloud is the default; on-prem is a constrained option for clients with specific regulatory or board-level reasons.

The launch-day playbook

For anyone doing this kind of system, our launch-day defaults:

• Pre-warm. The day before launch, run synthetic load equal to ~150% of the expected peak, end-to-end through the full stack including the HDB integration.
• Scale ahead. Don’t auto-scale on launch day; manually pre-scale to expected peak. Auto-scaling lags real demand by minutes you don’t have.
• Read replicas off the hot path. All reporting, audit, and HDB-status checks read from replicas. The primary handles writes only.
• Two on-call engineers, one on-call partner. Three pairs of eyes for the first hour.
• A frozen change window starting 48 hours before launch. No changes to anything until the post-launch standup.

The launch-day discipline is the part that doesn’t move. Property developers do this once or twice a year. Get it right or get a phone call from the COO at midnight.

— Scott Li, wGrow