# How I Researched My Way to a Mobile App Idea > Most people pick an app idea the way they pick a takeaway: whatever they happen to be craving that evening. I wanted to do it differently. - Author: Bianca Correia - Published: 4 Oct 2026 - Topics: product, research, sql - URL: https://biancacorreia.com/blog/how-i-researched-my-way-to-a-mobile-app-idea Most people pick an app idea the way they pick a takeaway: whatever they happen to be craving that evening. I wanted to do it differently. Before writing a line of code, I decided to treat the idea itself as the most important thing to get right, and to spend real time researching before building anything. This post walks through that research in three parts. First, the process I borrowed from a founder who has done it well. Second, the two ideas that came out of my own digging, each with the diagrams and working code I used to test whether it had substance. Third, what I learned about choosing between them. The code is deliberately small. The point of writing it was to find out whether each idea could stand on its own logic, not to ship it. ## Starting with someone else's journey The spark was an article I came across on Twitter, written by a founder who built a consumer health app to a substantial annual recurring revenue figure, largely on his own with AI doing much of the building. What stayed with me was not the revenue but the order of his process. He picked the idea carefully, tested whether people cared through short videos, and only then built the product. His argument was that now AI has made building cheap, the scarce skill is choosing the right thing to build. His method for choosing was refreshingly practical. Spend time where real consumers spend theirs, on TikTok, Instagram and Reddit. Check keyword demand in the App Store with a tool such as Astro, looking for a market with some existing demand but not overwhelming competition. Then take a proven app and narrow its appeal to a smaller group of people, the way a meditation app might become a manifesting app, or a language app might become a chess teaching app. Only after that does the building start, and he says it should take a week or two rather than months. Figure 1 shows the routine I took from it. ```mermaid flowchart LR A([1. Observe]) --> B([2. Measure]) --> C([3. Narrow]) --> D([4. Validate]) --> E([5. Build]) ``` ## Turning the advice into a scorecard Advice is easy to nod along to and hard to apply, so I made it concrete. For each candidate idea I rated five things from one to five: how much demand I could see, how big the gap in the market looked, how strongly I personally cared about the problem, how buildable it was for a very small team, and how clearly it could earn revenue. Demand and gap carry the most weight, because an idea nobody wants, or one that a dozen products already solve well, is dead on arrival however much I like it. The ratings below are my own rough judgements, so treat them as a thinking tool rather than a measurement. Writing the weights down was the useful part, because it forced me to say out loud what I actually valued. The two scores landed within a couple of points of each other, which told me something useful straight away: no amount of spreadsheet thinking would separate them. I would need evidence from real people. Before I get to how I plan to gather it, here are the two ideas themselves. ## Idea one: a personal shopping layer that belongs to the customer The first concept is a shopping account that belongs to the user rather than to Amazon, Google, TikTok or any single retailer. Think of it as a personal shopping brain across the entire internet. Instead of fifteen scattered wishlists on fifteen different sites, there is one intelligent home for everything you want, everything you already own, what you can afford and what you are waiting on. What excites me is the shift from search results to decisions. Imagine telling the app you have £250 for a week in Paris in October, and that you already own a black trench coat, white trainers and dark jeans. Rather than fifty jumpers under £100, it returns a small capsule of pieces that work with what you own, combine into several outfits and stay under budget, and then explains its reasoning. ## The architecture in one picture Products arrive from wherever the user finds them, whether that is a pasted link, a screenshot, a typed name or a share from TikTok. They are turned into a clean product card, then filed into one account that the user owns. The decisions the user actually pays for sit on the right, and every one of them draws on the same personal data in the middle. ## Shopping DNA as a data model The real value is not in AI recommendations, which are quickly becoming commoditised. It is in a persistent profile that I have been calling Shopping DNA. It holds a typical spending range, a ceiling for spontaneous purchases and a threshold for investment pieces. It also holds style, the brands the user loves or avoids, fabric and sizing preferences, and habits such as waiting for sales or never being shown a duplicate of something already owned. Writing it as types made me notice how much of it is simple, structured data rather than anything mysterious. ## Every item has a status A universal list becomes far stickier once every product carries a status: want, waiting for a price drop, ready to buy, purchased, repurchase or no longer interested. Those states are really a small state machine, shown in Figure 3, and writing the allowed moves down stops the app from ever doing something nonsensical, such as offering to repurchase something the user never bought. ## Turning a wishlist into a verdict Take the example of a £120 serum spotted on TikTok. The user shares it to the app, which knows the lowest tracked price was £89, that the user's budget for this kind of product is £100, and that they already own two similar serums. The answer should be a plain word, not a score: buy now, consider, wait or remove. ## Spending a budget wisely The most useful feature in the whole concept is the question it answers: what should I buy first? That is a small optimisation problem. Each item has a price and a priority, the user has a budget, and the app should pick the combination that delivers the most priority without overspending. ## Starting smaller A simpler starting point came out of this research too. It is a wishlist where you add items by link, screenshot or name, set a monthly budget, and the app tells you what to buy now, what to wait for and what to save towards. Think of it as a budgeting app for shopping decisions rather than a rival to Amazon. Beginning in a single category such as beauty keeps it focused, since beauty combines frequent purchases, impulse buying, overlapping products and discovery driven by influencers. I also like the idea of missions, where you describe a need and the app assembles it within your budget and tastes. ## Idea two: a research to task workspace The second idea is a SaaS product rather than a consumer app, and it came from a frustration I recognise in my own work. Research and task management usually live in separate tools, so you end up switching between them and cross referencing by hand. The concept is built around a task tree rather than documents or folders. A project breaks into tasks and subtasks, and every saved web page, PDF, screenshot, quote or file attaches to the exact node where it matters. ```mermaid flowchart LR P["Project: Launch beta"] --> CR["Competitor research"] P --> PR["Pricing"] P --> ON["Onboarding"] CR --> C4["Compare 4 rivals"] --> PP["Page: pricing page"] --> PDF["PDF: market report"] CR --> IN["Interview notes"] --> QU["Quote: user says"] PR --> TP["Test price points"] --> BM["Page: benchmark"] --> SP["Shot: paywall"] ON --> DQ["Draft questions"] --> UX["Page: UX article"] ON --> RP["Review prompt"] --> SR["Quote: store rules"] ``` ## The data model A tree sounds exotic until you write it down. A single table of nodes, each pointing at its parent, covers projects, tasks and subtasks alike. Sources hang off any node, and tags sit alongside so that a topic can be pulled up across the whole tree. The tables below are everything the first version needs. ```sql CREATE TABLE task ( id BIGSERIAL PRIMARY KEY, project_id BIGINT NOT NULL, parent_id BIGINT REFERENCES task(id) ON DELETE CASCADE, title TEXT NOT NULL, done BOOLEAN NOT NULL DEFAULT FALSE, position INT NOT NULL DEFAULT 0 ); CREATE TABLE source ( id BIGSERIAL PRIMARY KEY, task_id BIGINT NOT NULL REFERENCES task(id) ON DELETE CASCADE, kind TEXT NOT NULL, url TEXT, excerpt TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE tag ( id BIGSERIAL PRIMARY KEY, name TEXT UNIQUE NOT NULL ); CREATE TABLE task_tag ( task_id BIGINT REFERENCES task(id) ON DELETE CASCADE, tag_id BIGINT REFERENCES tag(id) ON DELETE CASCADE, PRIMARY KEY (task_id, tag_id) ); ``` ## Opening a task shows everything at once The promise of the product is that you never search two tools to reconstruct why a task exists. In database terms that is one recursive query: start at a task, walk down through its subtasks, and gather every source attached along the way. ## Capture at the moment of saving The behaviour that makes the whole idea work is that the user is asked which task a clip belongs to at the moment of saving, not later. That removes the inbox that every other tool leaves you to sort. A lightweight browser extension would send the page address, title and any highlighted passage, along with the chosen task, to the server. ## Where it sits in the market What convinced me this was worth considering was the gap analysis. Tools such as ONES and Draft lean towards general team task management, while Raindrop and Fabric lean towards general knowledge capture. Nobody I found combines both around a strict task hierarchy, which leaves a narrower but underserved audience. ## Choosing between them The scorecard gave me a near tie, and that matches how it feels. The shopping idea has the larger audience and the clearer consumer habit, but it also faces giants and needs data from many retailers. The workspace has a smaller audience and a visible gap, and it comes from a problem I feel myself, which makes it much easier to talk to the right users. Neither is obviously wrong, so the next step is not more thinking. It is the founder's own test: post about each idea as content, build a tiny mock up of the killer feature, and see which one makes people ask for the link. ## What the research taught me Four lessons stand out. First, spend as much time choosing as building, because a carefully researched idea saves months of wasted effort. Second, narrow the audience, since a clear problem for a specific group is easier to explain, build and test than a general solution. Third, validate before you commit, using content and conversations with real people to see whether anyone actually wants it. Fourth, and the one that surprised me, write the core logic down as code or diagrams early. Twenty lines of planner or a single recursive query showed me which parts of each idea were solid and which were wishful thinking, and it cost an afternoon rather than a month. I am still weighing these ideas, but the process has already paid off, because I now know why I would choose one over another, not just which one I like best.