Digital fluency is real, but it is not the same as clarity

When I started building Sunna Planner, I had no problem choosing a stack, setting up my database, or wiring a prototype. The technical friction that stops a lot of first-time builders simply did not exist for me. I could move fast. I was comfortable with ambiguity in the tooling layer.

What slowed me down was something else entirely: I had no real clarity on what I was building or for whom. I was digital-fluent but product-unclear. I kept adding screens because I could, not because a user needed them. Version one had discussion groups. Some used them. But I have to animate it. In reality, the problem was that I had built something I was technically capable of shipping, not something people had actually asked for and that I could animated.

Being digital-native makes you fast at execution. It does not make you good at listening. Those are different skills. The second one took me longer to develop, and it required slowing down in a way that felt unnatural at first. I had to learn to sit with a problem before jumping to a solution. That gap between stimulus and response, between identifying a friction and opening a code editor, is still something I train deliberately.

Digital fluency is a foundation. But without a clear problem to solve, it is just speed in the wrong direction.

The tools shaped how I saw the problem

There is a concept I kept running into as I refined Sunna Planner's positioning: when your only tool is a hammer, everything looks like a nail. For me, the hammer was always digital. And for years, that made me underestimate how non-digital the real lives of my users actually were.

I was building a productivity app for Muslim entrepreneurs and professionals. I assumed they were like me: always on their phone, comfortable with SaaS, used to managing their day in layers of apps and integrations. Some of them are. But a lot of them are not. Some track their prayers in a notebook. Some use Apps reminders. Some do not separate work tasks from personal routines in any structured way at all.

My digital lens made me design for a version of the user that was closest to me. That is a known bias, but it hits differently when you are building solo with no design team to challenge your assumptions. I had to actively seek feedback from people who did not share my habits. Not just to validate features, but to understand how they thought about time, discipline, and spiritual practice.

The app got meaningfully better when I stopped assuming that digital-native meant universal. The UX improvements I made between v1 and v2 were not just visual. They were a direct result of understanding that my users relationship with tools was different from mine, and designing for their reality, not my comfort zone. If you want to go deeper on UX lessons from building solo, I wrote about that here.

Always-on is a feature of the environment, not a virtue

One of the more uncomfortable things I had to admit to myself is that being digital-native had normalized a level of fragmentation that I had completely stopped questioning. Notifications, context-switching, tabs, threads, etc. I was not managing my attention. I was just used to it being scattered.

When I started praying more consistently, I noticed the contrast sharply. Prayer requires presence and focus. Five times a day, you stop. You disconnect. You orient yourself toward something that has nothing to do with your todo-list. That rhythm exposed how fractured the rest of my day actually was. I was not focused. I was just busy in a familiar way.

This became one of the quiet design principles behind Sunna Planner's Focus Mode. Not because I wanted to moralize about screen time, but because I had personally experienced what it felt like to work in 25-minute blocks with no interruption, after years of working in an environment where interruption was the default. The difference was significant enough that I built it into the product.

Being digital-native means you absorb the norms of digital environments. That includes the bad ones. Noticing them, naming them, and deciding which ones you actually want to keep is part of growing up in a different way.

What I wish I had known earlier

I wish I had known that digital fluency and product thinking are not the same skill set, and that confusing them costs you time. I spent months building things I could build instead of things I should build. The technical confidence was real. The product judgment was not there yet.

I also wish I had been more deliberate earlier about separating my identity as a digital-native from my decisions as a builder. When you grow up with technology, it becomes invisible. You stop asking whether a digital solution is the right solution. You just assume it is. Sometimes it's not. Sometimes the right answer for a user is a simpler flow, fewer steps, less surface area. Restraint in product design is harder when adding features feels effortless.

The other thing I underestimated was how much the digital world rewards output and penalizes pause. Ship fast, iterate, move. That pressure is real and sometimes useful. But some of the best decisions I made on Sunna Planner came from not shipping, from sitting with a question for a few weeks before committing to an answer. The pivot toward Muslim entrepreneurs as a clear target audience in v2 came from that kind of pause, not from a intensive sprint.

If you are building something solo and feeling the pressure to always be moving, I would recommend reading about how indie hackers think about sustainable growth. This piece on SaaS growth for solo builders covers some of that honestly. And for broader context on what it means to think clearly about product direction, the Harvard Business Review piece on design thinking is worth a read, not for the methodology, but for the underlying argument about problem framing. And go for a walk!

What I would do differently

I would talk to non-technical, non-digital users much earlier. Not to design for them specifically, but to stress-test my assumptions. Every time I did that, I found something I had missed. The gap between how I use tools and how most people use tools is larger than I naturally assume.

I would also be more skeptical of my own defaults. Just because I track everything digitally does not mean everyone should. Just because I find a certain interface intuitive does not mean it is. Growing up digital gave me strong instincts. Some of those instincts are right. Some are just familiar. Learning to tell the difference is ongoing work.

And I would have invested earlier in understanding the emotional relationship people have with their tools, not just the functional one. People do not just want apps that work. They want apps that feel like they were made for them. That is a different standard, and it requires empathy that goes beyond technical skill.

At the end of the story

Being digital-native is a real advantage. It lowers the cost of building and accelerates learning. But it also installs defaults you don't always notice until something forces you to look. For me, it took building something personal, something tied to faith, discipline and daily life, to start seeing those defaults clearly. The digital part is still how I work. But I try not to let it be the only lens I use.