My learning journey in shaping ideas into usable applications through ideation, prototyping, development, and testing.
Most of my app ideas begin as a sentence in a notes file: "an app that tells me what to cook from what I already own". A sentence costs nothing, so I collect plenty. The skill is deciding which ones earn weeks of work and how to move them from a sentence to something people can tap.
I start with the problem, not the feature list. I write who has the problem, when it happens, and what they do today. For Spooniq, the situation was choosing food and wasting what sat in the fridge. Writing the situation down shows me whether the problem is real and frequent. If I cannot name the moment it hurts, the idea waits.
Next comes cheap validation. I talk to a few people who match the description and ask about their last experience with the problem, not whether they like my idea. People are polite about ideas and honest about past behavior. I also look at what exists. Competitors prove demand, and their reviews list the gaps. A one-star review that says "too many steps to add an item" gives me a design goal for free.
Then I shrink the scope. I list every feature I can imagine and cut until one core loop remains: the smallest sequence a user repeats and gets value from. For a meal app, that loop is add what you have, get suggestions, pick one. Accounts, sharing and settings come later, if the loop holds up. A small scope ships sooner, and shipping teaches more than planning.
UI planning follows. I sketch screens on paper, then build a clickable prototype in Figma. A prototype lets someone tap through the flow before I write any Flutter. I watch where they stall and fix the layout while changes cost minutes. I also define the visual basics here: colors, type, spacing and a few components, so development reuses them.
Development begins with the riskiest part. If the idea depends on a camera scan, a location lookup or a background sync, I prove that piece first, because a failure there changes the whole plan. In Geotag Photo ID, the core question was how to attach reliable location data to a photo, so that part got built before the screens around it. I use Flutter for mobile and Vue for web, with Firebase for authentication and data, since one service covers login, storage and hosting for small projects.
I build in thin vertical slices. One slice runs from a screen through the logic to the data store for a single action, such as saving an entry. Each slice works end to end before I start the next. This keeps the app runnable every day, and I never face a week of integration at the end.
Testing happens in layers. Unit tests cover the rules that decide results, like validation and calculations. Manual passes cover flows on a real phone, including a poor connection and an empty account. I hand the build to a few testers early, even when it looks rough, and I ask them to do one task while I stay silent. Their confusion becomes my task list.
Iteration decides the outcome. After each release I read feedback, check what people actually use, and choose one change at a time. Some features I loved go unused, and I remove them. Some small fixes, such as a clearer button label, lift completion more than a big new feature. I keep a short changelog so I remember why each decision happened.
Finishing matters too. An app needs an icon, a store description, a privacy statement and a crash report setup before strangers can use it. I treat those as part of the work, not leftovers. The distance between an idea and a real app is mostly small, unglamorous steps repeated in order, and each one I complete makes the next idea easier to start.