5 Mistakes Indonesian Businesses Make When Building Their First App
Indonesian businesses are building apps at a pace I've never seen before. The pandemic accelerated digital adoption by years, and now everyone — from the warung on the corner to mid-sized distributors — wants a mobile app or internal system.
That's exciting. But it's also created a wave of expensive mistakes.
I've spent the last few years building software for Indonesian businesses, and I see the same patterns repeated over and over. Owners with real problems and real budgets, making decisions that cost them twice what they should have paid — or walking away with software that nobody uses.
This article is for any Indonesian business owner or manager who's thinking about building their first app. Read this before you talk to a developer.
Mistake #1: Building an App When You Need a Process First
This is the most common and the most expensive mistake.
A business owner sees a problem — employees are late, inventory is wrong, customer orders are getting lost — and immediately concludes: we need an app.
But an app doesn't fix a broken process. It automates it. And automating a broken process just makes the chaos faster.
Before you build anything, ask: do we have a clear, written process for this? Do my employees actually follow it? If the answer to either question is no, the app will fail — not because of the technology, but because the human side isn't ready.
I talked to a restaurant owner in Batam who spent Rp 45 juta on a custom ordering system. Six months later, the staff had gone back to pen and paper. Why? Because nobody had defined who was responsible for updating the menu, what happened when an item ran out, or how the kitchen should prioritize orders during a rush. The app surfaced all those gaps — and instead of solving them, the team just abandoned the tool.
What to do instead: Write down your process manually first. Use a Google Sheet, a WhatsApp group, anything. If people follow the manual version consistently, then you have something worth automating.
Mistake #2: Hiring the Cheapest Developer They Can Find
I understand the instinct. Software feels expensive, and there's no shortage of freelancers on Fastwork, Fiverr, or local Facebook groups offering to build your app for Rp 5–10 juta.
The problem isn't the price. The problem is what you get for it.
At that price point, you're typically getting someone who will copy-paste a template, do minimal testing, and disappear after handover. There's no documentation, no clean code, and no real understanding of your business problem. When you need to change something six months later — and you will — either the original developer is gone or the quote for changes is 3x what it should be because the codebase is a mess.
I've been brought in to "fix" apps that cost clients less than Rp 10 juta to build. In every single case, the fix cost more than starting from scratch would have.
The real cost of cheap development isn't the initial quote. It's the months of frustration, the staff who won't use the broken tool, and the second project you'll eventually have to fund.
What to do instead: Set a realistic budget. For a simple internal tool or mobile app in Indonesia, expect Rp 30–80 juta for something built properly. Get references. Ask to see previous work. Talk to someone who used the app they built — not just the client who commissioned it.
Mistake #3: Asking for Everything in Version 1
I sit down with a business owner, and they describe their dream app. It will handle HR, payroll, inventory, customer orders, loyalty points, reporting, and it needs to work offline, support multiple branches, and have a beautiful UI.
"When do you need this?" I ask.
"ASAP," they say. "Can you finish in two months?"
This is a fantasy. And pursuing it is how you end up six months later with a half-built product, an exhausted developer, and a budget that's been blown twice over.
The instinct to include everything makes sense — you're paying for development, so you want to get as much as possible out of it. But software doesn't work that way. Complexity compounds. Every feature you add doesn't just add its own development time; it adds integration time, testing time, and the cost of keeping everything working together.
The businesses I've seen launch successful internal tools all have one thing in common: they launched a version that did one thing well. Attendance tracking only. Order management only. Inventory only. Then they expanded from there once they saw real usage.
What to do instead: Write down every feature you want. Then pick the three that, if nothing else worked, would still make the tool valuable. Build those first. Schedule everything else for version 2 after you've seen real users interact with version 1.
Mistake #4: Ignoring the People Who Will Actually Use It
The business owner commissions the app. The developer builds what the owner asks for. The app launches.
The staff doesn't use it.
This scenario plays out constantly, and the root cause is almost always the same: nobody asked the end users what they needed.
Your cashier, your warehouse staff, your field sales team — they have specific constraints you probably don't think about. Maybe they're using low-end Android phones with limited storage. Maybe they're working in bright sunlight where small text is impossible to read. Maybe they're entering data with one hand because the other hand is carrying something. Maybe they have varying levels of digital literacy and will abandon any app with more than three steps.
An app that doesn't account for how real users work in real conditions will get workarounds — WhatsApp messages, handwritten notes, spreadsheets — that defeat the purpose of having an app at all.
What to do instead: Before development starts, spend time with the people who will use the tool. Watch how they work. Ask what frustrates them about the current process. Show them mockups or rough prototypes before a single line of code is written. Their feedback at this stage is free. Their rejection after launch is expensive.
Mistake #5: Treating Launch as the Finish Line
This one surprises a lot of first-time software buyers. You pay for development, the app is delivered, and you think the project is done.
It's not.
Software is not a one-time purchase like furniture. It's more like a vehicle — it needs maintenance, and it will eventually need upgrades. Operating systems update and break things. Your business grows and your requirements change. Bugs appear that weren't caught in testing. The regulatory environment changes (especially relevant now with Indonesia's evolving data privacy laws under UU PDP).
I've seen businesses get caught off-guard by this repeatedly. The developer hands over the finished app, the relationship ends, and six months later something breaks and there's nobody to call. Or the business wants to add a feature and realizes they don't even have access to the source code.
What to do instead: Before you sign any contract, clarify three things:
- Who owns the source code? Make sure it's you. Get it delivered to a repository you control.
- What's the maintenance arrangement? Is the developer available for bug fixes after launch? At what cost?
- What does documentation look like? If you ever need to bring in a different developer, can they understand the codebase?
These aren't complicated questions, but a lot of business owners don't think to ask them until it's too late.
The Common Thread
If you look at these five mistakes, they all share a common root: treating software as a product to buy rather than a system to build and maintain.
Software at its best is a living reflection of how your business operates. It takes time, iteration, and real feedback to get right. The businesses that succeed with their first app aren't necessarily the ones with the biggest budgets — they're the ones who treat the project as a partnership, stay involved throughout the process, and think beyond launch day.
Indonesia's digital economy is growing fast. Businesses that build good internal tools and customer-facing apps now will have a real operational advantage over the ones that wait. But rushing, cutting corners, or approaching it without a clear process will cost you more time and money than just waiting and doing it right.
At 90fri.day, we build software for Indonesian businesses that need practical tools — not enterprise complexity. If you're thinking about your first app and want an honest conversation about what it takes, get in touch.