Systems & UI/UX
The spreadsheet was never the problem. It was the warning.
We build the internal systems companies actually run on — contract ledgers, progress claims, defect registers — and design the interfaces people have to use every day without hating them. Same practice, same reasoning, different material.
Where this came from
We did not pivot into software. We ran out of workarounds.
Running renovations means running a ledger: what was contracted, what was varied, what was claimed, what was certified, what is still open, and what the client was told. Everybody in this industry does that in spreadsheets, and everybody's spreadsheets disagree by the time the final account arrives.
So the systems work here is not a consultancy that read about construction. Every product on this page exists because the same practice hit the wall it solves — on its own sites, or on a client's.
Project 01 · Client system
SD Core
One Postgres schema that is the system of record for Shower Dynamic's contracts, scope, progress claims, certifications, variation orders, invoices, drawings and documents. It replaced a reconciliation process that lived across several workbooks and one person's memory.
What it enforces
- Contract position always computed: original value plus approved variations, never
typed in
- Progress claims auto-numbered per contract and frozen once submitted
- Only legal status transitions allowed — the database refuses the rest
- Append-only certifications with a stated reason on every line adjustment
- Invoices follow certifications; payments keep invoice status current
- Gapless document sequences, so nothing can quietly vanish
The design decision that matters: domain rules live in the database as triggers and stored procedures, not in application code. An interface can be rewritten, a script can be run by the wrong person, a spreadsheet can be edited on a plane — but a claim that exceeds its contract position simply cannot be written.
Migrations are the source of truth, and behaviour is proven by tests against a real local stack rather than a mock. When the seeded ledger disagrees with the client's own reconciliation sheet, the discrepancy on screen is the one the old process created.
Project 02 · Our own
DefectSG
A homeowner-side public record of which Singapore renovation firms, designers and builders actually fix the defects they leave behind. Free for homeowners, permanently. Firms pay to be measured, not to be marketed.
Most renovations do not end in a scam. They end with a list — the job finishes, the defect list is agreed, the final payment gets abandoned, and the carpentry is never fixed. Nobody counts this, because no single chipped door is worth a complaint.
So the product counts it. Homeowners log defects at key collection and again after renovation. Every fix comes back with a photo — the app will not let a defect be closed without one. The evidence is the firm's own, which is precisely why the resulting grade is worth anything.
Design constraints we accepted
- No lead selling
- No paid placement, ranking or featured slots
- No percentage of anyone's renovation contract
- No charge to a homeowner, ever
- No hiding a grade because a firm stopped paying
A grade a firm can make disappear by not paying is worth nothing. The constraints are the product.
Project 03 · Our own
PangsaiGoWhere
A restroom-discovery and rating platform for Singapore, named in Singlish because the alternative was forgettable. Beneath the joke is the same structure as DefectSG: a public, openly published A–F standard that cannot be bought.
The data layer
PostGIS geospatial database with full row-level security, privacy-preserving public views and precomputed rating aggregates. Around 740 real locations seeded from OpenStreetMap and enriched with government address data.
The integrity layer
One review per person per location, contributions location-checked, photos stripped of EXIF and GPS on upload, community reporting with weighted moderation. Anonymous to the public, accountable to moderation.
The distribution layer
A keyed, rate-limited read API, a venue restroom directory, and an embeddable live grade badge — so a mall that earns a good grade can publish it, and a bad one cannot pay to hide it.
How we build
Rules in the database. Interfaces designed, not assembled.
The schema is the product
Migrations are the source of truth and domain rules live in the database. If a state is illegal in the business, it should be impossible in the data — not merely discouraged by a form.
Tested against the real thing
Behaviour is proven by tests running against an actual local stack. Mocks confirm that the code does what the code does, which is not the question anyone is asking.
UI/UX by the same hand
The person who designed the spatial sequence designs the screen sequence. Internal tools are used forty times a day by someone under pressure — the interface has to be legible at a glance and impossible to fill in wrongly.
Boring where it counts
Static sites where static will do, Postgres rather than something novel, and no dependency we would not be willing to maintain in three years. Interesting infrastructure is a liability in a business that is not an infrastructure business.
Who this suits
Companies with a real process and no system for it.
A good fit
- The process exists and works, but lives in workbooks
- Two people disagree about the same number, monthly
- Off-the-shelf software fits 70% and the last 30% is the business
- You need the interface designed, not just the backend built
Probably not us
- You want a large team and a long roadmap
- The requirement is a well-served commodity — buy that instead
- Nobody internally owns the process being systematised
- The real problem is a decision nobody wants to make
Describe the spreadsheet.
Genuinely — send it, or describe it. The shape of the workbook people have built to survive tells us more about what the system needs to be than any requirements document.