One afternoon, the owner of a restaurant with three branches in Bandar Lampung opened the Play Store and typed in a competitor's name. The app came up: delivery ordering, loyalty points, and promo claims right from the phone. He put down the phone and asked us: "If they can do it, why don't I have one?"
It's a fair question, but there's a more important one to ask first: does the business really need a mobile app, or would a responsive website be enough? A mobile app development company will happily take your order, but a responsible provider will actually pause you for a moment and map out the problem first. This article helps you decide clearly, before you contact anyone.
First: Do You Really Need a Mobile App?
Think of a mobile app as a store inside a mall. It gets lots of foot traffic, looks impressive, and is open whenever customers want it. A mobile-first website is more like a roadside shop: cheaper to set up, still findable, but the reach and closeness to customers aren't the same.
There are three options that people often mix up, and each has its own place.
Responsive Website
A website that adapts its layout to phone screens. Quick to build, relatively cheap, and most importantly: easy to find on Google. For company profiles, product catalogs, blogs, or online stores with reasonable transaction volumes, a responsive website is almost always the most sensible answer.
If a good website can serve your needs, don't rush into building an app. Many businesses spend hundreds of millions of rupiah on an app that a well-made web page could have handled.
Progressive Web App (PWA)
A PWA is a website that behaves like an app. Users can "install" its icon on their home screen, it keeps working offline, and you can send notifications. All without going through the Play Store or App Store, and without developer license fees.
A PWA is a smart compromise for businesses with limited budgets. Its limitations: access to phone features isn't as complete as a native app, and iOS treats PWAs more restrictively than Android does.
Native App
An app downloaded from the Play Store or App Store, built specifically for that platform. It can read GPS, camera, and sensors, make full use of push notifications, and run smoothly because it's written with technology created for that device.
You need a native app if most of the following apply:
- Customers interact with your business repeatedly each week, not once in a while
- Your transactions or services depend heavily on the phone: location, camera, fast payments
- Loyalty is your growth engine: points, membership, personalized promos
- Your business needs to appear in customers' minds through notifications, not wait for them to come
The restaurant owner met almost every criterion. A restaurant with customers coming twice a week, a points system, and delivery service is fertile ground for an app. A building materials store whose customers visit once every two months? A website is probably enough.
Android, iOS, or Both?
The next decision is the stage: who is this app built for?
In Indonesia, Android controls more than 85 percent of the smartphone market. This figure holds steady year after year, and the implication is simple: if you must pick one platform to start with, Android is almost always the first choice for the domestic market. iOS users in Indonesia are concentrated in big cities and higher-spending segments, which is interesting for premium businesses.
Three common strategies:
- Android first. Faster release, lower cost, and you learn from real data before investing in a second platform. Good for businesses with limited budgets or uncertainty about market adoption.
- Both at once. If the app is the backbone of your business and the market is clear, building both platforms simultaneously makes sense. The cost is nearly double, though.
- Android first, iOS later. The middle path favored by many Indonesian startups: launch Android, evaluate the metrics, and build the iOS app after the product proves itself.
This choice is best discussed with your mobile app development provider, because the answer depends heavily on your customer profile. A B2B app for a sales force, for instance, could be dominated by iOS users because the company provides the devices.
One note on local context: Indonesia's payment ecosystem (QRIS, GoPay, OVO, DANA) and intercity logistics services shape how apps are designed. Discuss which payment methods you want to support from the start, because these integrations genuinely affect cost and time. If you're looking for Android app development for the local market, make sure the provider understands this ecosystem, not just how to write code.
Technology: Native or Cross-Platform?
This is the engineers' favorite question, and unfortunately the one that often confuses clients the most. Let's simplify it.
Native: Kotlin and Swift
Android apps are written in Kotlin, iOS apps in Swift. Each platform gets built with technology created for it. The result: the best performance, full access to device features, and an experience that feels most "at home" in the operating system.
The price: two apps, two codebases, two teams or twice the build time. Maintenance cost and time also double, because every feature change must be done twice.
Cross-Platform: Flutter and React Native
One codebase, two apps. Flutter is developed by Google, React Native by Meta, and both are mature enough for production. Apps built this way compile into genuine Android and iOS apps, not wrapped websites.
For most Indonesian business needs, cross-platform is the most sensible choice. Unless your app depends on extreme graphical performance (3D games, video processing), users can barely tell the difference between native and cross-platform, but your budget certainly can.
A good mobile app development firm will be honest about this trade-off. If your needs genuinely require native (for example, special hardware integration), they'll say so, rather than forcing one technology for their own convenience.
The next natural question: where does the team come from? Choosing an Indonesian mobile developer has real advantages: communication in the same language, minimal time difference, an understanding of local user behavior, and the ease of meeting in person when needed. For businesses in Lampung, that proximity is tangible during discovery and when the app needs to adapt to local customer habits.
What Does a Healthy Development Process Look Like?
A serious provider doesn't open their laptop the moment the contract is signed. There's a process, and that process is itself a marker of quality. At Kartech., we divide it into four stages: Frame, Shape, Build, and Operate. In general, a healthy flow looks like this.
1. Discovery
The team understands your business problem: who the users are, what their behavior is, and what success looks like for this app. This stage produces a scope document: which features go into the first release, and more importantly, which features are deliberately left out.
2. UI/UX Design
Wireframes first, then visuals. In this stage you see the user journey: how someone signs up, orders, pays. It's cheaper to change a wireframe than to change finished code, so make the most of this stage.
3. Development
Features are built incrementally, usually in weekly sprints. With a collaborative mobile app development partner, you see real progress every week or two, rather than waiting for a surprise at the end of the project.
4. Testing
The app is tested across various devices and operating system versions. Bugs that slip into production aren't just a technical nuisance: on the Play Store, a one-star review because an app crashes often can sink a newly launched app.
5. Publish
The app is submitted to the Play Store and App Store. Both have review processes: the Play Store usually takes one to seven days, and the App Store can be similar or slightly longer. Your release schedule must account for this.
After release, life has only just begun. An app needs maintenance: adapting to new operating system versions, fixing bugs that show up on certain devices, and developing features based on user feedback. Ask from the start what the provider's after-sales service covers.
Realistic Costs and Timelines
Let's talk numbers, because this is what gets misunderstood most. In the Indonesian market, mobile app development for Android and iOS ranges from Rp20 million to Rp300 million. That range is wide, and it should be, because "app" can mean many things.
As a rough guide:
- Simple apps (Rp20-60 million): one platform, limited core features, such as a product catalog with manual ordering. Timeline around 2-3 months.
- Mid-range apps (Rp60-150 million): two platforms, or one platform with full features: user accounts, online payments, push notifications, admin dashboard. Timeline 3-5 months.
- Complex apps (Rp150-300 million and up): marketplaces, apps with legacy system integrations, real-time tracking, or hardware-involving features. Timeline 5-8 months or more.
Beyond the build, there are costs people often forget:
- Google developer account: US$25, a one-time lifetime payment
- Apple developer account: US$99 per year
- Monthly maintenance: usually 5-10 percent of the build cost per month, or agreed as a package
- Server and third-party services: notifications, storage, payment gateways
What drives the number up or down? Four things: the number of platforms, feature depth, backend complexity, and integrations. An app without login or backend can be twice as cheap as a similar app with user accounts and an admin dashboard. Real-time features like courier tracking or chat add cost significantly. Ask for a quote that separates these components, so you know exactly what you're paying for.
Beware of offers that are too cheap. A properly built Android and iOS app requires real work: design, development, cross-device testing, and publication. A Rp5 million price for an "app" usually means a website wrapped in WebView, with no process, no testing, and no accountability after release.
Preparation Before Contacting a Developer
Before reaching out to any mobile app development service, prepare these five things. This isn't a formality: the quality of your answers determines the quality of the proposal you receive.
- Business goal. What is this app for? Increasing sales? Reducing your team's workload? Strengthening loyalty? A clear goal makes every later decision easier.
- User profile. Who will use this app? End customers, the sales team, or internal staff? Their needs are very different.
- Priority features. If you could only choose three features, which would they be? This is good practice, because a good provider will recommend a lean first release.
- References. Which apps do you like, and what makes them feel good to use? It's easier to design with examples than with abstract descriptions.
- Budget and deadline. What range have you set aside, and when must the app launch? Honesty at the start saves disappointment along the way.
With these five answers, a professional provider can put together a relevant proposal. Without them, you'll only receive the same generic offer given to every client.
How to Choose a Mobile App Development Partner
Once all the decisions above are settled, it's time to choose a partner. Here are the criteria we recommend evaluating:
Relevant Portfolio
Ask for examples of apps already live on the Play Store or App Store, then download and use them yourself. Check the reviews. An app that has survived two years with good reviews is far stronger proof than a row of client logos on a website.
A Clear Process
Ask how they work: what the stages are, how you see progress, what happens if scope changes midway. A provider with a documented process is far easier to work with than one running on enthusiasm.
Code Ownership
Make sure the source code, developer accounts, and all assets become yours. Some providers "tie up" clients by withholding access, making it hard for you to switch or develop the app with someone else. That's not a healthy way to work.
Human Communication
You'll work with this team for months. Notice how they answer your questions during the quoting stage: are they listening, or busy selling packages? Communication patterns at the start usually persist to the end.
Cost Clarity
Ask for a breakdown: what's included, what's not, what happens when features are added, how much maintenance costs. A transparent quote shows confidence in its own quality.
After Launch: How to Measure Success
A launched app is not the finish line; it's the starting point of learning. Without clear metrics, you won't know whether this investment is working or quietly draining the budget.
Start with three simple metrics:
- Retention. What percentage of users still open the app 30 days after downloading? A healthy app typically keeps 20-30 percent of its users in the first month. If the number is far below that, the problem is almost always in the first experience: complicated registration, slow loading, or promises unfulfilled.
- Activation. How many users reach the "aha" moment, the core action that makes the app valuable? For a restaurant app, that's not just downloading, it's successfully placing an order. Tracking this point shows where users get stuck.
- Technical quality. Monitor the crash rate and complaints in app store reviews. A crash rate below one percent is a healthy standard; above that, fix it before adding new features.
Also set up feedback channels: an in-app report-a-problem button, periodic surveys, and easily findable communication channels. Users who feel heard are users who stay.
Common Pitfalls
A few mistakes we see repeatedly, so you can avoid them:
Starting from technology, not from the problem. "I want an app built with Flutter" is a sentence we hear often. Technology is a tool; start from the business problem and let the experts choose the tool.
Piling features into the first release. Every feature adds cost, time, and risk. A lean, reliable first release always beats a big half-baked one. Other features can follow once you're looking at real data.
Ignoring maintenance. An app is not a one-off project. Operating systems change every year, new devices appear, and users report issues. Without a maintenance budget, your app slowly becomes obsolete.
Not thinking about distribution. A great app is useless if nobody downloads it. Think from the start about how people will learn this app exists: from the store, from the cashier, from social media, or from ads.
Start from Your Problem
Back to the restaurant owner. After discussion, it turned out his main need wasn't a delivery-ordering app, but a loyalty system that would keep customers from switching to the competitor. A simple Android app with points, promos, and ordering became the right starting point, with iOS following once the data said so.
A good decision about a mobile app always begins with the right question, not with the desire to own an app. If you're standing at that crossroads, the Kartech. team in Bandar Lampung is ready to help map out the problem first. Start from our contact page, or look at our services page to understand how we work. We start from your problem, not from a package.
