I built an offline-first POS app for Indonesian small businesses
For the last few months, I have been building KasirCepat — a simple POS app for warungs, small shops, and micro businesses in Indonesia.
The idea started from a simple observation:
Small businesses don't always need more features.
They need software they can trust.
Many modern POS applications are built around cloud systems, subscriptions, and business analytics.
That approach works for some companies.
But for a small shop owner, the daily problems are usually much simpler:
- "Can I still sell when the internet is down?"
- "Will my sales data still belong to me?"
- "Do I need to pay every month just to keep using basic features?"
- "Can my employee understand this app without training?"
So I decided to build something different.
Offline-first from day one
KasirCepat is designed to work without internet.
Not as a backup mode.
Not as an emergency feature.
Offline is the default.
A small shop should still be able to:
- add products,
- process transactions,
- calculate payments,
- view sales history,
even when the connection disappears.
Data belongs to the shop owner
One thing I care about is data ownership.
Sales history is not just numbers.
It contains information about:
- best-selling products,
- customer habits,
- business growth,
- daily revenue.
KasirCepat stores transaction data locally on the user's device.
No mandatory cloud account.
No requirement to upload store data.
The owner keeps control.
Free does not mean limited by design
A lot of apps follow this pattern:
Start free → add users → lock important features behind subscriptions.
I understand why companies do this.
But for small businesses, recurring costs can become a burden.
KasirCepat has a free version with:
- unlimited products,
- unlimited transactions,
- local backup and restore,
- basic reports.
The Pro version exists only for users who need additional features:
- multi-device cashier through local WiFi,
- automatic receipt printing,
- hardware barcode scanner support,
- advanced reports.
The goal is not to force upgrades.
The goal is to give users a choice.
Built for real people, not dashboards
The person using a cashier app may not be a technical person.
It could be:
- a shop owner,
- a family member,
- a new employee.
So the workflow is intentionally simple:
- Find product.
- Add to cart.
- Select payment.
- Finish transaction.
No complicated setup.
Current status
KasirCepat is available on:
- Android
- Windows
- Linux
Current numbers:
- ~100+ Android installs
- First paying Pro users
- Built as a solo developer project
It is still early.
There are many things I want to improve:
- better onboarding,
- more printer compatibility,
- more business workflows,
- better reporting.
Why I built this
I believe small businesses deserve good software too.
Not software that makes them dependent.
Not software that treats their data as a product.
Just software that helps them run their business better.
KasirCepat:
"Your shop. Your data. Your control."
The first paying users are the interesting signal here. Do you know what actually triggered those upgrades—multi-device/printer workflows, reporting, or something else? That might tell you whether the current free/Pro boundary matches how small shops value the product.
Good question.
The sample size is still small, so I don't want to overgeneralize yet. I have only a few paying Pro users at this stage, and I am still learning from their usage.
From the first users, the main reasons seem to be around operational needs rather than just extra features — especially workflows that save time during daily operations.
The Pro features that seem most relevant are:
For a single-person shop, the free version already covers most of the core needs. The Pro value becomes clearer when there is more than one person involved or when the shop wants to speed up repetitive tasks.
I agree that directly asking the first paying users why they upgraded is probably the best next step. It could reveal whether the current Free/Pro boundary actually matches how small shops value the product.
Thanks for the insight!
That’s a useful distinction, especially the focus on whether another creator actually changes an editing decision. If you’re open to it, what’s the best email to reach you on?
Good question. I'd bet on reporting being the sneaky one, once an owner sees which products actually move day to day, going back to guessing feels like a downgrade. Multi-device is probably more about shop size than intent to pay, a single cashier doesn't need it yet. Worth just asking the first few Pro users directly why they converted instead of assuming, the answer might reshape what "Pro" even means for a one-person shop vs a warung with staff.
That reporting signal is interesting, especially with real upgrades already happening. If you’re open to it, what’s the best email to reach you on?
Prefer not to post my email publicly, you can reach me on LinkedIn instead: https://www.linkedin.com/in/kaya-abdullah/
I prefer email for this. You can reach me at hello@beryxa.com — send me a quick note there and I’ll reply.
Offline-first products earn trust when the failure mode is explicit: users should know what is queued locally, what has synced, and how conflicts are resolved. I like the focus on the shop owner rather than dashboards; the strongest validation may be observing a busy day with a weak connection and noting every manual fallback. Which part of the sync or recovery experience has been hardest to explain to first-time users?
Thank you, this is a really good point.
One thing that is slightly different with KasirCepat is that we started with a local-first approach rather than an offline-sync approach.
The primary use case is a single device running the store, so transactions, products, and reports are stored locally on that device. Because there is no background cloud sync in the core workflow, there is no "waiting to sync" state or conflict resolution flow for the basic version.
For Kasir Bersama (multi-device), we use local WiFi inside the shop instead of relying on the internet. The challenge there is less about cloud conflicts and more about making the connection status and device roles easy to understand for non-technical users.
I agree that observing a busy day with a weak connection is probably the best validation. The hardest part is not making the system work technically, but making the experience understandable for someone who just wants to sell products quickly.
Thanks for bringing up this perspective — it gives me ideas for improving the onboarding and explaining how data flows between devices.
Offline-first solves the connectivity risk, but it shifts the trust test to device loss and recovery. I would give a shop owner a new phone or computer and ask them to restore last week's transactions without assistance. If they can recover the business in minutes, ‘your data, your control’ becomes a demonstrated outcome rather than only a privacy promise. Do you know what percentage of users create and test a backup before their first incident?
Good point. I agree that recovery is an important part of data ownership.
KasirCepat already has local backup and restore workflows for this scenario.
Users can:
The current challenge is not only building the recovery feature, but making sure non-technical shop owners actually understand the importance of creating backups before they need them.
I like your idea of testing this as a real scenario: give a user a new device and see if they can recover their store data without assistance. That is probably a better validation than just having the feature exist.
Thanks for bringing up this perspective.
Your strongest message is not ‘offline’ as a technical feature; it’s ‘you can keep selling when the connection fails.’ I’d test onboarding with a short scenario: a staff member makes a sale during an outage, then needs to transfer or restore later. Watching where they hesitate will give you both product changes and clearer wording for the storefront. Concrete failure stories may convert better than a longer feature list.
This is a great point.
I agree that "offline-first" is mainly a technical explanation, while the real value for a shop owner is much simpler:
"You can keep selling even when the internet connection fails."
The technology matters because it enables that outcome, but the user experience should start from the real situation they face.
I like the idea of testing with a concrete scenario:
That kind of scenario probably communicates the value better than a list of technical features.
KasirCepat already supports local backup/restore and export workflows, but I think the next challenge is making these capabilities easier to understand for non-technical users.
Thanks for the suggestion. This is a good reminder that product messaging should start from the user's daily problem, not the implementation detail.
Local-only data wins the trust argument, but it hands you a support problem: the day a warung owner drops their phone in a bucket of water, the entire sales history is gone and you're the one who gets blamed. That fear is a stronger Pro upsell than barcode scanners, so I'd sell owner-controlled encrypted backup, where the shop holds the key and you can't read it, as the paid tier. Selling insurance against loss converts better than selling convenience, especially to a market that already distrusts the cloud.
This is a very interesting perspective.
I agree that data recovery is probably a stronger trust signal than convenience features.
KasirCepat already has manual backup and restore:
For the future Pro version, I have been thinking about scheduled automatic backups.
The challenge is not the backup process itself, but making the scheduling reliable on Android. Background execution is complicated because different manufacturers aggressively optimize battery usage and may stop background tasks.
I don't want to build a feature that looks automatic but silently fails on some devices.
So I am still exploring the best approach:
I agree with your point though: protecting the owner's business data is probably a more meaningful value than just selling extra convenience features.
Thanks for the insight.
Offline as the default is the right call for this audience, and it comes with a quiet obligation: you are now the shop's system of record. I see local backup and restore in the free tier, which is good, but a backup that lives on the same phone does not survive the failure that actually happens. The worst day of your merchant's year is a dropped, stolen or wiped phone, and on that day "your data never leaves the device" flips from a trust feature into the reason a year of transactions is gone.
The useful thing is that your Pro tier already contains the answer. Multi-device over local WiFi is a second copy wearing a sync costume, and I would bet "your records survive a broken phone" sells Pro harder than advanced reporting to an owner who has been burned once. Even in free, a one-tap export to the phone's own file storage or an SD card would remove most of the risk, and it costs you nothing in positioning because the data still never touches your servers.
One smaller thing, since you also ship Windows and Linux builds. To a non-technical shop owner, the warning screen on an unsigned Windows installer reads as "this will steal my money". Code signing is tedious and worth starting early, because signing reputation accrues with installs and elapsed time, so it is cheap to begin now and expensive to begin later.
Has anyone asked you for an export or an off-device backup yet, or does that fear only arrive after someone's first lost device?
This is probably one of the most important trade-offs of building local-first software.
I agree that "data stays on your device" is only part of the story. The other side is making sure the owner has a reliable way to recover when the device itself fails.
Currently KasirCepat supports:
But you are right that a backup stored on the same device does not protect against the most common real-world failures.
The Pro direction is actually moving toward this area. We have been exploring more automatic backup workflows, but I want to make sure the implementation is reliable, especially on Android where background execution and battery optimization vary a lot between manufacturers.
The idea of positioning Pro around "protecting your business records" is interesting. Features like printing and scanners improve workflow, but protecting months of transaction history addresses a much deeper concern.
For Kasir Bersama, the local WiFi multi-device model does create another copy of data during operation, although it was originally designed for collaboration rather than backup.
Regarding Windows code signing, that's also a good point. We currently focus mostly on Android, but as desktop usage grows, reducing trust friction during installation will become more important.
So far, most users have not explicitly asked for off-device backup yet. I think, as you mentioned, this kind of concern often appears after someone experiences the first data loss event.
Thanks for the thoughtful feedback. This is exactly the kind of edge case that helps shape the product beyond just adding features.
The local-first vs offline-sync distinction is easy to miss, but it changes what users need to understand. For the single-device version, I’d make backup and restore plus device-loss recovery very visible in onboarding, since that’s the tradeoff people may worry about when data never leaves the shop. The local WiFi approach for multi-device sounds much easier to explain than cloud sync conflicts.
This is a good point, and I think you captured the distinction clearly.
The original idea behind KasirCepat was not to build an offline version of a cloud POS. The core principle was closer to a digital cash book owned by the shop owner:
"Your shop, your data, your control."
The app is designed to keep the primary data under the owner's control instead of making the cloud the source of truth.
That said, I agree that local-first creates a responsibility around recovery. If the device is lost, damaged, or replaced, the owner still needs a clear path to recover their business records.
KasirCepat already has local backup/restore and CSV export workflows, but I am still exploring what the best backup model should be while keeping the privacy principle intact.
For example:
I like the local WiFi approach for multi-device because it is easier to explain: devices inside the shop work together without introducing cloud sync complexity and conflict resolution.
The challenge is finding the right balance between:
Thanks for the insight. This is exactly the kind of trade-off I want to think through before adding more backup features.
Really thoughtful approach. Making offline-first functionality the default instead of treating it as a backup feature is especially valuable for small businesses where reliable internet can't always be assumed. I also like the focus on data ownership and keeping the core workflow simple. Great work building this as a solo developer, and congrats on getting your first Pro users! 🚀
Thank you! I really appreciate it.
One thing I noticed while building for small businesses is that reliability is often more important than having the most features.
For many small shops, internet connectivity is not something they can always control, so I wanted offline to be the foundation instead of an exception.
The same applies to data ownership. A shop's sales history is part of their business, so keeping control of that data felt like an important design decision.
Still early days, but I'm excited to keep improving KasirCepat based on real usage from shop owners. Thanks again for the kind words!