Forem: Petr Jahoda

How much does it take to “finish” an app

Petr Jahoda — Wed, 04 Feb 2026 15:30:55 +0000

Quite strange equation, don’t you think? But in a developer’s world, math works in unexpected ways.

Six months ago, I decided to build the best EPUB reader for Apple devices. I started immediately and, in four months, I had a working prototype with about 90% of the functionality. Everything worked as expected. Without fear, I launched my first TestFlight.

I expected anything and everything, but not this: I slid back to 10% done.

Somewhere in 2025, I watched Sean Allen’s video on the “90/90 rule.” Now I truly know, what that second 90% means.

TestFlight revealed two truths to me:

Developers are always wrong
When you think you’re almost done, you’ve barely started

These two things forced me to rethink the app’s internals, design, and UI.

I spent the last two to three weeks working harder than in the previous four months. I spent nights fixing bugs, unifying the interface, working on promised features, and making sure, that basics are there (like a consistent close button: top-right X, always).

And even now, I’m not “finished.”

Since this series is about justRead.app development, here’s the latest state with tech details.

What was fixed

The killer problem was simple: the app was freezing and crashing. Something I didn’t experience in development, something TestFlight users experienced a lot.

justRead.app loads epub files from the cloud, often buried deep in subfolders (not yet downloaded). When folder with books is selected, it ran three heavy processes:

Analyze all the (sub)directories for epub files (no files downloaded)
Extract thumbnails and some accessible data from those files (still no files downloaded)
Parse metadata (downloading of files starts now) Users saw a “frozen” app, they tried everything, then app then crashed. What was worse: on relaunch with a selected library, it repeated the exact same cycle with the exact same result for user.

The fix:

The app is running the same processes, but now in the background with clear user progress indicators. Users can read downloaded books while those three processes are running. Simple and completely avoided with better testing.

Smaller bugs got fixed too: streak calculations, read-time tracking, bookmark saves.

What was changed

Non-crashing users gave me around 20 ideas like:

Tap anywhere on a book row to open it (not just the cover)
Hide settings on book start
Load font manually from menu, not automatically from folder

I experimented with all the ideas, iterated on users feedback and implemented what was the best fit.

What was added

No breakage risk here. Those were added:

Statistics dashboard
Roadmap with user voting
Alphabet jump bar for libraries
Extra settings tweaks.

Plus about 50 other small things, like highlighting your current TOC chapter.

TestFlight #2

It’s live today.
This time, I’m expecting crashes, freezes, and issues.

As a user, why is this all important?

You want polished apps, no crashes, intuitive user interface. You are expecting a developer who cares about the app, because he uses it.

That’s why TestFlight matters. Apple enables it, testers refine the app and the users get app as polished as possible.

The voting roadmap builds on this: you shape justRead.app’s future, prioritizing what you want.

As a developer, why is this all important?

We build apps and systems because we love to.

Sean’s rule reminds us: the final 90% polish is the app.

Rush development and release, and you ship a prototype.

Deliver the app polished, and you create something users love.

That’s why 90% + 90 % makes 100%.

And to answer the question in the beginning: it does take a lot more than what you have planned. Even if you have years of experience in development.

justRead.app is an epub reader for iPhone, currently in TestFlight._
Peter
Reader, Developer, justRead.app Creator

30 Days of Sauna: The Sleep Hack That Made Me a Better Developer

Petr Jahoda — Mon, 26 Jan 2026 08:50:53 +0000

Why Daily Sauna Is the Best Productivity Tool I Never Expected

As a developer, I optimize everything: code, workflows, deploy times. But I’d neglected the most important system: my own brain.

Two years ago, I spent two days on and off in a Finnish sauna and felt relieved like never before — a complete nervous system reset. I knew I needed this regularly, so I decided to build my own Finnish sauna. It took me two years.

Why? Because I was deep in coding, building justRead and other projects, with no time to spare. Now I regret I didn’t finish it in two weeks.

On December 22, 2025, with sauna finally finished, I committed to daily sauna for 30 days. Not for fitness, but as an experiment in cognitive recovery and mental “garbage collection.” I wanted to know if deliberate heat exposure could help me think more clearly, switch contexts faster, and actually shut down after work instead of never-ending thinking until midnight.

What I discovered surprised me. My sleep changed first, then my focus, and only later my stress baseline. And once I dug into the neuroscience of heat stress, blood flow, and endorphins, the science backed up what I was feeling in real life.

If you’re a developer stuck in burnout loops, poor sleep, or creative drought: read on.

This might be the recovery protocol you’ve been missing.

This is the story of that 30-day experiment, what worked, what didn’t, and how sauna quietly rewired the way I build, think, and recover as a developer.

The problem: developer brain decay

I was caught in a pattern most developers recognize. Deep whole day focus sessions draining me by 6 PM.
Fractured sleep, waking three, four times a night, thoughts spiraling.
Brain fog thick enough that fresh ideas felt impossible ( I was caught in non stop solving problems).

I’d notice problems but react with anxiety instead of clarity.

Recovery wasn’t happening. Each day started where the previous one ended.

The 30-day experiment

Daily routine: 2×15 minutes in sauna (90°C), separated by cold exposure. Plus the minutes before and after.

About one hour completely offline.

Simple. Consistent. Measurable.

What changed (the good)

Sleep quality improved dramatically. I now sleep 8+ hours straight with no, or little, interruptions. My Apple Watch confirms: 90%+ sleep quality, nearly every night. For last 30 days I got 99% five times. I know, not much, but this was impossible for me before, for a whole year. This alone is significant. Sleep deprivation compounds: lack of sleep erodes decision making, impulse control, and the ability to do sustained cognitive work.

Better sleep is better code.

I can work productively until 9 PM and wake fresh. I used to hit a wall around 6 PM, depleted and fried. Now I extend into the evening without the characteristic burnout feeling. Next morning, I don’t feel the accumulated exhaustion.

It’s real recovery, not willpower.

My default nervous system state shifted. I’m naturally high-strung. Overreactive. Small obstacles triggered disproportionate stress. Now when something breaks — a bug, a business complication — I notice it, acknowledge it, and move forward calmly. This is the biggest change for me. Calm.

You think more clearly under calm.

Ideas flow. Second most valuable change: I get problem-solving ideas while in the sauna. New ideas about justRead, the project I am working on, architecture decisions, feature approaches, how to solve this and that. Before, I was stuck in execution mode. Now, my brain regenerates creative capacity. I do my daily tasks better and faster and have time for thinking.

This is what cognitive recovery actually looks like.

Joint pain vanished. I have a healed broken ankle and a past elbow injury. Both would ache, especially with stress or fatigue. Or weather. For 30 days, they’ve been silent. I stopped noticing them entirely.

The electronics-off hour matters. I’m around computers 10+ hours daily. That hour of pure heat, no screens, no input: it’s not meditation.

It’s your nervous system resetting.

The bad: teenage acne at 46

For three weeks, my face erupted like in puberty. Acne everywhere. At 46, I looked 16 again. Heat stress + detox purging sebum buildup. Week 4, skin started clearing. Worth it? Yes. But prepare for the mirror shock.

My 17 years old daughter refused to go in, when she was seeing me for those three weeks.

Why sauna beats other recovery methods

I’ve tried them all: meditation, walking, music, running, you name it.

The problem? My brain still stayed on. Work problems, bugs, architecture decisions: they followed me. Even with “free time,” I was mentally working.

Sauna is different. The heat demands 100% attention. You can’t think about SwiftUI bindings when your core temperature is 39°C. Your nervous system hijacks control. Work disappears. For the first time, my brain actually shuts down. Why? I don’t know. But it works.

The science

All of this written above isn’t placebo. Recent neuroscience research on sauna bathing shows measurable cognitive shifts.

Brain wave patterns change. EEG studies show increased theta and alpha power post-sauna — the same patterns associated with clarity and emotional processing. Your brain becomes more efficient; it uses fewer attentional resources to process the same information.

Stress hormones drop. Heart rate decreases significantly post-sauna. Cortisol (stress hormone) reduces in regular users. Your nervous system downshifts into parasympathetic activation — the recovery state.

Cognitive processing speeds up. Reaction times improve measurably after sauna. Your pre-attentive auditory processing (how your brain filters relevant signals) becomes sharper. More signal, less noise.

Sleep architecture improves. Heat exposure triggers melatonin regulation and creates a core temperature drop that signals sleep onset. The evidence is clear: sauna users report significantly better sleep quality.

Why this matters for developers

We optimize our tools. We rarely optimize recovery.

A developer’s output isn’t measured in hours worked. It’s measured in decision quality, code clarity, and sustained focus. All three degrade under chronic stress and poor sleep.

Sauna maybe isn’t a productivity hack, like promised in the title.

It’s infrastructure repair.

If you’re experiencing burnout, fragmented sleep, reactivity masquerading as decisiveness, or creative drought: 30 days of daily sauna might reset you the way it reset me.

The barrier is consistency. There’s no sauna in most offices. Most of us don’t have one at home. It requires commitment: showing up daily, staying the full duration, tolerating discomfort.

But the return on that commitment is significant: sleep, calm, ideas, and the capacity to work without depletion.

Is this all?

I’m continuing. At day 60 and day 90, I’ll measure what else emerges, because research says that most changes occurs at the end of third month. Long-term effects, the compound advantages of three months of daily recovery.

If you build software and you’re not recovering properly, sauna is worth testing.

And if you’re looking for an app that respects your reading time and gives you offline-first focus? justRead is designed for people who understand the value of deep, undistracted engagement with text. Same principle: clear the noise, reclaim your attention.

Peter
Reader, Developer, justRead Creator

References

When Your App Freezes in Front of Your Testers: What I Learned About Ego & iOS Development

Petr Jahoda — Sun, 25 Jan 2026 08:11:56 +0000

Development of justRead app in six parts; part five.

I’ve been building software for almost 15 years. Manufacturing systems, backend services, databases that handle millions of transactions. Things that actually matter, production lines depend on them. I thought I knew what I was doing.

Then I shipped my first TestFlight, and my app crashed for 50% of my testers.

The confidence trap

When you’ve spent a decade and a half solving hard problems, you develop a certain… confidence. Not arrogance, exactly. Just the quiet assumption that you understand your domain. You’ve debugged memory leaks in enterprise systems. You’ve optimized database queries for millions of records. You’ve shipped products to paying customers who depended on your code.

Building a native iOS app in SwiftUI felt manageable by comparison. Smaller scope. Single platform. Modern tooling. Surely the hard parts were the product design and the business strategy, not the code.

So when I invited 157 testers to try justRead, my e-book reader app, I was genuinely unprepared for what came next.

The day everything broke

The numbers seemed reasonable at first:

157 people applied for TestFlight
88 actually run the TestFlight
4 unsubscribed immediately (missing features they wanted)
84 stayed and used TestFlight
10–15 engaged deeply with feedback

What I wasn’t ready for: approximately 50% of those users experienced crashes and freezes. Not occasionally. Repeatedly.

The feedback came in waves on the first day. “App froze.” “Crashed when I opened a book.” “Keeps crashing during search.” “Freezes and won’t respond.”

I felt it immediately: shame & embarrassment. That specific kind of ego hit you get when you assumed you were competent and the evidence suggests otherwise.

My first instinct was to fix it immediately. I pushed four quick builds in rapid succession, each targeting what I thought were the culprits. Each time I was convinced I’d found it. Each time, I learned I hadn’t.

The problem I didn’t expect

I totally not anticipated: the app was trying to download data from cloud storage to local iPhone storage in the background while users were trying to interact with it. The process wasn’t properly managed. It wasn’t being cancelled. It wasn’t communicating with the UI that it was happening.

The result? The app would freeze while syncing. Then crash when users tried to do anything else.

This is a foundational problem. Not a bug. A design oversight. And it required rethinking how the entire cloud-sync system works.

That’s not fixed in a quick build. That’s fixed in the next major revision: the one I’m working on now, scheduled for next week.

Why this mattered more than I expected

I wrote the post-TestFlight email to my testers laying out exactly what we found, exactly what we’re fixing. It’s detailed. 27 separate items across stability fixes, functional improvements, experience enhancements, and new features.

When I look at that list, I feel two things simultaneously:
(1) genuine gratitude that TestFlight caught these problems before actual users did, and …
(2) the uncomfortable knowledge that I shipped something to real people that wasn’t ready.

But this thing hit harder than the crashes themselves: I wasn’t expecting problems in the first place.

Not intellectually. Obviously, you expect problems when you’re building in public and testing. That’s the point of TestFlight.

But emotionally? I thought I knew what I was doing. My experience did translate — to the architectural thinking, the debugging methodology, the understanding that stability matters. But it didn’t translate to the specifics of how iOS manages background tasks, memory pressure, and network state. That requires learning deeply iOS, not just applying general software engineering. I thought the hard parts would be the things I expected them to be, not the foundational infrastructure that I’d glossed over.

The humility reboot

Every developer who’s shipped something meaningful knows this feeling: the moment your assumptions collide with reality. It’s not special. It’s not even novel. Thousands of indie developers ship broken first versions to TestFlight every week.
What is interesting is that I didn’t see it coming, even though I should have.

I think it’s because there’s a category error in how we talk about indie app development. The content I read before shipping was almost entirely about growth metrics, monetization strategy, App Store Optimization, and how to build profitable businesses. Very little about the actual problem-solving journey. Very little about the moment when your code meets real devices, real networks, real edge cases, and fails spectacularly.

Everyone talks about MRR and unit economics and customer acquisition cost. Almost nobody talks about the humbling moment when you realize your search implementation is leaking memory, or your cloud-sync strategy is fundamentally broken, or your assumptions about how iOS handles background tasks were incomplete.

So I wasn’t prepared for the specific ways iOS exposes stability problems: background task lifecycle, memory pressure, network interruption, concurrent file access. I knew stability mattered. I didn’t anticipate how differently it manifests.

What I know now (that I didn’t know last week)

Confidence and competence are not the same thing.

I’ve built complex systems. I understand databases, performance optimization, distributed systems. But iOS development operates by different rules. Memory management is different. Concurrency is different. The operating system’s lifecycle management is different. And my 15 years of experience didn’t automagically transfer to these domains.
The apps that freeze on 50% of devices aren’t built by incompetent people. They’re built by people who didn’t anticipate the specific, non-obvious ways that iOS handles background tasks, network requests, and memory pressure.

Testing on the simulator is not the same as testing on real devices.

I tested extensively. On the simulator. On my own devices. But real users with different network speeds, device generations, cloud storage providers, and actual reading patterns found problems in 48 hours that I didn’t find in months.
The testers weren’t doing anything wrong. They were using the app the way it’s supposed to be used. And that’s exactly when the problems appeared.

The gap between “it works for me” and “it works” is massive.

This is obvious when you say it out loud. But it was a genuine surprise living through it. My devices are development machines. They have good connectivity, fresh iOS versions, ample memory. Real users have older iPhones running older iOS versions on spotty WiFi networks while the app is trying to download a 500MB library from cloud storage.
The problem wasn’t the code. The problem was that the code had never met these conditions before.

Freezes and crashes are not small bugs. They’re design problems.

I initially approached the crashes as debugging exercises. Find the null pointer. Find the memory leak. Find the race condition. But the core issue was architectural: my app’s approach to cloud sync didn’t account for the reality that syncing might take a long time, might fail, might be interrupted, and the UI should probably tell the user what’s happening instead of just freezing.

That’s not a bug fix. That’s a redesign.

The week ahead

I’m rebuilding the cloud-sync system from the ground. I’m adding proper error handling, user notifications, timeout mechanisms, and background task management. I’m making sure the app doesn’t try to open files that haven’t finished downloading. I’m creating feedback loops so users know what’s happening instead of wondering why their app is frozen.

The new build goes to TestFlight next week.

And I have to admit that I’m nervous about it. Not because I think there will still be crashes (I’m 100% confident there won’t be, and yes, I know what that overconfidence sounds like now). But because I’ve learned that my confidence is not a reliable predictor of reality.

The 84 people who stuck with the app deserve a product that works. The 10–15 who gave detailed feedback deserve to know that their investment of time was the thing that made the difference between shipping something broken and shipping something real.

The thing nobody writes about

This is why I’m writing this. Not to tell you that my app is great (it’s not, yet). Not to tell you about my growth metrics or my monetization strategy (I have neither, we’re literally in TestFlight week one). And not to tell you that building an indie app is easy if you follow these ten steps.

I’m writing this because the indie dev content I read before shipping was almost entirely about the business side, the metrics, the strategy and the market opportunity. Almost none of it was about the moment when you realize that iOS stability requires entirely different thinking than backend systems. That managing cloud sync while the OS kills background tasks while the user is on spotty WiFi requires architectural decisions, not just debugging. Stability as a principle? Everyone knows that. Stability as iOS execution? That’s what nobody talks about.

Almost none of it was about the feeling of shipping something to real people and having it fail for half of them, even though you thought you knew what you were doing.

Almost none of it was about the humility that comes from learning, in real time, why your confidence was misplaced.

And maybe that’s because those stories are harder to write. They require admitting that despite 15 years of experience, despite months of development, despite testing that felt comprehensive, you still got something fundamentally wrong.

But they’re also the stories that matter most, because they’re the ones that prepare you for what actually happens when you ship.

What comes next

For justRead: a rebuilt cloud-sync system, more thorough testing with real devices, and a deep respect for what I still have to learn about iOS development.

For this journey: continued transparency about what works and what doesn’t. Continued gratitude for the 84 testers who are willing to help us figure this out. And continued proof that the hard part of building an app isn’t the idea or the design, it’s the relentless, humbling work of making it actually work.

The next TestFlight build will be better. And I’ll be more honest about what “better” actually means: not that we fixed everything, but that we learned something.

That’s progress, even if it doesn’t feel like it when your app is freezing in front of real people.
justRead is an EPUB reader for iPhone, currently in TestFlight. If you’re interested in early access or want to share your own story of shipped-too-early products, I’d love to hear from you. The next build ships next week.

Peter
Reader, Developer, justRead Creator

Why most apps feel broken (and why justRead is different)

Petr Jahoda — Thu, 22 Jan 2026 10:47:30 +0000

Development of justRead app in six parts; part four.

The elephant in the room

You’ve probably felt it. That moment when you download an app that looks beautiful but feels wrong. The onboarding is confusing. Navigation is buried three taps deep. Performance stutters when you expect smoothness. The developer clearly built the app for themselves, not for you.

According to research, 68% of users will switch to a competitor after just one poor experience.
Another study found 88% of users abandon apps due to bad UX alone — not because they lack features, but because they feel poorly made.

What’s striking is that this isn’t accidental. It’s a symptom of how most apps are built: from the inside out. Developers ship features without asking if users actually want them. They guess at what “polish” means instead of asking or following guidelines. They update mysteriously, leaving users confused about what changed or why.

Most apps are made at users, not for them. And users notice.

The 15-year perspective

I’ve spent 15 years building software, and the last decade focusing obsessively on user experience. I’ve watched talented developers ship broken apps. Not technically broken — but broken in the ways that matter: confusing navigation, invisible affordances, missing the small details that make something feel intentional versus accidental — ever experienced misaligned icons?

And the worst part? Many developers don’t ask what’s broken and what the app needs. They release updates in silence. Users guess why something changed. Features land that nobody wanted. Features people asked for never ship.

Meanwhile, I’m also a lifetime reader. I’ve used every EPUB reader on iOS. I’ve felt the frustration — smooth scrolling that isn’t, fonts that don’t render properly, library management that feels like an afterthought, features that exist but feel bolted on.

It became clear: the apps that survive are built by people who deeply understand both craft and empathy.

The problem: apps without voices

Here’s what most apps do wrong: they assume users can read minds.

You download an app. It’s pretty. But then:
You have an idea for a feature
You email support (if there even is one)
You never hear back
Months later, a mysterious update arrives
You have no idea if it addressed your feedback or ignored it
You uninstall

This happens because there’s no conversation. The developer is building in a vacuum. Users are waiting in the dark.

72% of users say they expect regular feature updates as extremely important or very important. But most apps provide zero visibility into what’s coming next. Not a roadmap. Not a hint. Just silence, then surprise.

This erodes trust. And once trust is gone, so are you.

The better way: an in-app roadmap where users vote

This is where justRead is different.

Right in the app, you’ll find the Feature Roadmap — a living, breathing board where you can:

Vote on features you want to see built next
See exactly what’s in progress (because transparency matters)
Track completed features and know your voice shaped them
Comment and discuss ideas before they’re implemented
Understand the “why” behind development decisions

This isn’t performative transparency. It’s not a gesture. It’s the actual mechanism by which justRead is built — using VoteFirst, a platform designed specifically for this purpose. Your votes influence what gets built. Your feedback shapes how it gets built. The roadmap updates live — you see progress in real time.

Why does this matter?

When users can see and influence the roadmap, something shifts: they go from being customers to being partners. Research shows users who participate in voting are significantly more likely to appreciate updates when they ship — not because the features are better, but because they see themselves in the product.
They feel heard. And when users feel heard, they stay.

Proof that polish matters

I didn’t enter indie app development to build a mediocre reading app. I built justRead because I wanted to create something that feels intentional in every interaction.

That means:

Smooth scrolling that doesn’t stutter
Thoughtful font rendering that respects typography
Micro-interactions that feel responsive, not delayed
Consistent design language throughout (not features that feel bolted on)
Performance optimization so the app doesn’t drain your battery
Respecting Apple design guidelines

This is tedious work. No user notices these things consciously. But they feel them. An app that’s been polished feels different — lighter, faster, more trustworthy. An app that hasn’t feels like extra work.

This isn’t vanity. Research shows that app performance and stability directly impact how users perceive your entire brand. One laggy app, and users assume you’re careless everywhere. One smooth app, and they assume you care about details that matter.

The message to users

If you’re a reader considering justRead, here’s what we’re offering: an app built by someone who reads, who understands what makes apps feel good, and who believes you should have a voice in what gets built.

You’re not downloading software. You’re joining a community where your vote matters and your feedback shapes what comes next. Features land because you asked for them, not because a product manager guessed.

That’s a different kind of relationship. One where the developer is visibly, consistently working for you.

Join the waitlist at justread.app and be part of this process. See the roadmap for yourself. Vote on features. Help us prove that apps can be built for readers, not at them.

The message to developers

If you’re a developer reading this, consider what justRead is doing: creating an in-app feature roadmap with user voting.

Why is this a differentiator? Because most apps don’t do it. Most developers hide their roadmap (if they have one). Most users have no idea what’s being built or if their feedback matters.

But users crave this transparency. It’s low-cost to build — a GitHub Project, a Notion board, or a dedicated platform like Frill, Changelogfy, or VoteFirst. The hard part isn’t the tool. It’s the commitment: showing your users you’re willing to be transparent about progress, priorities, and constraints.

When users see your roadmap, they understand:

What you’re working on right now
What’s coming next (and when)
Why some features get prioritized over others
That you’re actively listening
This builds trust in ways that polished marketing can’t touch.

It’s also a recruiting tool. Developers and designers are attracted to projects that care about users. Transparency says: “We’re not hiding anything. Come build with us.”

The unspoken competition

The competition for user attention isn’t just between EPUB readers. It’s between apps that feel like they want to work for you and apps that feel like they’re tolerating your existence.

Most apps fall into the latter category. They’re technically functional but emotionally cold. No voice. No relationship. No sense that a human being made thoughtful choices about every detail.

The apps that win — and I mean truly win, with loyal users who evangelize them — are the ones that feel personal. That feel like someone cared enough to polish every interaction. That feel like the developer is sitting across from you, listening to what you need.

That’s not a coincidence. That’s design.

What’s next

justRead launches with a public, in-app roadmap where you can see every feature in progress and vote on what comes next. This isn’t a “maybe someday” feature. It’s core to how we build.

If you’re a reader, that means your voice matters from day one.

If you’re a developer, consider: What if your users didn’t have to wonder what you’re building? What if they could see, vote, and feel ownership over your product’s direction?

The difference between an app that works and an app that matters is smaller than you think. It starts with listening. It continues with transparency. And it compounds when users feel like partners instead of customers.

Most apps miss this. They release in silence. They update mysteriously. They hope users stay.

justRead is built differently.

Your vote. Your voice. Your app.

Ready to join?

If you want to be part of shaping justRead’s future — and you’ve been waiting to see what makes this app different — your moment is coming.
→ Join the waitlist at justread.app

Watch the roadmap. Vote on features. See your feedback become reality. Help us prove that apps can be built forreaders, not at them.

P.S. If you’re a developer interested in implementing feature voting in your own app, check out VoteFirst — that’s what powers justRead’s roadmap. Transparency and user collaboration should be standard practice, not an afterthought.

Peter
Reader, Developer, justRead Creator

Building justRead: A Technical Comparison with Apple Books, Kindle, and BookFusion

Petr Jahoda — Mon, 12 Jan 2026 11:11:33 +0000

This is part three of our justRead development series. Instead of marketing claims, we're doing a detailed visual comparison of how four e-reader apps handle the fundamentals: UI/UX, library organization, customization, and performance.

What we discovered: UX conventions matter more than feature count. Users shouldn't need to learn new patterns. We analyzed seven key areas—UI design, library sorting, font customization, color options, menu depth, margin control, and landscape lock.

Key findings:

justRead wins on accessibility and customization depth (2 menu levels vs 3-4 for competitors)

Supporting 5,000+ books requires thoughtful architecture: Apple Books and justRead both handle this; BookFusion crashes

Font freedom matters: custom fonts + system fonts vs limited presets in competitors

Respecting Apple's design conventions creates better UX than breaking them

We also built unique features competitors don't have:

20–20–20 eye care reminders
rich reading statistics
community voting on features

Read the full visual comparison and see how we approached these design decisions:

itnext.io / justread-vs-apple-books-vs-kindle-vs-bookfusion-00e93199eb95

Forem: Petr Jahoda

How much does it take to “finish” an app

What was fixed

The fix:

What was changed

What was added

TestFlight #2

As a user, why is this all important?

As a developer, why is this all important?

30 Days of Sauna: The Sleep Hack That Made Me a Better Developer

The problem: developer brain decay

The 30-day experiment

What changed (the good)

The bad: teenage acne at 46

Why sauna beats other recovery methods

The science

Why this matters for developers

Is this all?

References

Sleep Quality

Stress & Calm (Cortisol Reduction)

Brain Clarity & Ideas

Cognitive Decline & Dementia

Joint/Pain & Flexibility

General Research & Happiness

When Your App Freezes in Front of Your Testers: What I Learned About Ego & iOS Development

The confidence trap

The day everything broke

The problem I didn’t expect

Why this mattered more than I expected

The humility reboot

What I know now (that I didn’t know last week)

Confidence and competence are not the same thing.

Testing on the simulator is not the same as testing on real devices.

The gap between “it works for me” and “it works” is massive.

Freezes and crashes are not small bugs. They’re design problems.

The week ahead

The thing nobody writes about

What comes next

Why most apps feel broken (and why justRead is different)

The elephant in the room

The 15-year perspective

The problem: apps without voices

The better way: an in-app roadmap where users vote

Proof that polish matters

The message to users

The message to developers

The unspoken competition

What’s next

Ready to join?

Building justRead: A Technical Comparison with Apple Books, Kindle, and BookFusion