Building for Brunei: Tools that actually help

There is something satisfying about building a product that people genuinely use.

Not because it looks impressive in a presentation. Not because it has a long list of features. Not because it uses the latest technology.

But because someone opens it, gets what they need, and moves on with their day.

That is the kind of product I increasingly want to build for Brunei.

Over time, I have become less interested in technology for the sake of technology and more interested in practical systems that remove friction from everyday life. The idea is simple: if a product can make something clearer, faster, easier, or less frustrating for real people, then it is probably worth building.

In a small country like Brunei, that mindset matters even more.

We do not always need giant platforms. Sometimes we need smaller, focused tools that understand our habits, our language, our routines, and the specific problems people here deal with every day.

That is where useful products begin.

Start with the problem, not the technology

One of the easiest mistakes to make when building something is to begin with the technology.

You see a new framework, API, AI capability, or design trend and immediately start thinking about what could be built with it.

I think the better question is:

What problem is actually worth solving?

That sounds obvious, but it changes everything.

A product should not exist just because it is technically possible. It should exist because somebody has a real reason to use it.

Take border travel as an example.

People travelling from Brunei to Miri, Limbang, Lawas, or other nearby destinations often want to know something very simple:

How bad is the queue right now?

That is not a complicated question.

But the answer is often spread across WhatsApp groups, social media comments, friends who crossed earlier, and general traffic information.

That repeated uncertainty was enough to justify building something more structured.

The value is not in having a clever dashboard. The value is in helping someone make a better decision before leaving home.

That distinction is important.

The product is not the technology. The product is the reduction of uncertainty.

Local products should feel local

A product built for Brunei should understand Brunei.

That does not mean covering everything in national colours or forcing local slang into every screen.

It means understanding how people behave.

For example, people here often mix online and offline interactions naturally.

A seller might post an item online, answer questions through WhatsApp, arrange payment separately, and meet the buyer for pickup.

Trying to force that user into a completely unfamiliar international e-commerce workflow may actually make the experience worse.

A better local product works with existing behaviour and improves it gradually.

That principle has influenced how I think about TamuBN.

The goal is not to recreate a giant global marketplace.

The goal is to make local selling more organised and discoverable.

A small seller should be able to present products clearly, receive enquiries, manage orders, and reach more buyers without needing to become an expert in e-commerce.

The platform should remove friction, not introduce new friction.

This applies to almost any local digital product.

The more closely the system reflects how people already think and work, the easier adoption becomes.

Simplicity is harder than it looks

There is a temptation when building software to keep adding features.

Every idea sounds useful.

• Add another dashboard.
• Add another filter.
• Add another notification.
• Add another page.

Eventually the system becomes powerful, but exhausting.

I have learned that good product design often requires doing the opposite.

Remove things.

Reduce decisions.

Make the next step obvious.

A useful interface should not make someone stop and study it before they can continue.

If a person opens a dashboard, the system should quickly answer:

• What is happening?
• What matters now?
• What should I do next?

That principle also applies to internal systems.

A customer management tracker, for example, can easily become another complicated spreadsheet with more colours and more columns.

But the actual need is usually much simpler.

The person managing the work wants to know:

• What is active?
• What is overdue?
• Who am I waiting on?
• What needs follow-up today?
• What engagement is coming up?
• What does management need to know?

Once those questions are answered clearly, the tool becomes useful.

Without that clarity, it is just another place to store information.

Good systems reduce memory work

One of the things I find most interesting about digital tools is how much mental effort they can remove.

A surprising amount of work depends on people remembering things.

• Remember to follow up.
• Remember which email contained the latest update.
• Remember when the workshop is happening.
• Remember who is waiting on whom.
• Remember what you told management last week.

That is risky.

People are not bad at work because they forget things. They forget things because they are managing too many things at once.

A useful system should carry some of that memory.

It should preserve history.

It should surface deadlines.

It should make outstanding actions visible.

It should help someone return after a week away and understand where everything stands.

This is one reason I care so much about activity history and next-action design.

Information is not useful simply because it has been stored.

It becomes useful when it can be recovered at the right moment.

Small improvements can have large effects

Not every meaningful product improvement looks dramatic.

Sometimes the best change is a small one.

• A better button label.
• A clearer status.
• A countdown to an engagement.
• A link from a dashboard number directly to the underlying records.
• A reminder that appears at the right time.
• A better mobile layout.
• A shorter form.
• A cleaner report.

Individually, these improvements can seem minor.

Together, they change how a system feels.

This is something I have learned repeatedly while building.

Users often do not ask for “better UX” in abstract terms.

They say things like:

“I cannot find this.”
“This takes too long.”
“I keep forgetting this.”
“I do not know what happens next.”
“Can this just show me the important ones?”

Those are design requirements.

The job is to translate frustration into better structure.

Building for real use changes your priorities

The moment people actually start using a product, your priorities change.

Before launch, you care about how the system looks.

After launch, you care about where people get stuck.

You begin noticing different things.

• Is the page fast enough?
• Does the mobile version work properly?
• Are users understanding the labels?
• Is the information fresh?
• Are people coming back?
• Are they using the feature you thought was important?
• Did you build something nobody actually needed?

This is why I like building in public and improving continuously.

A product does not become finished because version 1 was deployed.

Version 1 is when the real learning begins.

The feedback loop matters more than the first design.

Brunei has room for more focused digital products

I think Brunei has plenty of opportunities for practical digital products.

Not necessarily massive startups.

Useful services.

Local tools.

Systems that solve specific problems well.

There are still many areas where people rely on a combination of manual processes, chat messages, spreadsheets, social media posts, and word of mouth.

That is not always bad.

Sometimes those methods work perfectly well.

But when the same frustration keeps appearing, there may be an opportunity to build something better.

The important thing is not to digitise everything automatically.

It is to recognise where technology can genuinely improve the experience.

Sometimes the right answer is a full platform.

Sometimes it is a simple webpage.

Sometimes it is a dashboard.

Sometimes it is just a better way of presenting information.

The scale of the technology should match the scale of the problem.

Trust matters more than features

A local product can have many features and still fail if people do not trust it.

Trust comes from consistency.

If information says it was updated five minutes ago, it should actually be fresh.

If a button says something will happen, that action should behave predictably.

If a system asks for information, users should understand why.

If there is uncertainty, the product should communicate it honestly.

This is especially important for community-facing tools.

A product becomes part of someone’s routine only when they feel confident relying on it.

That trust takes time to build and very little time to lose.

So sometimes improving reliability is more important than adding a new feature.

That may not be exciting from a development perspective, but it matters more to the user.

Build for the person in front of the screen

At the end of the day, software is used by people.

That sounds obvious, but it is easy to forget when you are deep inside code, databases, APIs, hosting, debugging, and deployment.

There is always a human being on the other side.

• Someone trying to get home earlier.
• Someone trying to sell something.
• Someone trying to finish work.
• Someone trying to understand what needs attention.
• Someone who does not care how difficult the system was to build.

They care whether it helps.

That perspective keeps the work grounded.

Technology is only successful when it improves the experience of the person using it.

What I want to keep building

The projects I find most meaningful tend to share the same qualities.

They solve something real.

They are focused.

They understand local context.

They make information easier to use.

They improve through feedback.

And they do not require the user to care about the technology behind them.

That is the direction I want to keep moving in.

Better tools for local businesses.

Better information for travellers.

Better systems for people doing real work.

Better ways to reduce unnecessary friction.

Not every idea needs to become a company.

Not every project needs millions of users.

Sometimes success is simply creating something useful enough that people choose to keep using it.

That is a good outcome.

Better tools, better days

I like the phrase:

Ideas. Execution. Better Days.

Because ideas alone are easy.

Execution is the difficult part.

And the point of execution is not simply to produce software.

The point is to create a better outcome.

• A smoother journey.
• A clearer process.
• A stronger local business.
• A more organised day.
• A little less uncertainty.
• A little more control.

Those improvements may feel small.

But everyday life is made up of small things.

If technology can improve enough of those small moments, the overall impact becomes meaningful.

That is what building for Brunei means to me.

Not building technology because we can.

Building useful things because they help.

And then listening, improving, and building the next version a little better than the one before.