Building KosPro: A Boarding-House Management App from Real Problem to Play Store

Most articles on this blog are about how to work with a software house. This time we open our own kitchen. KosPro is a boarding-house management app we built and released ourselves on Google Play. This article tells how KosPro came to be: the problem it solves, the features we deliberately postponed in version one, why we chose Flutter and Supabase, and what we learned along the way.

We're writing it not as promotion, but because this story is the most concrete example of how we work. If you're a business owner thinking about an app for your operations, the same pattern most likely applies to your business.

The problem: late rent that nobody notices

The idea for KosPro came from a simple observation of how boarding-house owners run their business. Almost everything is still manual: payments noted in an exercise book, tenants reminded one by one over WhatsApp, vacant rooms tracked only in the owner's head, and no tidy financial report. The problem multiplies when an owner has more than one location.

Interestingly, the biggest problem isn't record-keeping, but late rent that goes unnoticed:

• Each tenant's due date is different, following their move-in date, so there's no uniform "billing day".
• Bank transfers mix with other transactions in the account.
• Late tenants are often only discovered weeks later, because nobody is reminding them.
• When the owner delegates to a caretaker or changes admin, the payment history disappears with them.

If you've read our article on when a business doesn't need AI yet, this is the exact example. The problem isn't "not smart enough", it's "not tidy enough". The solution isn't AI, it's a single source of truth for tenant and billing data, clear status, and automatic reminders.

Discovery: design on paper first

Before a single line of code, we laid out the app flow screen by screen and simple lo-fi wireframes for every page: property list, rooms, tenants, notifications, settings, through to reports. This document became the scope contract: if a screen wasn't in it, it wasn't in version one.

Three things we considered mandatory for version one to answer:

1. Who hasn't paid this month, and who is about to be due.
2. Which rooms are vacant, which are occupied.
3. Payment history per tenant, so there's something to rely on if a dispute happens.

Honest note: our initial wish list was far longer: payment integration, a tenant portal, multiple managers, even an idea for listing vacant rooms publicly. All of it sounded good and all of it delayed the release. We cut it with the same discipline we recommend to clients in MVP vs full product. Some of those items still aren't built today, and no user has complained.

Version 1 scope: four objects, one flow

After design, the v1 scope was locked to four data objects and one main flow.

The main flow: the owner adds properties and rooms, enters tenants, then the app creates monthly bills automatically and colour-codes their status. Green paid, yellow approaching due date, red late. The owner decides when a bill counts as paid, with one button on the room page.

One small detail that turned out to matter: the "due soon" threshold was initially hard-coded at seven days. Once in use, some owners wanted three days, others two weeks. It's now configurable (3, 5, 7, or 14 days). Lesson: a number that feels "obvious" to the app's builders isn't necessarily obvious to its users.

Technology decisions: Flutter and Supabase

Flutter because of one codebase for Android and iOS, and because we already know it well. For an operational app like this, iteration speed matters far more than a "one hundred percent native" look.

Supabase because it gives three things at once without building a backend from scratch: a PostgreSQL database, authentication (email plus Google Sign-In so owners don't need to remember a new password), and scheduled server functions. Those scheduled functions are what create monthly bills automatically and check for late status every day, without the owner opening the app.

For the Premium subscription, we use RevenueCat. It wasn't our first choice, and we tell that story in monetisation lessons from KosPro.

What we want to stress to non-technical readers: all three are ready-made services that save weeks of work. For a small business's operational app, it's almost always wiser to use services like these than to build your own server. We cover the cost range in the cost of building an app in Indonesia 2026.

Harder than expected: dates

The feature that looks most trivial, "create a bill every month", took the most time. A tenant who moved in on 31 January is due when in February? How is a tenant who changes rooms mid-month billed? What is a partial payment recorded as? Server and phone are in different time zones, is the bill created on the wrong day?

None of those questions were on the feature list. They all surfaced during the work. This is why we always add a buffer for "business rules" in client estimates, and why the testing stage in the SDLC must not be cut.

To test it, we generated mock data at an extreme scale: a hundred properties with a hundred rooms each, complete with late, nearly-due, and paid tenants. If the app stays smooth with ten thousand rooms, an owner with thirty rooms won't have a problem.

Releasing to Google Play

From the first commit in early April 2026 to availability on Google Play at the end of July 2026, KosPro took about four months with a small team, worked on alongside other jobs. That number is relevant if you're estimating a similar project: a simple operational app for one type of business, without payment integration, but with subscriptions and automation.

A few things that take time outside of coding and belong in any project schedule:

• Developer account and verification. Google requires organisation identity verification for an account in a company's name, and that has its own delay.
• Listing materials. Icon, feature graphic, screenshots, descriptions in two languages, a privacy policy on your own domain. All of it is checked.
• Review and compliance. Apps with user accounts and in-app purchases are reviewed more closely, including on user data.

The iOS version is prepared from the same codebase, including its in-app purchase configuration, and will follow.

After release: what we didn't expect

Once other people used it, a few things surfaced that didn't come up during design:

1. Junk sign-ups. There were registrations using disposable email addresses. We added disposable-domain blocking and login-attempt logging. In version 2.0.1, that became the main update.
2. Old apps that don't get updated. Users don't update automatically. We added forced and recommended update mechanisms so old versions don't break when the server changes.
3. Reminders to tenants, not just to owners. The most frequent request: "can the app do the chasing?" The answer became a Premium feature: the owner connects their own WhatsApp to the app, and bill reminders are sent to tenants automatically with an editable message template.

What you can take to your business

• Start from status, not from features. The question "who hasn't paid?" is worth more than ten other features. Find the equivalent question in your business.
• Date and money rules are always more complicated than you think. Set time aside for them.
• Use ready-made services for whatever isn't your core business. Authentication, database, subscriptions. Build only what differentiates your product.
• Design the free and paid boundary from the start. It affects the data structure, not just the price.

That's also how we handle client projects. The products we build ourselves, including Cuplikin, are where we test that process before applying it to services for clients.

Next steps

If your business has similar problems, scattered data, unmonitored bills, or processes that depend on someone's memory, we can help design an app that's the right size. Start with a free consultation or chat on WhatsApp.