- Published on
I Did a Week of Market Research in an Afternoon — From My Terminal
- Authors

- Name
- Tina Park
- @tinaparklive

Every project I start eventually hits the same uncomfortable moment. The demo works, I'm excited, and then a quiet voice asks: am I the only person who actually needs this?
For Spoken Kitchen — my app (which started as a Mother's Day project) that helps immigrant families capture, translate, and preserve heirloom recipes passed down through voice — that question really mattered. If there's already a StoryWorth-for-recipes with translation built in, I'd rather find out on day one than three months in.
The honest answer to that question is market research: who else is here, what they charge, how they position, who the customer is, and where the gap is. Normally that's a week of open tabs, half-finished spreadsheets, and pricing pages that won't load. This time I did the whole thing in an afternoon, entirely from my terminal, using the Nimble CLI.
I'm not going to walk through every finding here — I published all of it. The full research, every script, and the raw data live in this repo, and the results are deployed as an interactive page here. This post is about what the process was actually like, and what I walked away believing.
The mental shift that made it click
The thing that unlocked this wasn't a feature. It was reframing the whole project as one simple mapping: a business question becomes a command.
"Who are all the players?" is a search sweep. "What do they charge?" is pulling pricing pages. "How do they position?" is grabbing competitor homepages and reading them next to how real buyers describe the problem. "Who's the customer?" is reading the actual threads where people are already asking for this.
With Nimble that mapping is almost literal. Each question is one command — search hands back JSON, extract hands back clean markdown — instead of a page I have to babysit:
# Who are the players? — a search sweep, results as JSON
nimble search --query "voice recipe app translation" --search-depth deep --max-results 20 --format json
# What do they charge / how do they position? — pull the page as markdown
nimble extract --url "PRICING_URL" --format markdown -r
Every phase became a small shell script that called nimble and dumped the raw output to a folder. By the end I had a directory I could re-run, not a memory of tabs I'd closed. That's the part that changed how the work felt: the research became an artifact instead of an afternoon.
What surprised me
It found competitors I didn't know to look for. I went in with a shortlist I was confident about. The discovery sweep surfaced two voice-to-recipe products that weren't on it at all. That's the part that actually mattered — anyone can confirm what they already suspect, but having the search widen on me and catch what I'd have missed is the whole reason to do research instead of guessing.
It was live, not a training snapshot. I was reading pricing and Father's Day homepage copy that was current to that day. For competitive work that's the difference between real and theater — last year's pricing tells you nothing.
The customer was already telling me what to build. The most useful stuff wasn't the competitor pages, it was the buyer-side searches. People are already translating family recipes by hand, copy-pasting them into translators, scrambling to save a grandparent's handwriting after a funeral. The need is clearly real, and clearly nobody's productized it well. You don't get that from a competitor's marketing — you get it from listening to where people are already struggling.
The part that was genuinely annoying
It wasn't all clean, and I'm including the friction on purpose, because the pitch for tools like this is always frictionless and the honest version is that I still spent a little time reading errors and adjusting.
The one that taught me something: a few pricing pages — Remento, CreateMyCookbook, Mixbook — render their numbers in JavaScript or bake them into an image, so my first nimble extract pass came back with everything except the price. The fix wasn't to fight the page; I fell back to a nimble search query and read the figure straight out of the result snippets, which already had it. The lesson that stuck: when one command type hits a wall, the next one over often just walks around it.
The rest were small. A couple of the flags I reached for — a deeper search depth, an answer-synthesis option — turned out to be enterprise-only and quietly 403'd on my standard tier until I worked out why. And the CLI reads the API key from the environment, not from a .env file on its own, so I load the file into the shell (set -a; . ./.env; set +a) at the top of each script — ten confused minutes before that clicked. Small detours, not the days that scraping each site by hand would've cost.
A note on what I collected
Everything I pulled was public: competitor pricing, homepages, and open discussion threads. The repo reflects that — it has the public business pages and the buyer pain aggregated into themes, with the personal details stripped out. Market research shouldn't mean hoarding strangers' posts, and the good tools make the responsible version the easy one.
What I actually walked away with
I came in asking whether I was the only one who needed this. I left with the opposite of a vibe — a priced, positioned, customer-named picture of the market, and a clear empty space where Spoken Kitchen fits. The specifics are all in the repo and the results page if you want to see the charts.
But the bigger takeaway is about the shape of the work. Market research used to be a thing you scheduled a week for and dreaded. Turning it into a folder of scripts changed it from a chore into something I'll just do now — early, often, and again whenever the market moves. That's the real unlock: not that it was faster, but that it got cheap enough to become a habit.
And the answer to the question? No, I'm not the only one who needs this. I might just be the first one building it.
If you want to reproduce it or poke at the data, everything's open: the research repo has the scripts and raw data, and the deployed page has the findings.