Jeremy Hon

Payroll module (Q4 2023 → Q1 2024)

By late 2023, the company needed a step-change within a single quarter. Payroll emerged as the clearest strategic focus, but the scope was realistically a two-quarter build.

The team was very hesistant to commit but I pushed hard for an aggressive delivery timeline anyway. To make this feasible, I drove a series of scope and sequencing decisions:

• Ruthlessly cut non-essential features, or sequenced them at the end
• Built onboarding first to allow pilot customers to onboard before full payroll rollout
• Accepted iteration post-launch rather than blocking on completeness

We started onboarding customers at the end of Q4 2023, bearing in mind that onboarding each customer would take a couple weeks. The first customer payroll was run for the month of Jan 2024.

Since then, we’ve iterated significantly on the module, launched a second country, and its become an essential part of the company’s offerings. Payroll is now adopted by ~50% of the customer base, customer churn dropped from ~20% to ~10%, and contributes ~20–30% of revenue.

Building payroll was intensely exciting and harrowing. It reminded me of what a tight team with ambitious goals could pull off. The key insight here was recognizing shipping onboarding first which was simpler (and customers take a few weeks to onboard properly).

Internal ERP / billing system

From 2018–2021, revenue tracking lived in spreadsheets manually maintained by the CRO. During the Series A process we were required to move off spreadsheets. An Oracle NetSuite quote came in at roughly SGD 50k, which felt disproportionate to our needs and stage.

Our deal structures were too bespoke and changed too often for a fast off-the-shelf rollout, so I pushed to build a custom internal system instead.

The system had to model multi-entity, multi-product agreements with varying terms across countries and currencies. We built it on HubSpot, integrated Stripe for billing and SignNow for contracts, wired it into the product for entitlement enforcement, and pushed data into BigQuery for real-time revenue visibility.

Delivered by roughly 0.5–1.5 engineers over a couple of quarters, it now runs contract signing, billing logic, and revenue reporting end to end.

If I was doing this today I would probably not build on top of HubSpot. Hubspot ultimately didn’t buy us that much more time, and it’s much clunkier and less flexible than if we’d built our own service.

Phone-number authentication via WhatsApp

Our user base is heavily phone-number-centric. We relied on Firebase SMS authentication, which worked in Singapore but became extremely costly in Malaysia and Indonesia. An SMS costs 5c in SG and 20c in Indonesia. Bearing in mind that we charge indonesian users less, this became untenable.

I built a phone-number authentication system that uses WhatsApp as a first-class auth channel, routes by country, and automatically falls back between WhatsApp and SMS on delivery failure. WhatsApp charges much more reasonable rates for indonesian users.

The result: authentication spend reduced by ~10×, delivery rates comparable to SMS-only flows, and no regression in user experience.

Note to self: Don’t build a service that depends on phone number auth.

Cost cutting & efficiency

During a broader cost-cutting push, I noticed our BigQuery spend growing into the low thousands per month despite relatively low query volume. We had a consultant come in, and while they were starting up their big review project, an engineer noticed a production path querying an unoptimized bigquery table. That dropped our costs overnight by 90%.

As part of the same push, We also achieved roughly a 50% reduction in total cloud spend without meaningful degradation in reliability or performance.

Behind every 10x cost decrease is a very dumb mistake