Why I built a 'dumb' reading app in the era of AI and Social Feeds
TL;DR: I built a reading app that intentionally lacks "features" (no store, no social, no accounts) and focused entirely on native iOS mechanics and file ownership. Here is why I think the "Universal App" approach is wrong for niche tools.
The Context
I’ve been building justRead, an EPUB reader for iOS. The eBook market is crowded with apps trying to be the next Netflix or Goodreads—pushing subscriptions, social algorithms, and proprietary ecosystems.
And AI.
I decided to go the opposite direction. I wanted to build a tool, not a platform. Here are the 3 controversial architectural decisions I made, and why I think they are the right business move for a solo founder.
1. The "No Import" Architecture (Files vs. Database)
The industry standard for retention is Lock-in. Apps want you to import books into their database so it's hard for you to leave.
- My Approach: I built the app to read directly from the user's iOS File System (iCloud Drive/On Device).
- The Technical Trade-off: This is harder to code than a standard SQL database import because you have to handle file permissions and cloud syncing states in real-time.
- The User Benefit: Users own their data. If they manage their library in Calibre on PC, it auto-syncs to the phone. No "Send to Device." No duplication.
- The Business Bet: Power users (my target niche) value ownership over convenience. They are tired of their books being held hostage.
2. Native SwiftUI vs. "Write Once, Run Everywhere"
As a solo dev, the logical choice was Flutter or React Native to hit iOS and Android simultaneously. I chose native SwiftUI.
- The Reasoning: In a utility app, "feel" is the product. The 200ms lag in a non-native interaction breaks the flow. I wanted to leverage native iOS behaviors (Haptics, Dynamic Type, System Animations) for free.
- The Result: The app has zero "learning curve" because it mimics Apple's own design language (Apple Books/Notes/Safari). It feels like from Apple.
3. "Dumb" Orientation (Ignoring the Accelerometer)
This is a small UX decision that highlights the philosophy. Most apps auto-rotate. I disabled auto-rotation by default.
- Why? Reading is a flow state. A user shifting in bed shouldn't trigger a layout change.
- The Lesson: Sometimes "smart" features are just interruptions. Giving users manual control (locking to portrait/landscape) is often better than trying to guess their intent with sensors.
The Ask
I’m currently in pre-TestFlight. I’m curious to hear from other devs:
Do you think prioritizing "User Ownership" (no database/lock-in) is a viable moat against major competitors, or am I just making it too easy for users to churn?
Do you think mimicking Apple design UI is better than creating a super-duper UI by yourself?
I wrote a deeper dive on these design choices here: Why We Built justRead This Way
Link to project: https://justread.app
Really appreciate this approach — stripping down to a tool, not a platform and focusing on ownership and flow over noise actually flips the usual mobile app playbook on its head. In a world where “features = value” is the default, prioritizing how users feel while they use something is a rare differentiator that often comes up in healthy retention curves. When you think about long-term adoption, do you see simplicity becoming a virtuous growth loop (users tell others because it just works) rather than a churn risk?
Hi, the app is called justRead, so reading is the "what this app is about" and it was my initial goal: to have reading experience as pleasured as possible, without any fuzz around. Meaning the simplicity of Apple Books (in comparison to BookFusion for example). But on opposite give user the ability to change things reading related: fonts, colors, etc. but again, as simple as possible.
I hope I achieved this as I applied for my first TestFlight ever.
And there are few things added, but things that add value for reading, not added for the sake of features:
And again, simplicity is the key. I am still polishing the app to "get out of the way" of user, so user does not have to think about anything and just user the app.
I see simplicity in my app as something people will return to, after testing other apps.
And there is a roadmap in the app with features, but I will not be adding features just for the sake of adding features. If I don't know, how to implement the feature properly with simplicity in mind, I will not implement the feature.
The future will tell me, how much wrong I was :-)
Your ideas are practical good luck 🍀
Hi, thank, will be posting with updates, for sure. Have a nice day.
Love the simplicity here — focusing on native iOS behavior and minimal interruptions really stands out.
Hi, thank you for the response. Appreciated.
Love the clarity of the philosophy here - especially the "tool, not platform" stance.
I do think user ownership can be a moat and a risk. It’s a moat for power users, but it removes the usual retention levers. That probably means marketing has to be sharper about who the app is for, not just what it does.
On mimicking Apple UI: 100% agree. Reinventing UI in a reading app often feels like solving the wrong problem.
Respect the conviction behind these choices - not easy as a solo founder.
Hi William, thank you for the support. Just finished the first version with my first Testflight starting next week, so I will be posting with the ongoing development.
Have a nice day.
"tool not platform" is such a better framing. too many apps try to be ecosystems when users just want something that does one thing well.
also as fellow ios dev - the swiftui decision makes sense. cross-platform is tempting but the feel matters especially for reading apps. users notice when scroll doesn't feel right.
good luck with testflight! curious how the file-based approach works with icloud sync reliability
Hi man and thank you for the response.
The file-cloud-sync is really simple.
Also I am planning to create a finder extension with preview option to manage metadata in epub files on macos (covers, title, authors, tags, etc.).
The "tool, not a platform" framing resonates. I'm building a tech news aggregator and facing the same philosophical choice — do I try to become a destination (social features, engagement loops) or stay a focused utility that helps people read less but read better?
Your file ownership point highlights a broader pattern: users increasingly distrust tools that hold their data hostage. The same applies to content curation — when an aggregator becomes too "smart" about what to show, users feel manipulated rather than helped.
Curious: do you think the lack of database/lock-in actually helps with word-of-mouth? I've noticed tools that "let you leave easily" tend to get recommended more honestly, because there's no hidden agenda.
Well, about that word-of-mouth, I don't know.
I posted on reddit in calibre forum yesterday and got bit of a hate. Looks like people didn't bother to read anything about the software, ask basic questions , that are answered even on the landing page, or can be easily deduced from screenshots, and only complain about software price.
Was a little discouraged after that.
But I am going to do what I planned and will post results in here also.
Reddit feedback can be brutal — especially in subreddits with established tools like Calibre. The price complaint pattern is common: people react to pricing before understanding differentiation.
The fact that they're asking questions already answered on your landing page is actually useful signal. It might mean the value prop needs to hit faster (first 3 seconds), or the positioning needs sharper contrast vs. free alternatives.
IH tends to be more constructive since people here are building too. Keep posting your progress — the feedback quality difference is noticeable.
Thank you, it was very valuable to me, will be posting a new article today.
I wonder how many people have a library of epub's they maintain? If that's a real niche, then almost by definition you have a "moat" against competitors.
There are about 1 700 000 people, who use Calibre for management. I hope those and similar are the ones for me.
I really like this angle — in a world where so many tools try to be everything to everyone, simple focused tools often win by solving one clear pain.
From a dev perspective, the cost of complexity is real: more surface area to break, harder onboarding, higher cognitive load for users. Sometimes the best product is the one that never has 20 features, just the one that works reliably and predictably.
Curious — did you find that focusing on “dumb but useful” actually made it easier to iterate or get feedback from early users (vs trying to build something more ambitious right away)?
Hi mrHarsh, for now I have feedback just from colleague, friend and family. They are all readers, but they are not strangers.
TestFlight is starting in next 14 days, and I hope I will get a constructive criticism to make the app better.
Also, PostHog is implemented from start as I want to iterate the app not by thinking what should be done, but to have real data and stats on what should be done.
I am personally 15 years knee deep in development for factories (manufacturing software), and I am a "data and statistics" man, I simply love data and stats.
So stats will be a big part of this app, but I do not want to overdone it, as I can generate a lot of stats. And that is also why I hope PostHog will help me to sharpen this and get rid of features people do not use or use the least.
And as for your last question: especially in "manufacturing" I find that "the simpler the better" is much more useful that clog the software with a ton of features. People are different and I want to find the least common denominator for people to use the app without thinking about using it.
Have a nice day
PJ
That’s a very grounded approach — especially coming from manufacturing software, where complexity has a real operational cost.
Starting with friends/family for usability, then switching to strangers for behavior signals via TestFlight + PostHog, is a solid sequencing. The fact that you’re explicitly watching what people stop using (not just what they touch once) already puts you ahead of most early apps.
One thing I’ve seen work well in “simple tools” like this is defining a single non-negotiable core action (the thing that must happen repeatedly for the product to exist), and letting PostHog ruthlessly prune everything else that doesn’t support it.
Your framing around least common denominator usage + predictable behavior feels very aligned with that. Looking forward to seeing how the TestFlight data sharpens it.
Hi, thank you for the response, I too am looking forward to TestFlight as this will be my first one and I don't know, what to expect at all.