Why We Build for Real Constraints

Most software is designed for ideal conditions — stable connectivity, plenty of bandwidth, users sitting at a desk with time to read a tooltip.

We work in Indonesia. That assumption breaks quickly.

The gap between demos and deployment

It’s easy to build something that looks great in a demo. The real test is what happens when your server goes down at 2am, when your user is on 3G in a rural area, or when the person using your product has never touched a smartphone before.

These aren’t edge cases for us. They’re the default.

When we built BIOSENSOR — our environmental monitoring platform — we couldn’t assume reliable connectivity at sensor sites. So we designed for offline-first data collection with sync on reconnect. When we built Ruang Tunggu, we couldn’t assume users would have the patience to navigate a complex booking flow. So we stripped it down until it worked in three taps.

Constraints force clarity

Here’s what we’ve learned: constraints are a design tool.

When you can’t rely on bandwidth, you stop adding features that don’t earn their weight. When your users have limited screen time, you stop burying the important action five clicks deep. When your infrastructure might fail, you build fallbacks instead of assuming uptime.

The result is software that works — not software that works most of the time under favorable conditions.

What this means in practice

We ask different questions before we start:

• Who actually uses this, and where are they when they use it?
• What happens when the internet drops mid-task?
• What’s the minimum viable version of this feature?

Then we build from there.

It’s slower at first. But the things we ship tend to stay shipped.