Going from Conceptualisation to Monetization

Monetizing your app from concept through to obtaining your first customer is a tricky thing, nobody will deny that — It’s a struggle I’ve faced, myself, fairly recently with the development of a product in my own personal time, Kiwiki.

Every Great Idea has an Origin

Last March I was busy contributing to various video game communities in my spare time, and in one of them, I had decided to build a community wiki website for an ad-free, clean experience that was filled with bespoke features; website and wiki builders in the market lacked the level of customization I required, were too taxing on battery life, too riddled with intrusive ads, and were almost too simplified for my use case; these wikis were complex systems built off of the back of over 30,000 lines of JSON code for movesets, data values, and descriptions — Once the website launched, having been custom-developed by myself, it was a roaring success within the community hitting over 100,000 unique impressions in the space of three months, with over 20,000 active monthly users; unfortunately the game petered off and became unsupported within a year, making the website unfeasible to continue hosting as the community for the game diminished.

Saying this, it gave inspiration towards a unique product — A website generator focused on wikis that could be extensively customized, branded, and shipped using plain JSON data to build automatic APIs for large amounts of data, and to promote component reuse and dynamic experiences. I had other communities asking me to build wikis for their games — some of which were far, far larger than I could possibly record, with hundreds of thousands of lines of text and values — however I was only one person. What if I built this tool so that they could self-serve?

Going from Concept to Payment

From this, Kiwiki was born — But I had one major problem; how do I monetize an application like this? First, I theorized my pricing models — Would I charge per page? Per wiki? Per user? Per team? Would I have tiers? Would I support upgrading and downgrading for tiers? All of these questions were critical to my implementation, and Salable was — as a platform — more than simple enough to integrate and experiment with in order to find a solution that best worked for my product.

By establishing an authentication layer on my application via Clerk, and then creating Entitlements in Salable, I was able to meter the amount of pages a plan could have, and how many users could edit a wiki instance in Kiwiki from within my code — Simply sign up to Salable, create a Product with Plans that mirrored my tiers (Free, Paid, Pro and Enterprise Plans), and create Entitlements for my unique selling points like the number of pages, number of team members per-wiki, etcetera.

Each wiki instance would be a single subscription on the main Product, subscribing to one of the Plan tiers — If they wanted to upgrade or downgrade their plan, I would simply enact the change on the date of the next bill, and in our end of the code, hide the pages that exceeded the number of pages they were entitled to, or require them to cut team members if they had downgraded, for instance. By hooking onto the Entitlement name and providing it a value depending on the current user’s plan, this enabled me to be both extremely flexible, and also scalable with my plans and paywalling features. If I wanted to suddenly make a new feature tier-dependent, then I could just create a new Entitlement, add it to my plans, and my code would automatically have access to that flag to start building new paywalled experiences and limits as I needed.

Changing my Mind

Let’s also theorize if I woke up one day and decided to charge per-page, or allow users to purchase extra page slots beyond their plan — I could create a new plan as a one-off purchase with a new Entitlement flag for adding a new page to the tier’s total, and simply trigger it on a successful payment; this way I’m not locked into having a tiered pricing application, but instead can transition into a dynamic pricing application with just a few clicks, and a little bit of code.

Building upgrade and downgrade flows too was an effortless task within Salable — Again, I would simply swap the user’s subscription from one Plan to another, offering the choice for the user to upgrade or downgrade at the end of their current billing cycle, or immediately via cancelling their current subscription and establishing a new subscription — This way, users had the option of both waiting out a change in tier, or triggering it immediately.

Conclusion

What would have taken me weeks — if not months — to develop both of these flows using just Stripe has taken me only minutes in Salable. Even less if you were to utilise an AI model like Claude to automatically implement Salable’s integration into your application. Whether you’re an AI evangelist or an AI purist, Salable’s docs are simple to understand and follow, and the results do honestly speak for themselves.

Hopefully this blog has inspired you, whether you have an existing product or have just started conceptualizing one — Irrespective of the state of your product, or the structure of your planned pricing, Salable can handle it quickly, quietly and dynamically.