About

I’m Kenneth, a software engineer and builder from Singapore.

I tend to move between two questions: what should exist, and how do we make it hold together once somebody actually uses it? The first question usually wins for a while. The second one catches up.

This site is where I write down the decisions, experiments, and occasional wrong turns while they are still close enough to remember.

What I’m building

Right now I’m rebuilding Omni, a project that started as an attempt to solve part of Shopmatey’s social commerce problem.

The earlier version of Omni was built on Bluesky’s open protocol during buildspace s4, where I demoed the first prototype. The new version is AI-focused. I know, that description is doing a lot of work. The actual goal is to make something more useful than a GPT wrapper.

It is still in progress. That is the most accurate status I have.

What came before

In 2023, I launched Shopmatey, a platform for dropshippers to quickly spin up stores without committing to a subscription like Shopify. It launched on Product Hunt and reached #2 Product of the Day.

That part was exciting. Then we hit the harder question: what should the product actually become?

Building the kind of app ecosystem that makes Shopify powerful was a much bigger problem than it first appeared. We also started attracting people who treated Shopmatey like a marketplace for used goods, which was not the vision. I tried to pull the idea back toward social commerce, including an integration with Rye.com’s API. Eventually, the initial version stopped feeling right.

Shopmatey did not become the final answer. It did give me a better question to work on, which is how Omni started.

The kind of work I like

My work sits somewhere between product experimentation and software architecture. I’ve worked across mobile development with Flutter and FlutterFlow, spent time with the native iOS and Android ecosystems around Swift, Kotlin, and Java, and built backend systems in TypeScript and Node.js.

On the technical side, I like boundaries that make the next change easier. When I started Omni, a well-modularized monolith made more sense than jumping straight into microservices. A single process was easier to run, while clear domain boundaries kept the code from becoming one large room with no doors.

That is not a rule for every project. It is just where my judgment has landed so far.

I care about simplicity, portability, and ownership. Code should be understandable enough to change or delete. Content should not be trapped inside the frontend that happens to render it. Interfaces matter too—typography, spacing, and the small details are part of the thing being built, not decoration added after the engineering is finished.

I’m also less interested in treating technical choices as identity. FlutterFlow was useful when I needed to get an idea onto both platforms. Later, owning more of the Flutter code became useful. Both decisions made sense at different points.

The current thing is Omni. I’m still working out what it becomes.

Back to work.