John539.com was built to be reliable, understandable, inexpensive, and easy to evolve/iterate upon. This post focuses on why the architecture looks the way it does vs the tactical details of the service.

The Problem I Wanted to Solve

I was annoyed that most Bible study platforms are covered in ads, wrapped in subscription, or lacked trustworthy study features. I wanted a Bible study platform that loaded fast, was totally free, and raelly focused on enabling Scripture study and translation comparison. This is a personal project with simple but long-term intent.

An MVP Monolith Controller — And Possibly Forever

John539.com is intentionally built with a monolithic controller. The application logic, rendering, and data access live together in a single controller. This was a conscious tradeoff for the initial build, affording me:

  • Fewer moving parts
  • Simple deployment
  • Easy debugging
  • No network boundaries inside the app

Server-Rendered Pages Over Heavy Frontends

The site leans heavily on server-rendered HTML with light JavaScript enhancements. This decision was driven by a desire for super fast first paint and lower client complexity. Bible study is primarily a reading experience. A full SPA would add weight without meaningfully improving usability. JavaScript is used where it provides value — not as a default. The data layer uses MySQL. Scripture data is read-heavy, highly structured, and rarely changes. That makes relational databases a perfect fit. The simplest system that works reliably is often the best system. 

This approach also afforded the luxry of a pretty snappy Progressive Web App (PWA) experience, which I also value as a solid feature of the project. User's can access the app from their mobile device and have an, arguably, superior experience to a standard iOS/Android packaged app that results in a bit more bulk and disjointed mobile web/desktop experience. This may be a "hot take".

Selective Use of APIs and Background Processing

While the core site remains simple, I do use APIs and background processing where it makes sense. For example, the "John539 Companion"/AI Assistant, study features (bookmarks, highlights, notes, etc), search, and some async loads/prefetching). These components are treated as extensions, not dependencies. The site continues to (mostly) function even if these services are unavailable. That separation keeps the core reading experience pretty resilient.

Cost and Project Longevity

John539.com was designed to run cheaply. Generally speaking, I try to take the "poor man's" approach to most of my projects but this was something I know I never want to attempt to monetize -- I just want people to find value from it. All-told, the site only costs me a few bucks to operate every month and can probably scale to tens of thousands of users as-is without breaching that threshold. I don't expect that to ever happen.

John539.com is not an example of cutting-edge infrastructure. It is an example of intentional restraint. The technology exists to support the mission — not to distract from it. In a space as timeless as Scripture, durability matters more than fashion.