~ / startup analyses / How to Find SaaS Ideas: 7 Approaches, 12 Startups
How to Find SaaS Ideas: 7 Approaches Applied to 12 Real Startup Ideas
Rob Walling's "How to Find SaaS Ideas" worksheet lays out seven approaches for finding B2B SaaS ideas.
Each approach has different advantages -- some give you deep founder-market fit from day one,
others give you a distribution wedge or a defensible niche.
The key insight is that finding an idea is not a linear process.
You start with a problem and the people it affects, and you work backwards from there.
The seven approaches:
Scratch your own itch -- solve a problem you personally experience
Solve a problem at your day job -- identify pain in your current or past work environment
Translate an existing idea into a new niche -- take something that works horizontally and niche it down
Enter a large space with a hated incumbent -- find the market where everyone complains about the dominant tool
Explore fast-growing ecosystems -- ride a wave that is pulling all boats up
Analyze what you spend money on at your day job -- follow the budget trails for proven pain
Build on an existing product -- extend, integrate with, or compete against something already established
For each of the 12 ideas below, I name the approach, answer all 6 reflection questions from the worksheet,
run through the full checklist, and give the honest take on why this could work or fail.
2. 1. On-Call Post-Mortem Tool for Engineering Teams
Approach: Scratch your own itch
Every engineer who has been on-call has lived the same nightmare: a 3am alert, a scrambled fix,
a vague Slack thread that nobody reads, and then the same incident happens six weeks later
because nobody wrote a real post-mortem. PagerDuty has an incident timeline. Notion has a template.
Neither forces the right workflow. This is a tool that turns an incident timeline into a structured
post-mortem in one click, tracks action items to completion, and surfaces recurring failure patterns
across incidents over time.
Problem and people affected
On-call engineers and engineering managers at companies running any production infrastructure.
The pain: incidents repeat, knowledge is lost, post-mortems are written as checkbox exercises
nobody reads. The cost is real -- repeated incidents mean more downtime, more revenue loss,
more engineer burnout.
Checklist
Problem identified: Incident knowledge is not captured or acted on systematically.
Own itch: Yes -- every engineer on-call has felt this. The founder IS the user.
Translate to niche: Not applicable -- this is already niche (engineering teams).
Hated incumbent: PagerDuty is the incumbent. Engineers dislike it for being alert-heavy and workflow-light. Jira is used for action items but disconnected.
Fast-growing ecosystem: DevOps and SRE tooling is a consistently growing category.
Day job spending: Engineering teams already pay for PagerDuty, Datadog, incident.io. Budget exists.
Unique differentiation: Focus on the post-incident learning loop, not the alerting or on-call scheduling.
Reflection Questions
Q1: Problems in personal/professional life this solves?
The on-call experience is universal in software engineering. The specific pain: an incident happens, a postmortem is written (or not), action items are added to Jira, nobody follows up, the incident recurs. Three months later someone asks "haven't we seen this before?" and the answer is yes, twice, but nobody fixed it. A tool that closes the loop between incident, post-mortem, action item, and verification is solving a problem every engineering team experiences.
Q2: Network in this vertical?
Software engineers are reachable everywhere -- Twitter, Hacker News, engineering blogs. If you're an engineer, you already have the network. The specific advantage: SRE and platform engineer communities are tight and share tooling recommendations freely. One Show HN post with a working product reaches thousands of ideal customers.
Q3: Software your past company paid for monthly?
PagerDuty ($20-40/user/month), Datadog ($15-30/host/month), incident.io ($30-50/user/month), Jira ($8-20/user/month). The budget category is well established. A post-mortem and incident learning tool at $10-20/user/month slots directly into a budget line that already exists.
Q4: Unique focus in a competitive space?
The niche is the learning loop specifically, not the alerting or on-call rotation. Competitors (PagerDuty, Opsgenie) own the alerting problem. incident.io owns the real-time coordination problem. Nobody owns the "did we actually learn from this" problem. That's the wedge.
Q5: Fast-growing ecosystems or trends?
Platform engineering as a discipline is growing. The SRE function, once Google-only, is now standard at companies with 20+ engineers. As more companies run distributed systems, the cost of repeated incidents grows, and the demand for systematic learning tools grows with it.
Q6: Which approach resonates most?
Scratch your own itch. The advantage is absolute credibility with the target audience. An engineer who has been on-call and built the tool they wished existed can talk to customers in their language, spot feature requests that are real vs. nice-to-have, and earn trust fast. The downside: it's easy to build what you wanted rather than what the market wants. Disciplined customer discovery is still required.
3. 2. Internal Knowledge Search for Engineering Teams
Approach: Solve a problem at your day job
Engineering teams at companies with 20+ engineers are drowning in scattered knowledge:
architecture decisions live in Confluence, runbooks in Notion, API docs in Swagger,
code context in GitHub, incident history in Slack threads. When a new engineer joins
or an incident happens, finding the right information takes 45 minutes of context-switching.
This is a unified search layer that indexes all of it and returns the right answer,
not a list of documents.
Problem and people affected
Engineering managers, staff engineers, and on-call engineers at companies that have been running
for more than two years and have accumulated substantial internal knowledge that nobody can find.
The cost is measured in engineer-hours wasted per week per team.
Checklist
Problem identified: Internal engineering knowledge is siloed and unfindable.
Day job origin: Every engineer who has joined a company and asked "where is the runbook for X?" has felt this. Classic day job problem.
Translate to niche: Enterprise search exists (Glean, Guru). Niche down to engineering teams specifically -- different indexes, different query patterns.
Hated incumbent: Confluence is the dominant internal knowledge tool. Engineers hate Confluence with a passion that is remarkable and consistent.
Ecosystem growth: AI-native search is growing. The ability to actually answer questions (not list pages) is a step-change improvement over existing tools.
Day job spending: Confluence ($5-15/user/month), Notion ($8-15/user/month) -- budget exists.
Differentiation: Engineering-specific indexing: understands code, runbooks, ADRs, architecture diagrams. Not a generic enterprise search.
Reflection Questions
Q1: Personal problem this solves?
"Where is the documentation for this?" is a question asked dozens of times per week at any engineering team larger than 10 people. The pain is acute when you're on-call at 3am and need to find the runbook for a service that was built by someone who left a year ago. This problem costs real time and creates real incidents.
Q2: Network to leverage?
Engineering managers are the buyers here. LinkedIn targeting by "Engineering Manager" or "VP Engineering" is precise. The demo sells itself: index a company's Confluence + GitHub in 10 minutes, show them finding an answer that would have taken 20 minutes of search. That demo converts.
Q3: Software past companies paid for?
Every company pays for Confluence or Notion. Most pay for Slack, GitHub, and some kind of documentation tool. The search problem is caused by having too many of these tools simultaneously. The opportunity is to be the intelligence layer on top of tools they are already committed to.
Q4: Differentiation in competitive space?
Glean raised $260M and targets enterprises. The gap is the 20-200 engineer company that can't afford Glean and doesn't need its complexity. Engineering-specific: understands what an ADR is, can answer "which team owns the payment service?", knows that a GitHub README is different from a Jira ticket. That specificity is the wedge Glean can't occupy without bloating.
Q5: Fast-growing trends?
AI-native search for internal tools is exploding. The ability to ask a question in natural language and get a synthesized answer (not a list of links) is a genuine step change. Every company that has set up an internal ChatGPT or Slack bot has validated that employees want this -- they just want it to actually work.
Q6: Most resonant approach?
Day job problem. The advantage is that you've seen the exact failure mode -- not a hypothetical version of it. You know which team at which company couldn't find the deployment runbook. You know which manager spent two hours searching Confluence for a decision that was made in a Slack thread nobody exported. That specificity makes the sales story real and compelling.
4. 3. Stripe-Style Billing for Law Firms
Approach: Translate an existing idea into a new niche
Stripe and Chargebee solved subscription billing for SaaS companies beautifully.
Law firms have a completely different billing model -- hourly rates, retainers, matter-based billing,
trust accounts, IOLTA compliance -- and they are doing it in practice management software
from the 1990s (Clio, MyCase) that was never designed around billing as a first-class product.
This is Stripe's developer experience, API-first philosophy, and clean UX, applied
to the specific billing complexity of a law firm.
Problem and people affected
Small and mid-sized law firms (2-30 attorneys). The billing admin (often the managing partner
or office manager) loses hours each week reconciling time entries, generating invoices,
chasing payments, and managing trust account compliance. Every hour spent on billing
is an hour not billing.
Checklist
Problem identified: Legal billing is complex, compliance-heavy, and done with terrible software.
Translate to niche: Yes -- Stripe's model translated to the legal vertical.
Unique niche focus: IOLTA trust account compliance, matter-based billing, retainer management. None of these exist in generic billing tools.
Hated incumbent: Clio is the dominant legal practice management tool. Law firms use it but find it bloated and expensive for billing alone.
Day job spending: Law firms pay for Clio ($49-99/user/month), plus separate payment processors. High spend per user.
Differentiation: API-first, developer-quality UX, legal compliance built in. Clio tries to do everything; this does billing exceptionally well.
Reflection Questions
Q1: Problem from personal/professional life?
Anyone who has worked at or with a law firm has seen the billing chaos. Attorneys track time in spreadsheets or sticky notes, admin manually enters it into outdated software, invoices go out late, clients dispute them, trust account reconciliation is a compliance nightmare. The firm loses 5-15% of billable revenue to billing inefficiency and late payments.
Q2: Network in legal vertical?
Law firm administrators and managing partners are reachable through bar association events, legal tech conferences (ILTA, ABA TECHSHOW), and LinkedIn. If you have one attorney contact, they know 20 others. The referral rate in this community is very high -- attorneys trust tool recommendations from peers above all else.
Q3: Software law firms pay for?
Clio ($49-99/user/month), PracticePanther ($49-79/user/month), separate payment processing (LawPay charges 1.95-2.95% per transaction on top of a monthly fee), time-tracking tools, and document management. The billing stack alone often costs $200-400/month for a small firm. A consolidated, better-designed tool can undercut that.
Q4: Unique position in competitive space?
Clio and MyCase compete on breadth -- they want to be the OS for the law firm. The position here is depth: be the best billing product, full stop. "Stripe for law firms" is a sentence that both attorneys and legal admins immediately understand. Depth beats breadth for the specific buyer who is tired of paying for 15 features they don't use to get 3 they do.
Q5: Ecosystem trends?
Legal tech is one of the last professional services verticals to modernize. LegalZoom, Clio, and Ironclad have proven that attorneys will pay for better software. The sub-trend: IOLTA compliance automation is getting regulatory attention in several states. A tool that makes trust accounting less painful has regulatory tailwinds.
Q6: Most resonant approach?
Translating an existing idea into a new niche is powerful because the product model is proven -- you're not inventing billing software from scratch, you're applying Stripe's approach to a context where Stripe can't go. The risk: domain complexity. Legal billing has compliance requirements that take months to understand. The reward: that same complexity is the moat once you've built it.
5. 4. Project Management for Creative Agencies
Approach: Enter a large space with a hated incumbent
Creative agencies (design studios, brand agencies, video production houses) run on projects
but hate every project management tool built for them. Asana is built for product teams.
Monday.com is built for operations teams. Both have "agency templates" that feel like an afterthought.
What agencies actually need: brief management, creative review workflows, client approval gates,
time tracking against project budgets, and file management -- all in one place, with an interface
that doesn't look like a spreadsheet.
Problem and people affected
Creative directors, project managers, and account leads at agencies with 5-50 people.
They're managing 20-50 concurrent projects, coordinating feedback from clients who don't use
their tools, and tracking time to invoice correctly. The overhead is crushing.
Checklist
Problem identified: Generic project management tools don't fit the creative agency workflow.
Hated incumbent: Asana and Monday.com are the giants. Both are consistently criticized in agency forums for missing creative-specific features.
Translate to niche: Horizontal project management translated to the creative agency vertical.
Fast-growing ecosystem: The number of agencies and boutique creative studios has grown with the creator economy and content marketing explosion.
Day job spending: Agencies pay for Asana, Monday, Harvest (time tracking), Frame.io (video review), Loom -- often $500-1000/month in fragmented tools. Consolidation opportunity.
Differentiation: Creative review and approval workflow as a native feature, not an add-on. No generic project management clutter.
Reflection Questions
Q1: Problem from personal experience?
Anyone who has worked at or hired a creative agency has seen the chaos: feedback sent in email threads, revision requests lost in Slack, client approvals tracked in a spreadsheet nobody updates, time logged at the end of the month from memory. The direct cost is scope creep, missed deadlines, and invoices that don't match what was actually delivered.
Q2: Network in creative agencies?
Creative directors and agency founders are highly active on Twitter, Instagram, and LinkedIn. The agency community has strong word of mouth. Getting 5 agency founders to use the product publicly generates significant social proof in a community where everyone watches what everyone else is using.
Q3: Software agencies pay for?
Asana ($10-24/user/month), Monday.com ($12-20/user/month), Harvest ($12/user/month), Frame.io ($15-50/user/month for video review), Figma ($12-45/user/month). A 10-person agency is spending $500-1500/month on tools that don't talk to each other. The consolidation pitch is: one tool, half the cost, all the workflow.
Q4: Differentiation from Asana/Monday?
Three features Asana doesn't have that agencies actually need: (1) client-facing review portals where the client approves work without needing a login, (2) brief templates that flow directly into project scopes and timelines, (3) budget tracking tied to time entries per project. Add a UI that looks like it was designed by a creative person, not a product manager, and you have a compelling story.
Q5: Ecosystem trends?
The content marketing and creator economy boom has expanded the number of boutique creative studios dramatically. Agencies that used to serve big brands now serve startups and scale-ups, who have budgets but aren't used to paying for agency-tier software. That new segment (small agencies serving tech companies) is underserved by both Asana and legacy agency tools.
Q6: Most resonant approach?
Hated incumbent strategy is powerful because the go-to-market writes itself. Search "Asana alternatives for agencies" -- real traffic, real intent. Post in agency owner Facebook groups: "What do you hate most about Asana?" and watch the thread explode. The risk: Asana and Monday have enormous resources and will eventually add the features you build. Your moat is community and depth of specialization, not feature parity.
6. 5. MCP Server Registry and Analytics
Approach: Explore fast-growing ecosystems
Anthropic's Model Context Protocol (MCP) is a standard for connecting AI assistants to external tools and data sources.
It was published in late 2024 and has already been adopted by hundreds of developers building MCP servers
that let Claude, Cursor, and other AI tools interact with databases, APIs, file systems, and services.
There is no central registry, no quality signal, no analytics, and no way to discover or compare MCP servers.
This is the npm registry for MCP -- discovery, versioning, download analytics, and compatibility signals.
Problem and people affected
Developers building with MCP (finding and evaluating servers), and developers publishing MCP servers
(wanting distribution and usage analytics). Secondarily: AI teams at companies evaluating which
MCP servers to allow in their developer environment.
Checklist
Problem identified: MCP server discovery and quality evaluation is manual and scattered across GitHub repos.
Fast-growing ecosystem: MCP adoption is accelerating rapidly. Every major AI coding tool is adding MCP support.
Translate to niche: npm's model (registry + analytics + discoverability) applied to the MCP ecosystem specifically.
Day job spending: Companies investing in AI-native developer tooling already have budget for MCP-adjacent infrastructure.
Unique differentiation: First-mover advantage. Quality signals (compatibility, test coverage, update frequency) not available anywhere.
Reflection Questions
Q1: Problem from personal experience?
Any developer building with Claude or Cursor has tried to find the right MCP server for a task and ended up in a GitHub search rabbit hole. "Is there an MCP server for Postgres?" -- yes, there are six, with no quality signal to differentiate them. The discovery problem is painful and gets worse every week as more servers are published.
Q2: Network in this ecosystem?
The MCP builder community is on Twitter/X and Discord. It's small enough today that reaching every active MCP server author is possible with a few days of outreach. The community is eager for infrastructure that helps their servers get discovered. Early adoption by server authors drives supply-side growth organically.
Q3: Software companies pay for in this space?
Companies building on MCP already pay for AI API credits (Anthropic, OpenAI), developer tooling (Cursor, Copilot), and infrastructure (Vercel, Railway, Render). A registry and analytics tool at $29-99/month for teams who need to audit and govern which MCP servers are approved for use slots into existing developer tooling budgets.
Q4: Differentiation as the ecosystem matures?
First-mover plus data network effect. The registry that gets indexed first becomes the source of truth. Add quality metrics (test coverage, version stability, compatibility matrix across AI clients), security scanning, and enterprise governance features (approve/deny specific servers for your company), and you have a defensible position that a GitHub search can't replicate.
Q5: Ecosystem growth?
MCP is in the "GitHub pre-npm" phase right now. The ecosystem exists, there is real developer demand, and nobody has built the infrastructure layer yet. The window to become the canonical registry is open for maybe 12-18 months. After that, either someone builds it or Anthropic does internally. Moving fast here is existential.
Q6: Most resonant approach?
Fast-growing ecosystem. The advantage is timing -- you can build a defensible position before the market realizes it needs one. The disadvantage is risk: the ecosystem might not grow as fast as expected, or Anthropic might build this themselves. Mitigation: launch a free public registry quickly, establish community presence, and build revenue features on top of the distribution you've already created.
7. 6. SaaS Spend Analytics for Engineering Managers
Approach: Analyze what you spend money on at your day job
Engineering teams at companies with 20-200 engineers are paying for dozens of SaaS tools --
Datadog, Sentry, GitHub, Linear, Notion, PagerDuty, Vercel, AWS, and 15 others --
with no consolidated view of what is being used, by whom, at what cost, and whether it is worth it.
Finance sees SaaS line items. Engineering managers see the tools. Nobody sees the overlap,
the unused seats, or the tools that could be consolidated. This is the tool that shows you
what your engineering stack is actually costing you, per-tool and per-developer.
Problem and people affected
Engineering managers, VPs of Engineering, and CTOs at companies between seed and Series B --
where the tool stack has proliferated but the budget conversation hasn't happened yet.
Also CFOs at these companies who can't get a clear picture of engineering software spend.
Checklist
Problem identified: Engineering software spend is invisible, fragmented, and wasteful.
Day job spending origin: Every engineering manager has approved a Datadog invoice they didn't fully understand. The idea comes directly from watching the budget.
Hated incumbent: Generic SaaS spend management tools (Zylo, Torii, Blissfully) exist for IT but don't understand engineering-specific tools and usage patterns.
Translate to niche: General SaaS spend management niched down to engineering teams specifically.
Day job spending: Companies already pay for some version of this -- or are painfully aware they need to. The budget pain IS the budget.
Differentiation: Engineering-specific: understands that a Datadog spike is different from an unused Notion seat. Benchmarks your spend against similar-sized engineering orgs.
Reflection Questions
Q1: Personal problem?
An engineering manager at a 50-person startup is paying for GitHub Enterprise ($21/user x 30 devs = $630/month), Datadog (variable, often $3-8k/month), Sentry ($26-80/month), Linear ($8/user), PagerDuty ($21/user), Vercel (variable), and ten other tools. At any point in time, 15-30% of seats are unused (people who left, tools nobody uses anymore), and nobody has the full picture. That's a real, recurring cost center that every engineering manager recognizes immediately.
Q2: Network to validate?
Engineering managers and CTOs are the exact audience. LinkedIn is precise here -- "Engineering Manager" + company size filters get you exactly the right people. The pitch is simple: "I'll show you where your engineering team is wasting money on software. Free audit for first 10 users." That offer closes itself.
Q3: Software inspiration from day job?
The inspiration IS the software spend. Datadog at $5k/month, PagerDuty at $600/month, GitHub at $1k/month, Vercel at $500/month -- the stack is the idea. The question "is this spend worth it and is it being used?" is asked in every engineering all-hands when growth slows. A tool that answers it continuously, not just during the annual budget review, is valuable.
Q4: Differentiation?
Generic SaaS spend tools (Zylo, Torii) see every tool the same way. An engineering-specific tool understands that Datadog costs spike with traffic, that GitHub seats are correlated with headcount, that a Vercel bill needs to be attributed to specific projects. Benchmarking: "your Datadog spend is 40% above average for your engineering team size" is a sentence Zylo can't say and an engineering manager pays attention to immediately.
Q5: Ecosystem trends?
Software cost consciousness has increased dramatically post-2022. Engineering teams that were spending freely on tooling are now being asked to justify every line item. The CFO-CTO conversation about software spend is happening at more companies than ever. The timing is excellent for a tool that makes that conversation data-driven.
Q6: Most resonant approach?
Analyzing day job spending is powerful because the problem is immediately legible to any potential customer. You don't need to explain what the pain is -- you just need to quantify it. The risk: this feels like a tool companies build internally. The insight: they never do, because the person who would build it is too busy using the tools to audit them.
8. 7. Founder CRM for Pre-Seed Fundraising
Approach: Scratch your own itch
First-time founders raising a pre-seed round are managing 100-200 investor conversations simultaneously
with no tooling designed for this specific workflow. Salesforce is designed for enterprise sales reps.
HubSpot is designed for marketing. Notion templates fall apart at 50 contacts. Founders end up in
a spreadsheet, losing track of intros, warm leads, and who said "come back in 6 months" three months ago.
This is a CRM designed for the single most important sales process a pre-seed founder will ever run.
Problem and people affected
Pre-seed and seed founders, typically 1-3 people, managing their first institutional fundraise.
Also relevant: angel investors managing their deal flow (the other side of the same relationship graph).
Checklist
Problem identified: Founder fundraising process is a complex sales workflow with no dedicated tooling.
Own itch: Any founder who has raised knows the spreadsheet chaos. The tool is built for the person building it.
Translate to niche: CRM concept translated to the fundraising workflow specifically.
Hated incumbent: The "incumbent" is the Google Sheet. No dedicated tool has won this category despite obvious demand.
Fast-growing ecosystem: Pre-seed fundraising activity has grown. More startups, more first-time founders who don't have the playbook.
Differentiation: Fundraising-specific: stage tracking (warm/intro/meeting/term sheet), round timeline, investor relationship notes, "come back in X months" reminders. Nothing generic.
Reflection Questions
Q1: Personal problem?
Raising $500k-$3M from 10-20 angels and micro-VCs means managing 100+ conversations in parallel. An intro from one investor leads to three others. Some investors say yes, some no, some "maybe in 6 months." Without a system, you forget to follow up, miss warm intros, and extend your raise by 2-3 months. Time in fundraise directly costs equity dilution and founder attention away from the business.
Q2: Network in this community?
The pre-seed founder community is on Twitter, in YC alumni networks, in Indie Hackers, and in local startup communities. The referral rate is extremely high -- if a founder has a good experience with a fundraising tool, they tell every founder friend who is about to raise. Product-led growth through the founder community is fast and organic.
Q3: Existing software that founders pay for?
Most founders pay for nothing because nothing exists that's good enough. Some use Streak (Gmail CRM) at $15/user/month. Some use Notion ($8/user/month) with a template. A purpose-built tool at $29-49/month during a raise is a trivial cost against the value of closing the round faster. Post-raise, the tool becomes a cap table management and investor update tool -- an easy upsell.
Q4: Differentiation?
The three features that matter: (1) calendar integration that auto-logs investor meetings without manual entry, (2) warm intro request tracking so you know who owes you an intro and to whom, (3) round timeline view that shows velocity and projected close date. None of these exist in Salesforce or HubSpot. The interface should be designed for a founder managing a raise alone, not a sales team of 10.
Q5: Ecosystem trends?
The pre-seed funding market is volatile but the structural trend is clear: more founders are raising, more angels are investing, and the raise process has gotten more complex (SAFE notes, rolling closes, international investors). Tools that help founders navigate this complexity have real and growing demand.
Q6: Most resonant approach?
Scratch your own itch, because the founder IS the customer. The credibility of saying "I built this while raising my own round" is enormous. The risk: the market is narrow (only pre-seed/seed founders at a specific moment in their journey). The mitigation: once the round closes, pivot the use case to investor relations and cap table communication, which is a recurring revenue use case instead of a one-time purchase.
9. 8. Appointment Scheduling for Field Service Workers
Approach: Translate an existing idea into a new niche
Calendly and Cal.com solved appointment scheduling for knowledge workers beautifully.
But field service workers -- plumbers, electricians, HVAC technicians, cleaning crews --
have completely different scheduling needs: variable job duration, travel time between jobs,
multi-technician dispatching, equipment requirements, and on-site vs. remote work windows.
Calendly breaks completely in this context. This is the Calendly for the trades.
Problem and people affected
Independent tradespeople and small service companies (2-20 technicians). The scheduler/dispatcher
(often the owner or their spouse) is manually managing jobs in a paper calendar or a spreadsheet,
fielding calls between jobs, and losing revenue to scheduling gaps and no-shows.
Checklist
Problem identified: Field service scheduling has unique constraints that consumer scheduling apps ignore.
Translate to niche: Calendly's model translated to the trades and field service vertical.
Hated incumbent: ServiceTitan is the enterprise-priced dominant tool ($100-300/month minimum). Jobber is the SMB version -- widely used, consistently criticized for UX complexity.
Fast-growing ecosystem: Home services is a growing market. Labor shortage has forced trade companies to adopt digital tools faster than ever.
Day job spending: Trade businesses pay for Jobber ($35-100/month), scheduling apps, and often a separate CRM. Consolidation opportunity.
Differentiation: Route optimization built in, travel time buffers, technician skill matching, customer SMS reminders. Calendly doesn't know what a job window is.
Reflection Questions
Q1: Problem from personal experience?
Anyone who has hired a plumber or HVAC tech has experienced the scheduling chaos from the customer side: a 4-hour window, a call when they're 30 minutes out, a reschedule two hours before the appointment. The business side is equally chaotic: the owner managing 8 jobs a day by phone, double-booking, and guessing at travel time. The problem is visible and felt by everyone who interacts with field service businesses.
Q2: Network in trades?
Trade business owners are active in Home Service Business Facebook groups, HVAC contractor forums, and industry associations. They are less digital-native than SaaS buyers but they are increasingly online and increasingly willing to pay for tools that save them time. A referral from one plumbing business owner to another in their area network converts at very high rates.
Q3: Software field service companies pay for?
Jobber ($35-99/month), ServiceTitan ($145-398/month), Housecall Pro ($49-109/month). These are established budget lines. The gap is a scheduling-first tool that doesn't require buying an entire field service management suite to solve the specific problem of smart, conflict-free scheduling with customer communication built in.
Q4: Differentiation from Jobber?
Jobber does everything for a field service business. The differentiation is doing scheduling exceptionally well: real-time route optimization, automatic travel time calculation between jobs, technician-specific availability, skill-based assignment, and two-way customer SMS that doesn't require the owner to be on the phone. Jobber users consistently say "Jobber does too much and the scheduling piece is still confusing." That's the gap.
Q5: Ecosystem trends?
Home services is a $600B+ market in the US that is digitizing slowly but steadily. The labor shortage has forced trade business owners to be more efficient with the technicians they have -- which means scheduling optimization is a genuine revenue lever, not just a convenience. Every job slot wasted to a no-show or a travel inefficiency is real money.
Q6: Most resonant approach?
Translating an existing idea into a new niche is the right approach here because the product model is proven (Calendly exists, it works, people love the simplicity) but the audience is completely different. The translation requires understanding the trades deeply -- you can't just add a "travel time" field to Calendly and ship it. The moat is the depth of vertical knowledge baked into the scheduling logic.
10. 9. EU HR Compliance Platform for Startups
Approach: Enter a large space with a hated incumbent
Rippling, Gusto, and Deel are the US-dominant HR platforms. They all have "EU support" as a feature
but they treat Europe as an afterthought -- GDPR compliance is surface-level, local labor law variations
are poorly handled, payroll integrations differ by country, and the EU's employee rights framework is
fundamentally different from the US model. European startups hiring across France, Germany, Spain,
and the Netherlands face a compliance nightmare that US-built tools paper over. This is an HR
compliance platform built for European labor law from the ground up.
Problem and people affected
European startups between 10-200 employees, typically headquartered in France, Germany, or the UK,
that are expanding to additional EU countries and need to comply with local labor laws,
works councils, mandatory notice periods, and data residency requirements.
Checklist
Problem identified: EU HR compliance is complex, country-specific, and poorly served by US-built HR tools.
Hated incumbent: Rippling and Deel are the dominant tools. Both have real complaints about EU coverage quality from European startups.
Translate to niche: Horizontal HR platform narrowed to EU-specific compliance requirements.
Fast-growing ecosystem: EU regulatory complexity is increasing (AI Act, DSA, DMA, GDPR enforcement). HR compliance needs are growing accordingly.
Differentiation: EU-native means: French CDI/CDD contract generation, German Betriebsrat integration, GDPR-compliant data residency in EU, EU works council compliance. Rippling can't match this without a rebuild.
Reflection Questions
Q1: Problem from experience?
Any European startup founder who has tried to hire an employee in Germany using an American HR tool has hit the wall. German labor law requires specific contract terms, specific notice periods, and specific protections that a template from Gusto simply does not cover. A compliance mistake costs tens of thousands of euros and significant legal exposure. The pain is acute and the stakes are high.
Q2: Network in European startup ecosystem?
French, German, and UK startup founders are concentrated on LinkedIn and at events like VivaTech, Slush, and Web Summit. The French tech ecosystem specifically (Station F, French Tech network) is tight and well-connected. Being embedded in this ecosystem as a founder gives immediate access to the exact customer profile: funded European startup, 20-100 employees, expanding internationally.
Q3: Software European startups pay for?
Deel ($49-99/employee/month for international contractors), Rippling ($8-35/employee/month), Personio (German HR tool, $4-8/employee/month), local payroll providers in each country. European startups are paying $500-3000/month for fragmented HR tools that don't talk to each other and none of which fully covers EU compliance. A consolidated, EU-native platform at competitive pricing wins on both dimensions.
Q4: Differentiation from Rippling/Deel?
Data residency in the EU (legal requirement for some industries, strong preference for most). Country-specific contract generation that is actually legally reviewed, not templated. Works council tools for German companies. French collective agreement support. The pitch to a European founder: "Built by Europeans, for European labor law, data stays in Europe." That sentence eliminates Rippling from the consideration set immediately for many EU buyers.
Q5: Ecosystem trends?
EU regulatory expansion is a durable trend. Every year brings new compliance requirements for employers. The AI Act alone has HR implications (algorithmic management rules). A tool that positions itself as "the compliance platform that keeps up with EU regulation" has a built-in reason to stay subscribed and expand.
Q6: Most resonant approach?
Hated incumbent, but the hatred is structural rather than UX-based. Rippling and Deel are not bad products -- they are simply US products trying to serve a non-US market. That structural gap is harder for them to close than a UX problem would be. Building EU-native from the start means the moat compounds with every regulatory change, because you respond faster and more completely than a US company can.
11. 10. AI Agent Observability for Product Teams
Approach: Explore fast-growing ecosystems
Companies are deploying AI agents in production -- customer support bots, code review agents,
data analysis pipelines -- and they have no visibility into what these agents are doing,
why they are making specific decisions, where they are failing, and what they are costing.
LLM observability tools (LangSmith, Helicone, Langfuse) exist for developers.
This is the same capability, but designed for the product manager or VP of Product who
shipped the agent and now needs to understand it, improve it, and justify its costs to the board.
Problem and people affected
Product managers and AI product leads at companies that have deployed at least one AI agent in production.
They know the agent exists, they can see the aggregate output, but they cannot diagnose failures,
understand edge cases, or build a business case for further AI investment without real observability data.
Checklist
Problem identified: AI agents are black boxes for the product people who own them.
Fast-growing ecosystem: AI agent deployment is growing exponentially. Every company with a product team is shipping or planning AI features.
Translate to niche: Developer-focused LLM observability (LangSmith) translated to the product manager audience.
Hated incumbent: LangSmith and Helicone are loved by developers but completely inaccessible to non-technical product owners. The gap is the interface, not the data.
Day job spending: Companies pay for LangSmith, Datadog, and Amplitude separately. None of them serve the product-layer AI observability need.
Differentiation: Business-metric-first view: not token counts and latency, but task success rate, customer satisfaction impact, cost per resolved case, agent vs. human escalation rate.
Reflection Questions
Q1: Problem from experience?
A product manager who ships an AI customer support agent knows immediately that they can see ticket volume and CSAT scores in Zendesk, but they cannot see why the agent refused to answer a specific type of question, what percentage of conversations the agent handled confidently vs. hedged, or which topics consistently escalate to humans. That gap between "the agent exists" and "I understand what the agent is doing" is real and growing as more agents ship.
Q2: Network in this space?
AI product managers are an emerging professional identity with their own communities: Lenny's Newsletter, Reforge, LinkedIn "Head of AI" searches. The early adopter here is the person who just shipped their first AI agent and is now asked to report on it to leadership. That person exists at thousands of companies right now and they are actively looking for tools to help them.
Q3: Software companies pay for?
Companies already pay for LangSmith ($39-99/month for developers), Amplitude ($500-2000/month for product analytics), and Datadog ($500-5000/month for infrastructure). An AI agent observability tool for PMs at $200-500/month slots between product analytics and infrastructure monitoring -- a budget category that clearly exists.
Q4: Unique position?
The differentiation is the audience, not the technology. LangSmith shows traces and token counts. This shows: task success rate by category, agent confidence distribution, top reasons for escalation, ROI calculation (cost per resolved case vs. human cost), and trend views by week. The same data, presented for the person who owns the business outcome rather than the developer who owns the infrastructure.
Q5: Ecosystem trend?
AI agent deployment is the dominant trend in SaaS right now. Every product team is shipping agents. The tooling for managing these agents is 18 months behind the deployment curve -- exactly the timing for infrastructure tooling to emerge. Datadog didn't exist until AWS made infrastructure complex enough to need it. This is that moment for AI agents.
Q6: Most resonant approach?
Fast-growing ecosystem, but with a translation component: taking developer-facing observability and making it product-manager-facing. The risk is that this is a features-on-top-of-LangSmith play that a developer can replicate with a dashboard. The defense: the product manager doesn't want a dashboard on top of LangSmith -- they want something that works without knowing what a trace is. That simplicity is hard to build and easy to appreciate.
12. 11. Developer Environment Manager for Remote Engineering Teams
Approach: Analyze what you spend money on at your day job
Remote engineering teams at companies between 20-200 developers pay for a sprawling mix of
cloud development environments (GitHub Codespaces, Gitpod), secrets managers (HashiCorp Vault),
infrastructure-as-code tools (Pulumi, Terraform), and internal tooling for setting up new developer
environments. Onboarding a new engineer still takes 2-3 days of environment setup.
This is a tool that manages the full developer environment lifecycle: provision, configure, share,
and tear down -- with secrets, dependencies, and IDE configs included. One day-one experience
for every new engineer, regardless of their machine or location.
Problem and people affected
Engineering managers and platform/DevOps engineers at remote-first companies.
The pain is felt on day one of every new hire and every time a developer switches projects.
Checklist
Problem identified: Developer environment setup is slow, inconsistent, and expensive to maintain across distributed teams.
Day job spending origin: Companies pay for Codespaces, Gitpod, Vault, and internal tooling that still doesn't solve the full problem. The spend is real and the gap is visible.
Translate to niche: Cloud development environments (Gitpod model) combined with secrets and dependency management for remote teams specifically.
Hated incumbent: GitHub Codespaces is the giant. Platform engineers consistently find it inflexible for complex multi-service environments.
Differentiation: Cross-project environment switching, secrets injection without Vault overhead, team-wide environment standards enforcement, one-command onboarding that actually works.
Reflection Questions
Q1: Personal problem?
Any developer who joined a company and spent two days setting up their laptop knows this pain. The "getting started" doc that was last updated 14 months ago. The dependency version conflict that takes half a day to debug. The environment variable that everyone passes around in Slack DMs. The cost is not just the engineer's time -- it is the delayed productivity of every new hire and the context-switching cost of every project change.
Q2: Network to leverage?
Platform engineers and DevOps leads are the buyers. They are on Twitter, in CNCF Slack communities, and at DevOpsDays events. The demo sells itself: "Here is your entire engineering environment, including secrets, in 5 minutes on any machine." That is a sentence every platform engineer wants to say to their CTO.
Q3: Software companies pay for?
GitHub Codespaces ($0.18/hour per active user -- adds up fast), Gitpod ($9-35/user/month), HashiCorp Vault ($0.03/active client hour on HCP), Doppler (secrets management, $7-35/user/month), internal tooling built and maintained by platform engineers at $150+/hour. The fragmented spend on this problem is substantial. A consolidated tool at $15-25/developer/month replaces multiple line items.
Q4: Differentiation?
Codespaces and Gitpod solve the "cloud IDE" part. Vault and Doppler solve the secrets part. Nothing connects them in a team-managed, onboarding-optimized workflow. The differentiation: a single command that gives any new engineer their full, correctly-configured, secrets-injected environment on their first day -- tied to their GitHub identity, their team's standards, and the specific project they're joining. Platform engineers currently build this themselves with shell scripts and 200 lines of documentation.
Q5: Ecosystem trends?
Remote-first engineering is durable, not a pandemic artifact. The tooling for remote developer productivity is still maturing. AI-assisted coding (Cursor, Copilot) has raised developer expectations for environment quality -- a developer who expects AI-assisted completion also expects their environment to be right on day one. The bar is rising.
Q6: Most resonant approach?
Following the money at the day job. The advantage: every potential customer already pays for a fragmented version of this. The sales motion is not "here is a new problem" but "here is a better solution to the problem you already have a budget for." That makes the budget conversation much easier. The risk: this is a technically complex product with a long development timeline before it works reliably across diverse tech stacks.
13. 12. Notion-Native Operations Hub for Small Teams
Approach: Build on an existing product
Notion has 30+ million users. Small operations teams (5-20 people) at startups and agencies
have moved their entire workflow into Notion but hit a ceiling: Notion doesn't do forms that
route to the right person, doesn't do approval workflows, doesn't have a real inbox,
and doesn't integrate with the rest of the stack without Zapier in between.
This is an operations layer that lives inside Notion -- Notion templates, automation blocks,
and integration connectors that turn a Notion workspace into a real operations platform,
without forcing the team to leave Notion for another tool.
Problem and people affected
Operations managers and COOs at startups and agencies between 10-100 people
who have gone all-in on Notion and now need more power without the complexity of
switching to a dedicated ops platform.
Checklist
Problem identified: Notion-first teams hit workflow limitations that Notion can't solve natively.
Build on existing product: Yes -- entirely parasitic on Notion's growth and user base.
Unique focus: Operations workflows specifically -- approvals, routing, intake forms, status tracking -- not generic Notion templates.
Hated incumbent: The Notion template marketplace has 10,000 templates, most of which are glorified pages. Real workflow tooling for ops teams doesn't exist in the ecosystem.
Fast-growing ecosystem: Notion's enterprise push is bringing it into ops workflows at more companies. The platform is growing into use cases it was never designed for.
Traffic source: Notion template SEO is incredibly underexplored. "Notion template for operations" has real search volume and almost no quality results.
Reflection Questions
Q1: Problem from experience?
Any ops manager at a Notion-first startup has hit the wall: you can build a beautiful process page in Notion, but you cannot make it send an email when someone submits a form, you cannot create an approval workflow that routes to the right manager, and you cannot build a real inbox where requests land and get triaged. Every time you need those things, you end up in Zapier, which breaks every quarter and nobody understands.
Q2: Network to leverage?
The Notion community is enormous and self-organized. Notion ambassadors, the Notion subreddit (500k members), and the "Notion for business" Twitter community are all reachable. Getting one Notion influencer to demo your ops workflow template generates thousands of trial signups. The community is hungry for tools that push Notion's capabilities forward.
Q3: Software teams pay for currently?
Notion ($8-15/user/month, already paid), Zapier ($20-400/month for automations), Typeform ($25-83/month for forms), DocuSign ($25-40/user/month for approvals). An ops team at a 20-person startup is paying $400-800/month for tools that connect Notion to the world. A native layer that handles 80% of those connections inside Notion at $50-100/month is an obvious consolidation win.
Q4: Differentiation and unique position?
Positioning as a Notion-first product means Notion's user base is your distribution channel. The SEO strategy: "Notion template for [ops workflow]" for every common operations process -- vendor onboarding, employee offboarding, budget approval, IT requests. Each template is a lead magnet that converts to a paid subscription when the team wants the automation layer. No other competitor is executing this combination of content + product.
Q5: Ecosystem growth?
Notion just launched its enterprise tier and is actively pushing into larger company workflows. As Notion moves upmarket, the operations use case grows with it. Every new enterprise customer Notion acquires is a potential customer for the operations layer built on top. The platform bet is on Notion's continued growth, which is one of the safer platform bets in B2B SaaS right now.
Q6: Most resonant approach?
Building on an existing product is powerful because the distribution is built in -- you ride the existing user base. The risk: Notion can build this natively and eliminate the need. The mitigation: focus on complexity and depth that Notion's team won't prioritize for years, use Notion's growth as tailwind, and build enough switching cost (custom templates, automations, integrations) that customers stay even if Notion improves natively. This is the classic platform ecosystem bet.
The most reliable approach for a solo founder or small team is the day job problem or scratch-your-own-itch pair.
They give you the deepest founder-market fit and the fastest customer discovery.
The riskiest, but potentially most rewarding, is the fast-growing ecosystem play -- timing is everything,
and you either catch the wave or you don't.
Building on an existing product (Notion, Stripe, Shopify) works when the platform is large enough
and the niche is specific enough that the platform won't bother building it themselves.
The one thing all 12 ideas share: they start with a real problem and real people who have it.
Not a technology looking for a use case. That's the whole worksheet in one sentence.