Product judgment · September 2026 · 6 min

How do you decide what not to build?

A conversation about all the reasonable ideas that still did not belong in the first version of Tilawa.

Did you know exactly what Tilawa should be when you started?

Not exactly. I knew the problem I cared about. Somebody wants help with their recitation, but the right teacher may not be close to them or available when they need help. I wanted that person to be able to reach a real teacher without turning the whole experience into something complicated.

Once you start thinking about that problem, a lot of ideas appear. We could have video, lesson recordings, courses, messaging, schedules, community groups, AI feedback and detailed teacher pages. None of those ideas is ridiculous. The difficulty is that a list of useful ideas is not yet a product, and I was one person who still had to make the core call reliable.

How did you get the scope down to something you could actually build?

I kept returning to the moment that mattered most. A learner should be able to find the right kind of teacher, ask for help and have a live conversation. Then I looked at what had to exist around that moment for both people to feel safe enough to use it.

That still produced a lot of work because availability, matching, notifications, calls and session state are not one feature technically. But it gave me a way to challenge additions. If an idea did not make that exchange possible, safer or meaningfully easier, it probably did not need to delay the first real version.

Why did you settle on audio instead of video?

The lesson depends mainly on hearing the recitation and the correction. Video would ask for more data, a stronger connection and more comfort from both people without adding enough to that central interaction. It would also bring more permissions and more things to handle around privacy.

I wanted Tilawa to work on the kind of phone and network somebody already has. Audio gave me a better chance of doing that. It was not a decision to make the product feel smaller. It was me being specific about what the product needed to do well.

Were there features you liked but still decided against?

Recording the lessons is a good example. I can see why a learner would want to replay a correction later. I liked that part of the idea. What I did not like was everything else that arrived with storing private audio. I would need rules for access, retention and deletion, and I would be holding something very personal that Tilawa did not need in order to connect the lesson.

So I left recording out completely. I did not build it and hide it for later. I left out the storage path. That decision can be revisited if learners show that playback solves a serious problem, but then it has to be discussed together with the responsibility, not as a small item on a feature list.

What do you ask yourself when a new idea sounds useful?

I normally ask what happens to the main experience without it, what else I become responsible for if I add it and whether it will be difficult to undo. The answers are not always clear, but they stop me from treating the visible screen as the full cost.

For example, a small new action can need a permission rule, a notification, another admin state, support copy and a recovery path. A wording change can be reversed tomorrow, while a data model becomes much harder to change after payments and user records depend on it. Those things need different levels of care even if both changes look small in a design.

Did Apple or Google’s rules ever force you to change the product?

They affected how I handled the minutes and donation flow. I moved that journey to the website, but it was not just a matter of removing one in-app button. The page still had to identify the correct Tilawa account, check the paying wallet, start the charge, wait for the result and tell the user what to do if something went wrong.

I did not want the app to pretend the payment did not exist or send people somewhere that felt unrelated. The constraint pushed me to explain the purpose of the payment more clearly and make the web flow a real part of the product.

How do you know when an idea you postponed should come back?

I want real use to keep pointing at the same gap. One suggestion is worth listening to, but it is not automatically a roadmap. If learners or teachers repeatedly struggle in the same place, then I have more than an interesting idea. I have evidence that the current product is leaving something important unresolved.

I keep notes on the things I decided not to build because I do not assume the first answer will remain correct forever. I just do not want imagination to create more urgency than the people using the product. At this stage, doing fewer things properly gives me a better chance of learning what Tilawa genuinely needs next.