On September 3rd I launched Vesper, a cross-platform Christian prayer app for Android and iOS, as my entry in the RevenueCat 2026 Shipaton. This is not just a basic app thrown together quickly for this context, though: I have spent months building it and iterating on the features and design, as I am building it as a real production-grade application to bootstrap a business. I'm publishing this series of technical posts as a retrospective look back on how I built it.
A bit of context
I first got the idea for this app and started working on Vesper in early May. The Shipaton happened to coincide with my already-planned release schedule, so I decided to wait a few extra weeks so I could polish things up and document the technical decisions I'd made along the way for the benefit of the Kotlin community. These posts are written after the fact. I'm not live-blogging the build; I'm looking back at what I built and explaining the 'why' behind my decisions.
Vesper was designed heavily around Ballast, a Kotlin Multiplatform state management library I have maintained for many years. Ballast is mostly my personal opinionated structure for building things like per-screen UI state and app navigation, so part of my motivation for this series is showing what Ballast looks like in a real, production-scale application.
But the things I learned building Vesper apply to anyone looking to make a real-world, production-ready application today, whether you choose to use Ballast or not. While these blogs will describe the actual code of Vesper using Ballast, the general knowledge and ways to think about building software capable of handling production workloads are not specific to Ballast.
Who these posts are for
This is an advanced series. I'm not going to walk through setting up a Ktor project from scratch or explain what a coroutine is. What I will do is focus on higher-level architectural decisions and the tradeoffs that come with them — the kind of thinking that goes into building software you actually intend to maintain and grow over many years.
Vesper is not a throwaway pet project. It's the foundation of what I hope can eventually become a real company. That shapes every decision in the codebase.
That said, I want to be honest about the audience for these posts: most of what I describe here is almost certainly over-architected for a simple side project, and quite probably under-powered for an established company with a real engineering team and real infrastructure budget. The constraint I was working under is the one you find at an early-stage pre-launch startup — needing production-stable code without being able to pay for production-grade services. I built a lot of things myself that I could have paid for as a service (email campaigns, feature flags, push notifications, job queues) not just because I couldn't afford those services yet, but also because I don't yet need many of the advanced features those services provide. That context matters when reading these posts.
That said, the ability to tailor these features to exactly my needs without having to compromise on the available features or uptime of another service is a distinct benefit that I will not throw away lightly. I did not build features like job queues or email marketing directly into Vesper just because I want to save money. By building them myself, I am able to evolve the features and functionality along with the product itself in a way that I would not be able to with a SaaS product. It will be slower, for sure, but that's a luxury that I can afford now, and that I believe will continue to serve Vesper well far into the future and lead to an application that is every bit as stable as one built on SaaS products, but at a fraction of the monthly cost.
With Vesper, I find myself working in a space that I have not found to be documented very well, because most content you'll find online is focused on absolute beginners, or large enterprise customers. It's actually pretty hard to bridge the gap between the two, but I hope to be able to give a glimpse into what it looks like working in the space between those two extremes.
Kotlin Multiplatform is not optional here
The entire application is enabled by Kotlin Multiplatform. Vesper in its current form — a single codebase running across Android, iOS, and eventually web, with domain logic, contracts, and data models shared between the Compose frontend and the Ktor backend — could not exist without it. Some of these posts will focus heavily on specific Kotlin language features or KMP-specific patterns. Others will spend more time on the problem itself and less on the Kotlin mechanics. Either way, I'll make sure there's at least one concrete Kotlin snippet in every post so it's grounded in something real.
About the source code
Vesper is a closed-source application. The code I share in these posts is the only direct look at the internals you'll get. That said, nothing in the repo is a genuine trade secret — it's just a mobile app, and a relatively low-risk one at that. Several of the components I built are self-contained enough that I'd happily extract and publish them as open-source libraries if there's enough interest. I'll call those out explicitly as I go, and I'll be providing code snippets where relevant. But because most of the code is currently closed-source, don't expect to be able to copy-and-paste any of these code snippets into your project and expect it to work.
The Roadmap
The series will cover many topics cross the full spectrum of a full-stack Kotlin Multiplatform app, including Compose frontend, Ktor+Exposed backend, and infrastructure.
I will update this list with links and new entries as I publish the posts, so bookmark this page or follow me on Dev.to if you want to follow along!
- Get Started with Ballast for Structured Compose UI
- Designing a User Management system with JWTs, Ktor, and Exposed
- Theming and Dynamic Font Loading in Compose
- Deep-Linking and Navigation with KMP
- Domain-Driven Development - The Secret Weapon for Maintainable Apps
- Contract-Based Development for Sharing Code between Compose and Ktor
What Is Vesper?
While I am not writing these blog posts as marketing for the app itself, it may be helpful for you to have a bit of insight into the core functionality of the app.
Vesper is a prayer app and a community of Believers carrying each other's burdens. We gather 2 or 3 to join with Jesus in prayer, building a daily rhythm of intercession together.
Vesper works on a system of matching submitted prayers anonymously to other users ready to pray for them. It's intentionally not a social network as there is no concept of following, liking, or replying to prayers. It's just a place for Christians to ask for prayer in their time of need, and for other Christians to build a stronger habit of prayer by interceding for those requests.
If you're a follower of Jesus and would like to join the community, you can sign up for the mailing list or find links to download the app and join the community at vesperapp.cc.
But regardless of what you believe, I hope this deeper look into what it took to build Vesper will be helpful and a blessing to you!
Top comments (0)