Chasing the Elusive PMF

Chasing the Elusive PMF

Chasing the Elusive PMF

The hard-learned truth that collecting LOIs is easy, but building something users actually want to pay for requires months of grinding through bugs, optimizations, and unexpected user behaviors.

28 Aug 2025
Poh Yong Han (CEO)

Improper PPE in my family's shop (at least I'm not barefoot for this one)

Early on, armed with nothing but a Figma prototype, a deck, and boundless optimism, Liam and I knocked on doors at countless industrial estates across Singapore. The response seemed overwhelming: within a month, we had collected 14 LOIs, with a 100% conversion rate. We were psyched - surely this meant we had found PMF.

We set out to build after that. Within weeks, we hired our founding engineer to build a quick prototype. Having not built a tech product 0 to 1 before, I foolishly thought the building was the easy part.

I could not have been more wrong.

Our small, 2-man engineering team was able to ship out a working prototype with our core features fairly fast, but we quickly found out that building something that kind of worked was definitely not the same thing as building something that worked well. The hierarchy goes something like that: 1) build something, anything, a POC 2) build something that users are willing to even try 3) build something that users are happy to pay for.

Going from 0 to 1 took us maybe 3 months, and going from 1 to 2 took us another 3. Our clients are contractors fielding hundreds of phone calls, messages, running around from site to site. They were impatient when loading times exceeding two seconds, when hitting a button caused the app to freeze. We spent weeks optimising loading times, finding bugs, fixing bugs.

When the client (finally!) felt we were ready enough for them to try, we moved on to our first pilots. They proved both necessary, and slightly demoralising. I was touched by the hacky workarounds that our pilot users used. Because we hadn’t had time then to build out annotation features yet, they used their fingers instead, as arrows. It was both heartwarming and humbling – they wanted our product to work so badly they’d improvise solutions we hadn’t built yet.


Although people were happy to try our product, we knew our product wasn’t ready yet. They were doing us a favour, not solving a burning problem. Pinning photos to a floor plan was fantastic, and so was instant multi-lingual translation. But while they said that assigning tasks was helpful, we realised nobody was using them.

This could be because the pilot we started with was a small, renovation project, where workflows tended to be looser and more informal. That was true, and it would have been tempting to stop there. But we also realised that the current way to create tasks required too much manual entry. The question then: how could we help users track tasks better (since this was essential for their progress tracking), without requiring any change in user behaviour?

We observed that on site, most of our users were not standing around sending text messages. Instead, they were sending voice messages, sometimes on the go, often in rapid fire Chinese or dialect, giving instructions on what needed to be done and summarising what had been done.

We tapped on that insight and worked on introducing a voice-to-task feature, where users could simply record a voice message as they had always done. On the backend, we would parse that message through AI to identify which task(s) had been given, to whom, by when. I.e. all of the magic, with no extra work required, which significantly increased adoption. While not necessarily revolutionary from a technical perspective, from our customers’ POV, it was one of those ‘wow’ moments where technology made the mundane magical.

New issues emerge. With voice-to-task, questions of accent, localisation mean that we have to fine-tune existing APIs to improve accuracy, particularly for the local context where we are operating our pilots. Singapore’s beautiful, multicultural polyglot means that people switch frequently between multiple languages and dialects in one message, not to mention the incredibly diverse and international construction teams that help build our city.

One particular problem we tried to solve for was how to find a sufficiently good Hokkien translation engines. We tested Meta’s solution, Southern Min APIs built by Chinese companies, explored local startup offerings – but so far, none has been sufficiently accurate. Sadly, the realities of startup life means that we don’t have the bandwidth to prioritise this now, and our users have kindly agreed to speak in Chinese when using our app. But if anyone knows any good Hokkien translation engine, it would be our dream to integrate them.

Call this naiveté, call this overthinking. Some might find us foolish in chasing perfection, but the team is really motivated to build a product that users want. We are still continuing to iterate daily, there are always new UI to refine and new bugs to fix. But we have found out that tiny shifts accumulate, and make a huge difference in encouraging adoption.

Stay up-to-date with OnSite

Stay up-to-date with OnSite

Stay up-to-date with OnSite