Question 1

Build for a practice everyone agrees is right but nobody does

Flavius D. · Accepted Answer

The richest product territory is the gap between "known best practice" and "what people actually do." Structured interviews are universally accepted as the strongest predictor of job performance, and almost nobody runs them. Double-entry bookkeeping, security key logins, automated tests, pre-commit hooks: same pattern. Look for a practice that experts in your industry agree is correct and operators skip because it is inconvenient, then build the tool that makes the right thing the easy thing. The onboarding pitch writes itself.

Question 2

Use search demand to decide what features to build

Zoltan Szogyenyi · Accepted Answer

Before building a new feature or component, check what people are actually searching for. Use tools like Semrush to find keywords with real demand. When Flowbite saw search volume for "avatar tailwind" and "datepicker tailwind," they built those components and captured the traffic. Let search data guide your roadmap instead of guessing what users want.

Question 3

Set up analytics before you start scaling traffic

Zoltan Szogyenyi · Accepted Answer

Do not invest in scaling traffic until you have analytics running. Use Microsoft Clarity (free) or Hotjar for heatmaps, rage click detection, and session replays. Watch your bounce rate and average time on site (one minute is a reasonable benchmark to start). If users leave immediately, more traffic just means more people leaving. Fix the experience first, then scale.

Question 4

Record videos with your face in the corner

Raul · Accepted Answer

Use Loom or similar tools to record product walkthroughs with your face visible in the corner. People trust faces. These videos work as blog post embeds, YouTube content, and social proof simultaneously. Pages with face-in-corner walkthroughs consistently convert better than text-only pages.

Question 5

Build products from real client problems, not speculation

Cristian · Accepted Answer

Every Cozmoslabs product started with a problem their clients kept running into. They do not build on speculation or trends. When you know a product will take a year to execute, you need to be certain the problem is real. Spot the pattern in client requests, validate that the pain is genuine, and only then commit to building. Being picky about what you build is a feature, not a limitation.

Question 6

Build the simplest version first

Mircea · Accepted Answer

Mircea built SingleFax in a weekend by refusing to add anything beyond the core action: upload, enter a number, pay, send. No user accounts, no dashboards, no analytics. If your v1 takes longer than a week, you're building too much. Strip it down until a complete stranger can use it in under 60 seconds.

Question 7

Remove all friction: no signup, no subscription

Mircea · Accepted Answer

Every form field you add, every account creation step, every subscription commitment is a point where customers leave. I removed all of them. No signup, no login, no monthly plan. Just pay and use. For occasional-use products, this is the difference between making money and making nothing.

Question 8

Manual curation is a moat, not a limitation

Raul · Accepted Answer

Algorithms can scrape job boards. Nobody can automate the judgment call of "is this company actually calm or just marketing itself as calm?" Raul manually researches every company in his directory, checking employee tenure, real policies, and community feedback. That process is slow, but it's the entire value proposition. What feels like a bottleneck is actually what customers are paying for.

Question 9

Start with a spreadsheet, not a SaaS

Raul · Accepted Answer

Raul's entire business started as a personal spreadsheet shared with friends. He didn't buy a domain, set up payments, or write a line of code until real people asked him to keep going. A spreadsheet forces you to do the work manually, which teaches you what the actual product is. If your idea can't survive as a spreadsheet first, it probably won't survive as a SaaS either.

Product