What We Learned About App Monetisation from KosPro

Many founders treat monetisation as an afterthought: build first, find users, then think about pricing. From KosPro, the boarding-house management app we build and sell ourselves, we learned that app monetisation is a design decision that has to be made early, because it changes what gets built.

This article summarises the practical lessons: pricing model, the free and paid boundary, free trials, paywall placement, the operational side that's rarely discussed, and one decision we changed midway. If you haven't read the product story yet, start with building KosPro.

Subscription, not one-time purchase

The first choice: one-time purchase, subscription, or free with ads. For KosPro, subscription was the only option that made sense, for two reasons:

• The value recurs. Bills are created every month, reminders are sent every month, reports are read every month. Users pay for a service that keeps working, not for a tool that's done once used.
• The cost recurs. There's a server, a database, and scheduled functions running every day. One-time revenue doesn't match costs that never stop.

Ads were ruled out from the start. Owners use this app to manage money. Ads on the billing screen damage trust, and their value is small for an app with such a specific user base.

Setting the free and Premium boundary

The hardest decision isn't the price, it's what's free. Too generous and there's no reason to pay. Too stingy and users never get to feel the benefit.

For KosPro, we placed the boundary at business scale: the free plan covers one property with up to five rooms, and Premium is for anything beyond that. The reasoning:

• The owner of one small boarding house can use the app fully without paying and experience the complete flow: rooms, tenants, bills, colour status.
• An owner with two locations or more than five rooms is someone whose business is already running and who has a real record-keeping problem. For them, the subscription is small compared to a single bill that slips through.

Above the scale boundary, Premium adds features that save time and show the business picture: automatic reminders to tenants via WhatsApp, editable message templates, financial reports with monthly and yearly charts plus PDF export, payment history, and reminder settings a few days before the due date.

That last row matters. Locking basic information makes the app feel like a hostage-taker. What gets locked should be convenience and scale, not basic truths about the user's own business.

Price: show it from the store, don't write it in code

We set the Premium price by a simple rule: it has to feel small compared to one room's rent income, and it has to be compared with the cost of a bill that slips through, not with the price of a coffee. The "cheaper than a cup of coffee" message doesn't work for business users.

One technical lesson that turned out to matter: in early versions, we wrote the price number directly in the app's text. As soon as the price changed or differed between countries, the text was wrong. Now the price is always read from the app store and shown as is. That's also why we don't write the number in this article; the correct price is in the app.

Free trial and paywall placement

KosPro gives a one-month free trial of Premium. That duration isn't arbitrary: owners only feel the benefit of automatic reminders and reports after one billing cycle has run. A week-long trial is too short for that. Early versions used seven days, and we changed it after seeing the pattern.

We also moved the paywall. A paywall that appears at the start, before the user has entered any data, is just a nuisance. Now the Premium offer appears when the user hits the boundary: adding a sixth room or a second property, or opening a Premium feature like reports. At that point they've already entered tenant data and felt the flow, so the question is no longer "is this app useful", but "is it worth it for my other boarding house".

Honest note: we did build purchase validation ourselves at first. KosPro's first version purchased directly through Google Play and the App Store with our own verification function on the server. It worked, but every edge case, failed renewal, restore on a new device, cancellation mid-period, meant new code and new bugs. A few weeks after release, we moved it to RevenueCat. Payment logic is the part you least want to debug yourself, and we learned that the expensive way.

Why RevenueCat

RevenueCat handles things users never see but that decide whether subscriptions actually work: purchase validation on both stores, subscription status that's always in sync, purchase restores, free trials, and webhooks to our server when status changes. KosPro's server remains the gatekeeper: Premium features on the server side check subscription status rather than simply trusting the app.

Its pricing is free up to a revenue threshold, then takes a small percentage. For our current stage, that's far cheaper than engineer time to build and maintain the same logic on two platforms.

The operational side that's rarely discussed

A few things that only become real once there are actual transactions:

• Store commission. Google Play and the App Store take a percentage of every transaction. For small developers, both stores have programmes with a lower cut, around 15 percent, and 30 percent outside those programmes. Set your price after the cut, not before.
• Tax. The stores collect tax for buyers in Indonesia, but reporting on the company side is still our job. Involve a tax professional from the first transaction, not at the annual report.
• Payouts. Stores pay once a month, with a delay after the month ends. Plan cash flow on that assumption, especially if subscription revenue is paying for the server.
• Test users. We needed a way to give Premium access to testers without a transaction. It sounds small, but without it, testing paid features becomes a hassle.
• Junk accounts. As soon as there's a free trial, people sign up with disposable emails. Disposable-domain blocking and login-attempt logging went into the next update.

The metrics we watch

We deliberately don't publish the numbers here, because KosPro is still early and the figures aren't statistically meaningful yet. What we watch:

1. Free to Premium conversion. What percentage of active users eventually subscribe, and at which point they decide.
2. Trial to paid conversion. How many continue after the free month ends.
3. Monthly churn. How many subscribers stop each month. For a business app, low churn is the sign that the product is really being used.
4. Premium feature usage. If subscribers pay but don't use automatic reminders, sooner or later they'll leave.

We read these metrics together, not one at a time. High conversion with high churn means the promise on the paywall isn't being kept by the product.

For you, planning a paid app

If you're planning to build a paid app or SaaS, three things we recommend deciding at the discovery stage, not after release:

• The model and its boundary. What's free, what's paid, and where the "serious user" signal appears.
• The payment service. App stores, a payment gateway, or both. This determines the server architecture.
• Measurement. Which events need to be recorded so conversion and churn can be calculated from day one.

Each of those affects the data design and the app's screens, which is why we always ask about monetisation plans early, even for clients who "haven't thought about it yet". We cover the build cost range in the cost of building an app in Indonesia 2026.

Next steps

If you're designing a paid app or SaaS and want to talk through the pricing model, free boundary, and payment integration, tell us about it for a free initial consultation, or chat on WhatsApp. Our SaaS development services are on the services page.