DEV Community: Petr Jahoda

My first App Store App was profitable from Day One: $1,000+ in 1st month

Petr Jahoda — Tue, 16 Jun 2026 09:58:37 +0000

Written across multiple sessions in May/June 2026.

The decision to make the app was made in August 2025.
The app went live on the App Store on March 10th, 2026 and earned USD 1,230 in first 30 days.

How it all started

From the day I learned to understand what those strange glyphs mean, I am an avid reader. I read books and comics all the time. I love physical paper books, and you won't be surprised I had numerous e-ink devices from all possible manufacturers in the past. And I read on iPhone and iPad.

If you ask me, what I am reading right now, you can bet I have multiple books in progress.

Lately (meaning late few years), I completely went from eink devices to reading on iPhone and iPad (main reason here was superb contrast).

Through all those years I used all possible apps that were, and are, available for iOS and then for iPadOS. And every one of those has something that did not click with me. Inconsistent UI, large margins while reading, no custom fonts, … always something.

So I was what people would call a switcher. One month I was using Apple Books, the other month something else.

The more I used my phone for reading the more I was thinking about creating my own reading app, just for me to meet my preferences.

And then, in the summer of 2025, I decided to make it happen, because I am also a developer.

Now, if you're a developer too, you're probably wondering why you're reading about my reading habits when what you really want to know is how I earned that money with my first app. You'll get there, but now you also understand why I even started.

And the first thing that made the money happen was…

1. Solving real problems

My aim, in the first place, was to solve real problems I saw using those multiple reading apps. If you read on iPhone or iPad, maybe those will sound familiar:

I want to set my own margins like I want, and to the edge of the device. Meaning: I want as large space as possible for reading.
I want to add my own fonts, those I downloaded from the internet
I do not want to 'add' books into the app, I want the app to use books I already have saved in a folder.
I want an app that uses metadata and series properly. Meaning: I want the books in a series to be sorted by the order in that series
I want to lock reading orientation in landscape, while having the phone in portrait (impossible with Apple Books, for example)
I want filters, sorting, collections and use of tags in my library. Meaning: I want to see my library from different perspectives
I want proper reading statistics
I want the app to handle thousands of files
I want this and I want that As you can see, (I am repeating myself) my aim was not to create or copy another reading app. I wanted to create an app to solve my own real problems in the first place. Oh, and I totally forgot proper sync of data between devices.

Because I was using multiple other apps, I knew what I loved and hated in those apps. What I loved I included, what I hated I did not include.

And for you developers: I decided to not go cross platform and use Swift and SwiftUI, because I wanted to give users the best (and proper) user experience on Apple devices, which I think is almost impossible to do with (for example) Flutter.

To make a summary of this point: I started with solving my own problems and this gradually changed into solving problems of other people (see point 6).

2. Planning

Even though I knew what I wanted I spent around two months in non-stop thinking mode about what I want, how I want it, why do I want it the way I want it, etc.

I drew multiple sketches, on paper and using Sketch.app on my Mac.

I wrote endless small Swift and SwiftUI test programs, to test every idea I had.

I thought about design, functionality, UI and UX, colors, fonts, simply everything. Even before I wrote first line of code in the final project I knew exactly how the app would look and behave. But of course it looks and behaves slightly differently now, than I initially wanted.

I used AI in this planning time a lot. Analysis, ideas, statistics of different areas of development. My Perplexity account was used to max.

Meantime, I was writing a concrete step-by step plan with milestones along the way (including TestFlight, of course). March 1st was chosen (with a buffer) as a release date. But as you now know, I was not able to make it happen, due to three rejections from Apple.

The summary of this point is simple: I am not executing things when I do not know exactly what, how, when, where and WHY I am going to do this 'thing'. I must have a plan.

3. Commitment

Once I know, what exactly to do, I do it, no matter what. And because I know myself, the plan also includes buffers. I am counting with days I am lazy, I have no brain power, I am ill, or something else. Unexpected things happen all the time.

On the other side, when nothing unexpected happens, I am not ill and have superb brain power I am finishing my tasks sooner than I planned. And this is super positive on my mood and willpower.

This is something I do not only for development, but also for running (as I love to run long distances) and everything else I do and where it makes sense to make a plan and execute it.

To sum this up: In this part of the project I am simply executing things as I planned, but not 100%, because there is …

4. Continuous evaluation

Even thought I am doing what I planned to do I am always rethinking and refining the plan in realtime. New ideas are coming, new problems arise and even though I have a plan, that plan is not set in stone.

I do this on weekly basis, mostly on weekends, when I know there will be no work phone calls or emails (meaning calm waters for thinking about anything else than work).

I am spending few hours thinking about what I have already done and what is planned for next week.

I update the plan, change things (remove, add, move, …) and have a free thinking mode from different angles about it.

Summary of this part is also simple: The main goal is to have updated plan according to reality, that is always changing. And for this, it is very good to have another person, meaning you should…

5. Have a devil's advocate

Have someone who will constantly push you, control you, play with your ideas, have his or hers own ideas.

Have someone who will give you constant feedback of how bad you did what you did. You are not searching for someone who will give you thumbs up every day. No. You want someone who will give you realistic feedback, who is not afraid to tell you how bad this part of software is and who is not afraid to argue with you.

Here I am lucky to have a son, who is not afraid to argue with me about a position of a search field or a color of a button. Kudos to him.

Quick summary: Do not rely completely on yourself, have someone who will not agree automatically with everything you do and say.

But if you want to know, what ultimately moved the needle, it was point 6.

6. Users (feedback)

This will be lengthy point. All the other points above can be executed 100%, but when you have no users, then you really did the app for yourself with no money earned.

My plan included TestFlight from the beginning, because I wanted other real people to test the app before going live. And boy how glad I am I did it and boy how glad I am I started with it three months before release.

I made a webpage with a mailing list and I started looking for people who will be interested in this. Everywhere possible. In the end I got almost 1000 people in the mailing list. Of those 150 were interested in testing. Of those around 50 tested things and of those around 10 people were those ultimate testers that gave me valuable feedback.

I was (and I still am) active at reddit and mobileread forum. I wanted people to know about the app and give me feedback even before the app was released. Again I am thankful for this. I had to swallow a lot of pride.

But I did not end here. One thing I did not mention in the beginning, in the list of those problems I wanted to solved was this one: I wanted something for users to give me feedback inside the app. And not just feedback, but ideas. And as I was thinking about it, a complete roadmap ended up in the software, where users can add ideas, comment other ideas and vote for ideas they want to build next.

When I was preparing this in-app Roadmap, I was thinking: why other apps do not have something like that? With other apps, sometimes I do not even know how to contact the developer with a problem (meaning I uninstall the app).

And with this a side project was born: votefirst.

Side project, where my son is the author and I am that devil's advocate.

And this is the result of this side project, the summary of all the responses for my reading app:

I won't be able to be responsive and actively update the software, when users won't have a way to contact me as easily as possible.

And I think this last point — adding a roadmap with a feedback — was that needle that ended up in the app being profitable from day one. Because users feel the developer care for the product and for the users.

And see, I even included two em-dashes in the article!

To sum this point up: give users an opportunity for a feedback and value it. No need to use this votefirst app, but it is now battle tested, working and the developer, my son, respects the same principles I do. The ones you just read about.

What did not work FOR ME

As I was thinking about 'how to push the app to more users' I came across website called Indie App Santa. I was thrilled there is a way, that will somehow surely get me users and I even paid for a Growth plan, but in the end I saw nothing meaningful in the data.

Oh, I forgot to mention I am obsessive with data, so I measure everything I can in multiple places.

I am not saying Indie App Santa does not work, the people here are super friendly and helpful, it just did not work for my app, and to be fair, they mentioned it even before we started, that this kind of app is not the one attracting people.

Summary

Now you know what works for me. All those points are complementary to each other, split them separate and I think it will not work.

And this works not just with this small app development, it works for me in all areas in my life I do, be it running ultras, building sauna, making a new project or anything else.

I don't even know now, if I ever mentioned the name of the app itself, so here it is: the app is called justread.app.

And if you are interested why the .app in the name, the answer is simple, just type down justread.app in the url and you are right on the right page, so the name is it's own shortcut.

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

DEV Community: Petr Jahoda

My first App Store App was profitable from Day One: $1,000+ in 1st month

How it all started

1. Solving real problems

2. Planning

3. Commitment

4. Continuous evaluation

5. Have a devil's advocate

6. Users (feedback)

What did not work FOR ME

Summary

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