EC sales systems for property developers, four years on.

In 2022 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 original write-up (Team-Notes #63) covered the highlights: 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 the 2026 update.

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 2022 design used a dedicated SFTP server at the developer’s edge. In 2024 most developers 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. In 2024 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 in 2024 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

In 2022 we offered both on-prem and cloud; on-prem was popular among developers nervous about cloud. By 2024, most new EC launches are cloud-only. Cloud is now 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 in 2026, 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.

What we cut from the original

• The implication that on-prem and cloud are equally chosen. They are not in 2026.
• The phrase “blueprint for organizations facing similar challenges.” It overclaims.

What carries over unchanged

The launch-day discipline. Property developers do this once or twice a year. Get it right or get a phone call from the COO at midnight.

— wGrow studio · migrated from Team-Notes #63