Skip to content

Latest commit

 

History

History
882 lines (552 loc) · 39.3 KB

File metadata and controls

882 lines (552 loc) · 39.3 KB

be interactive to me and ask those questions one by one and base questions based on my answer and validate if my startup idea is a convertible money making business that can be funded

Let’s do this like a YC partner would in office hours: a structured, interactive deep-dive to see if this can become a real, fundable, money-making company.

First, a crucial note: this only works if you answer honestly and concretely, not aspirationally.


1. What is your idea?

First question:

Q1: In 2–3 sentences, describe your startup idea:

  • Who is it for (specific type of user or business)?
  • What problem are you solving for them?
  • What is the main way you imagine making money (e.g., subscription, % of transactions, one-time fee)?

Please answer Q1, then the next question will adapt based on your response.


for large enterprises or even small companies that are planning to use servicenow type tools , they are super expensive, I want to build a SaaS or self hostable ITSM that mimics most used features of servicenow like incidents, requests, change management, on-call rotation schedules and application inventory/groups for support to tie to any of the above and sell it as one time product for each company and any upgrades or releases will cost money but not subscription or annual user based fee like servicenow or others do , if saas , then I host it and just cost them a nominal annual fee and hosting cost

This can be a real, money-making business, but it will be very hard and only fundable under specific conditions (strong wedge, narrow ICP, and real differentiation). Let’s walk through this interactively and stress-test it like an investor would.

I’ll ask one question at a time and adapt based on what you say. Answer briefly but concretely.


1. Target customer focus

Right now your target ranges from “large enterprises” to “even small companies,” which is too broad for a first product. Enterprises buying ITSM (ServiceNow, BMC, etc.) are slow, political, and require deep features and integrations to switch, while SMBs care a lot more about price and simplicity. Venture investors usually want a sharply defined initial customer where you can win consistently before expanding outward.

Q1: For the first 12–18 months, who are you designing this for, as specifically as possible?

Pick one:

  • A) Large enterprises (10k+ employees) already on ServiceNow or similar
  • B) Mid-market (200–5,000 employees) that feel ServiceNow is too expensive/complex
  • C) Small IT teams (10–200 employees) that are currently using email/Sheets/Slack and maybe Jira/Helpdesk tools
  • D) A specific vertical (e.g., hospitals, SaaS companies, call centers, MSPs, etc. — describe which)

Reply with one choice (A/B/C/D) and 1–2 sentences describing the typical company (industry + team size + where they are today). Then the next question will dig into whether these buyers are desperate enough to switch and pay you.


I couldn't come to a decision on customer focus yet, you help me

Given your idea and pricing model, the best starting focus is B: mid‑market companies (200–5,000 employees) that feel ServiceNow is too expensive/complex. These are the most likely to switch, pay, and move fast enough to make this a real business.

Let’s lock that in and then go step by step.


1. Why mid‑market is your best wedge

  • Large enterprises expect deep features, compliance, integration, and vendor stability; competing with ServiceNow there as a new vendor is extremely slow and sales-heavy.
  • Very small companies often don’t need full ITSM; they get by with simpler tools (Jira, Zendesk, Freshservice, email) and are very price sensitive.

Mid‑market companies, especially in fast-growing tech or services, often:

  • Feel ServiceNow/BMC are overkill and overpriced.
  • Have real ITSM pain (incidents, changes, on‑call, asset/app inventory).
  • Are frustrated with per‑user pricing and want predictable costs.

2. Sharpening your initial ICP

To make this fundable, the initial customer profile needs to be narrow and repeatable, not “any company 200–5,000 employees.”

Here’s a concrete proposal for your first ICP:

  • Company size: 200–2,000 employees.
  • Type: SaaS or tech-enabled services companies with in-house IT + SRE/DevOps.
  • Current state:
    • Using email/Slack/Sheets + maybe Jira for tickets, and
    • Complaining that “ServiceNow is too expensive / heavy,” and
    • Need better incident/change/on-call coordination but don’t want big‑vendor lock‑in.
  • Buyer: Head of IT / IT Director or Head of SRE.

Q1 (decision point): Are you comfortable making this your starting ICP:

“Tech/SaaS or tech-enabled companies with 200–2,000 employees, with in‑house IT + SRE/DevOps, who think ServiceNow is too expensive/complex and currently patch together Jira + email/Slack/Sheets for ITSM”?

Reply YES if this sounds reasonable, or EDIT: and rewrite it in your own words if you want to tweak industry/size.

Once you confirm, the next question will be about what painful problem this ICP has that your product will solve 10x better than their current setup.


I was wondering if medium scale business of less than 2k employees can afford my product if they don't already have an ISTM process, replacing is easier since they know how much they are spending ?

Medium-scale businesses under 2k employees can afford ITSM, but whether they’ll buy yours depends more on pain and priority than raw budget.


Can they afford it?

  • A 200–2,000-employee company typically spends significant money on IT tools (SaaS, devices, security), so a reasonably priced ITSM (especially one-time or low annual fee) is usually within reach if the pain is clear enough.
  • The real issue is not “can they pay?” but “do they feel enough pain today to justify time, migration, and process change?” A company with no ITSM process often underestimates this pain because it is “normal chaos” for them.

Who is easier to sell to: greenfield vs replacement?

  • Greenfield (no existing ITSM):
    • Pros: No entrenched tool to rip out; less political resistance.
    • Cons: You must sell both the need for ITSM and your product; they may see this as “nice to have” rather than urgent.
  • Replacement (already paying):
    • Pros: They already believe in ITSM, have budget, and know the process value. If they complain about price/complexity, you have a strong wedge.
    • Cons: Migration, data, workflows, integrations, and change management become real objections.

For a fundable, scalable business, replacement buyers are often more attractive because you are tapping into existing budget and a problem they already acknowledge.


How this affects your idea

Your value proposition so far sounds like:

  • “ServiceNow-like ITSM with core features (incidents, requests, change management, on-call, app inventory) at a simpler, more predictable price (one-time or low annual fee, not per-seat).”

This resonates most with:

  • Companies that already feel current ITSM is too expensive/complex and are trying to reduce cost or simplify.
  • Or companies that have grown into needing ITSM and are balking at ServiceNow/Tier-1 quotes.

Next interactive step

To move forward with validation, the key question now is:

Q1: Which of these feels closer to your real target, given your vision?

  • A) Companies that already pay for ITSM (ServiceNow, BMC, etc.) and want something cheaper/simpler.
  • B) Companies that do not have ITSM yet and are outgrowing ad-hoc tools (email/Slack/Sheets/Jira).

Pick A or B, and then 1–2 sentences on why you chose it. The next step will be to test if that segment has enough pain and budget to make this a real, potentially fundable business.


A , because the existing tools are super expensive and comapnies are trying to cut budgets and allocate for AI or something else (my assumption, correct me)

Choosing A (replacing existing ITSM) is a good instinct, and your assumption is partly right: many companies are under pressure to cut costs and reallocate budget (including toward AI), and expensive ITSM tools are a visible target in some organizations.

However, “cost cutting for AI” is not a reliable, primary driver on its own. What reliably drives a switch from ServiceNow/BMC/etc. is usually a mix of:

  • High license + implementation + maintenance costs.
  • Complexity and slow iteration (needing consultants for changes).
  • Poor internal adoption (“everyone hates using it”).

Let’s keep this interactive and move toward “Is this fundable?” by stress-testing the business.


1. Validate your core bet about the buyer

For A (replacement), your core bet is:

“There is a large number of mid-sized companies already on expensive ITSM tools who are actively looking to switch to something simpler and cheaper, and are willing to migrate.”

To see if this holds, you will need to talk to real prospects and ask questions like:

  • “What do you use today for ITSM?”
  • “What frustrates you most about it?”
  • “Have you seriously considered switching in the last 12 months? Why or why not?”
  • “What would make you actually switch in the next 6–12 months?”

If they keep emphasizing cost + complexity + slow changes, your thesis is directionally right.


2. Key risk areas investors will push on

For this to be a fundable, money-making business, you must address these:

  1. Switching cost and migration
    • Even unhappy ServiceNow customers fear migration risk (data, workflows, integrations, training).
    • You need a story like: “We can get you migrated in X weeks with minimal disruption,” possibly with tools or services.
  2. Differentiation beyond ‘cheaper ServiceNow’ “Cheaper version of X” is usually weak for venture funding unless the market is huge and the wedge is strong. You likely need a clear angle, such as:
    • Opinionated, modern, “SaaS-native” ITSM tailored for tech companies.
    • Deep integration with modern tools (Slack, Teams, PagerDuty, cloud providers).
    • Radically simpler setup and workflow customization.
  3. Pricing model viability
    • One-time license + paid upgrades can be harder to build into a large, recurring-revenue business, which is what most investors want.
    • A more attractive model for funding is usually:
      • Predictable, not per-seat-gouging pricing (e.g., tiered by company size or # of assets/incidents)
      • Recurring revenue (annual subscription), maybe with optional self-hosted tier.

3. Next interactive question: strength of pain

To judge whether this can realistically be a money-making and fundable business, the most important thing now is: How intense is the pain for your chosen segment?

Q1: Think of 3–5 real companies you know (from your network, LinkedIn, or prior work) that are on ServiceNow/BMC or similar. For each one, can you honestly say at least two of the following are true?

  • They regularly complain about ITSM cost.
  • They complain it’s too complex and slow to change.
  • Adoption is poor (people bypass the tool).
  • They’ve discussed switching or evaluating alternatives in the last 1–2 years.

Answer with:

  • “YES, I can name 3–5 where at least two of those are true,” or
  • “NO, I don’t know enough real examples yet.”

Based on your answer, the next step will either be:

  • Designing your first 5–10 validation conversations, or
  • Narrowing your segment further to where you have real access and insight.

I will go with

Predictable, not per-seat-gouging pricing (e.g., tiered by company size or # of assets/incidents) Recurring revenue (annual subscription), maybe with optional self-hosted tier.I don't know enough real examples yet

and about q1 about real companies i know

Your instincts on pricing and model are pointed in a fundable direction; the main missing piece is real customer signal. Because you don’t yet know enough real companies, the next step is to design concrete validation conversations to find out if this can become a strong, money-making, and fundable business.


1. Your clarified idea (so far)

You now have a sharper version of the idea:

  • ITSM product with core ServiceNow-like features: incidents, requests, change management, on-call schedules, and application inventory/groups.
  • Selling primarily to companies already on expensive ITSM tools who want something simpler and cheaper.
  • Pricing:
    • Predictable, non–per-seat model, likely tiered by company size or usage (# of assets/incidents).
    • Recurring annual subscription, with optional self-hosted tier.

This is structurally attractive for revenue and more aligned with what investors like (recurring, predictable, non-punitive pricing).


2. What you must validate next

Since you don’t yet know enough real examples, you need to validate three core questions:

  1. Is the pain intense enough to switch?
    • Are there enough companies that hate the cost/complexity of existing ITSM and have actually thought about switching?
  2. Is your wedge compelling?
    • “Modern, simpler ITSM with predictable pricing” must be strong enough to overcome migration fear.
  3. Can you reach and close these customers?
    • Do you have or can you build access to IT/DevOps leaders at mid-sized companies?

3. Actionable next steps (talk to real people)

Because you can’t name 3–5 real companies yet, your job now is to get to at least 10–15 conversations with people who fit your rough ICP.

Step 1: Define a scrappy ICP you can actually reach

Use something like:

  • 200–2,000-employee tech/SaaS/IT-heavy companies.
  • In-house IT + SRE/DevOps.
  • Using ServiceNow, BMC, Cherwell, or similar; or recently evaluated them.

Step 2: Outreach channels you can use

  • Past colleagues / ex-managers in IT or DevOps.
  • LinkedIn search: “IT Manager”, “Head of IT”, “Service Desk Manager”, “SRE Manager” at 200–2,000-employee companies.
  • Communities: Slack/Discord groups for DevOps/SRE/IT, Reddit, etc.

Message template idea (adapt in your own style):

“Hey, I’m exploring building a simpler, more predictable alternative to tools like ServiceNow for IT teams at mid-sized companies. I’m not selling anything yet; just trying to learn. Could you spare 20 minutes to talk about what you use today for incidents/requests/changes and what’s painful about it?”


4. What to ask in those conversations

Your goal is not to pitch; it’s to learn if this is a money-making, fundable opportunity.

Ask questions like:

  • “What do you currently use for ITSM (incidents/requests/changes)?”
  • “What do you like and dislike about it?”
  • “Have you ever seriously considered switching? Why or why not?”
  • “How do you feel about your current pricing model?”
  • “What would an ideal tool look like for you in terms of features and pricing?”
  • “If a tool existed that did X/Y/Z and cost a predictable annual fee without per-seat pricing, would that be interesting enough to evaluate?”

You are looking for people who:

  • Explicitly say cost/complexity are painful.
  • Have thought about switching or are open to evaluating alternatives.
  • Show real curiosity or urgency (“I’d love to try something like that.”).

5. Direct answer to “Is this fundable?”

Right now, given your vision and chosen model:

  • Yes, it’s potentially a money-making business:
    • ITSM is a large, real market; ServiceNow’s size alone proves this.
    • A modern, simpler, predictable-pricing alternative aimed at mid-market users is a rational wedge.
  • Fundability depends on what you learn next: Investors will care about:
    • Evidence that multiple customers are eager to switch (strong pain).
    • A believable go-to-market path (how you’ll reach 10, then 100, then 1,000 customers).
    • A product story that is more than “cheaper ServiceNow” (easier, faster, better integrated, modern workflows).

Next interactive question

To make this concrete for you:

Q: In the next 2 weeks, how many real IT/DevOps leaders do you think you can talk to (from your network, LinkedIn, or communities)?

  • A) 0–3
  • B) 4–7
  • C) 8–15

Reply with A/B/C, and then a sentence on where you’d find them (e.g., “ex-colleagues and LinkedIn search”). The next step will be to design a very small, realistic plan for those conversations so you move from “idea in head” to “real signals from the market.”


from my network, I think 4-7 people in 2weeks i GUESS

Talking to 4–7 people in 2 weeks is a solid, realistic start, and enough to get early signal on whether this can become a money-making, fundable business.

Below is a simple, concrete plan plus how to interpret what you learn.


1. Your 2-week validation goal

Goal: Have 4–7 conversations with IT/Service Desk/DevOps/SRE leaders at 200–2,000-employee companies who use (or seriously evaluated) ServiceNow/BMC/Cherwell/etc.

Success criteria for this phase:

  • At least 2–3 people clearly express strong pain with current ITSM (cost/complexity/adoption).
  • At least 1–2 explicitly say they would seriously evaluate a simpler, predictable-pricing alternative in the next 6–12 months.

If you don’t hear that, you either have the wrong segment or the pain is not strong enough.


2. Who exactly to contact

From your network, prioritize:

  • Anyone with titles like:
    • IT Manager / IT Director / Head of IT
    • Service Desk Manager
    • SRE / DevOps Manager
  • People at:
    • Tech/SaaS or IT-heavy companies with 200–2,000 employees.

If you run out of network contacts, extend to:

  • Ex-colleagues now at other companies.
  • LinkedIn 2nd-degree connections you can get intro to.

3. Script for outreach

Keep it casual and honest; you’re not selling yet.

Example message:

“Hey [Name], I’m exploring a product idea in the ITSM space and would really value your experience. I’m looking to understand what’s painful about current tools like ServiceNow/BMC/etc. and how teams think about cost and complexity. I’m not selling anything right now—just trying to learn. Would you be open to a 20-minute chat in the next week or two?”

If they say yes, schedule a short call.


4. What to ask in each conversation

Use this structure (don’t pitch until the end, if at all):

  1. Current setup and context
    • “What do you use today for incidents/requests/changes?”
    • “Roughly how many people interact with the tool?”
  2. Pain and satisfaction
    • “What’s the most frustrating thing about your current tool or process?”
    • “If you could snap your fingers and change 1–2 things, what would you change?”
  3. Switching behavior and budget
    • “Have you considered switching tools in the last 1–2 years? Why or why not?”
    • “How do you feel about the current pricing model (per-seat/tiers/etc.)?”
  4. Your wedge (at the very end)
    • “I’m exploring something like a simpler ITSM focused on incidents/requests/changes/on-call, with predictable pricing by company size or usage instead of per-seat. At a high level, would that be interesting enough to evaluate if it worked well?”

Take notes after each call.


5. How to interpret the results (money-making + fundable?)

After 4–7 conversations, ask:

  • Do at least 2–3 people say things like:
    • “It’s way too expensive.”
    • “It’s too complex; we need consultants to change anything.”
    • “Adoption is a constant struggle.”
    • “Yes, we’ve discussed switching or are open to it.”

If yes, then:

  • You have early signal there is real pain; this can be a money-making product if you build something focused and opinionated.
  • For fundability, investors will later want to see:
    • First paying customers.
    • Clear ICP and repeatable sales motion.
    • Rationale for why this can become a large company (not just a niche tool).

If no, and most people are “meh” or resistant to switching:

  • The idea in its current form is probably not yet a strong, fundable opportunity.
  • You might need to:
    • Narrow further (e.g., “ITSM tailored for X vertical”), or
    • Shift from “cheaper ServiceNow” to a novel angle (e.g., on-call + incident + Slack-native ITSM).

6. Next interactive step

To make this real and not theoretical:

Q: In the next 48 hours, who are the first two people you will contact for these conversations (first name + how you know them, no private details)?

Example:

  • “Alice – ex-colleague, now IT Manager at a SaaS company.”
  • “Bob – DevOps lead at my current company.”

Share 1–2 like that, and the next step will be to refine the exact 3–4 questions you’ll ask those specific people based on their role.


let's assume this is interested for atleast 5 IT heads in 5 medium scale companies, go ahead with next questions

Assuming 5 IT heads at mid-sized companies are clearly interested, this is a strong early signal that your idea can be a real, revenue-generating product and a plausible candidate for funding, if you execute well on focus, wedge, and GTM.

Let’s now move from “interest” → “validated, money-making, fundable.” Next questions will pressure-test that.


Product focus and differentiation

Interest is not enough; you need a tight, opinionated v1 that those 5 would actually buy and deploy.

Q1: For version 1, what exactly do you ship if you must limit yourself to 2–3 major modules?

Pick one set:

  • A) Incidents + Requests + On-call
  • B) Incidents + Change management + On-call
  • C) Incidents + Requests + Application inventory
  • D) Your own combo (max 3 modules)

Reply with A/B/C/D and, if D, list the 2–3 modules. The next question will be about how those 5 IT heads would run their team differently with that v1.


Will they actually change behavior?

To be money-making and fundable, the product must make IT leaders say, “This will materially improve how my team works.”

Q2 (answer after Q1): For the 5 IT heads you’re imagining, what is the single most important improvement they care about?

Choose the closest:

    1. Lower total cost vs current ITSM
    1. Much simpler configuration and change (no consultants)
    1. Better adoption by engineers / staff (people actually use it)
    1. Faster incident/issue resolution and fewer dropped balls
    1. Something else (describe)

Reply with 1/2/3/4/5 and a short sentence (e.g., “Mostly 2; they hate needing consultants to change workflows”). Next, the questions will focus on pricing and concrete commitment.


Pricing and commitment

Assuming they are interested is helpful, but fundability depends on whether this can be a scalable, high-margin business.

Q3: For a typical 500–1,000-employee company using your v1:

  • What annual price feels both attractive to them and meaningful to you as a business?
    • Example bands:
      • a) 5–10k/year
      • b) 10–25k/year
      • c) 25–50k/year
      • d) >50k/year

Pick a–d and add 1 sentence of justification (e.g., “a) because I want to undercut ServiceNow heavily for mid-market”).

Next, we’ll turn these assumptions into a basic revenue model (e.g., “If you win N customers at $X/year, what does this look like?”) and then into what an investor would think.


Migration and switching risk

One of the biggest reasons IT leaders don’t switch is migration pain.

Q4: How do you imagine making migration easy enough that these 5 IT heads are comfortable switching?

Pick the closest:

  • i) “We provide tools to import from ServiceNow/BMC/etc. and a guided setup wizard.”
  • ii) “We or partners offer a done-for-you migration service for a fee.”
  • iii) “We start with a narrow slice (e.g., only incidents) and let them run in parallel before fully switching.”
  • iv) Something else (describe briefly).

Reply with i/ii/iii/iv and a sentence. Next, we’ll test whether this is believable as a GTM story and scalable business.


Answer Q1–Q4 in order and as concretely as you can. Based on your choices, the next step will be:

  • Turn your assumptions into a simple revenue model (can this be a multi-million ARR business?).
  • Then, translate that into how a seed investor would view the opportunity: “backable now / backable after X traction / probably too weak as-is.”

I will deliver all of these

A) Incidents + Requests + On-call B) Incidents + Change management + On-call C) Incidents + Requests + Application inventory

all these Lower total cost vs current ITSM Much simpler configuration and change (no consultants)

25–50k/year since they are comfortable with it

We or partners offer a done-for-you migration service for a fee. Later I plan to build an import tool once we get funded

Given your answers, this can be a real, high-ARR business, but it is not yet fundable as described unless you tighten scope and story. Right now you are trying to do too much in v1 and leaning on “cheaper ServiceNow” instead of a sharp wedge, which most investors will see as risky and unfocused.

Below is the honest, YC-style reality check plus what to do next.


1. Scope: you’re trying to ship too much

You want to deliver A, B, and C (essentially full ITSM: incidents, requests, change, on-call, app inventory) in v1.

  • For a small team / early-stage startup, that’s a huge surface area:
    • Incidents
    • Requests (service catalog, workflows)
    • Change management
    • On-call rotations and schedules
    • Application inventory and relationships
  • YC-style advice: You should start much narrower. A smaller, well-done surface that delights customers beats a half-baked “mini-ServiceNow.”

Recommendation: Pick one of these as your wedge and make the others “coming later”:

  • Incidents + on-call (incident-centric, SRE/DevOps-first).
  • Requests + simple catalog (IT/helpdesk-first).

You can still position as “growing into full ITSM,” but you should build and sell a very focused use case first.


2. Value prop: where you’re strong vs weak

You’re focusing on:

  • Lower total cost vs current ITSM.
  • Much simpler configuration and change (no consultants).

These are good but on their own are not unique ideas; many ITSM challengers claim this. You need these to be:

  • Visibly true in the product (not just words).
  • Backed by stories: “We got X company live in 2 weeks without consultants.”

To make this a money-making business:

  • Lower cost + simpler config → easier to close deals and reduce churn.
  • For fundability, investors will want:
    • Proof that these advantages lead to fast sales cycles and strong word-of-mouth.

3. Pricing: 25–50k/year is plausible

You’re targeting 25–50k/year for a 500–1,000-employee company.

  • This is plausible if:
    • They’re replacing a much more expensive tool or an expensive combination of tools.
    • You can show strong value (reduced license/spend, less consultant cost, better productivity).
  • For a venture-scale story, examples like:
    • 100 customers at 30k/year → 3M ARR.
    • 300 customers at 30k/year → 9M ARR.

At this ACV, selling to mid-market is viable if you can build a repeatable sales motion (inbound + light-touch sales or efficient outbound).


4. Migration: your plan is reasonable but needs proof

You plan to:

  • Offer a done-for-you migration service (you/partners) for a fee.
  • Build import tools later once you get funded.

This is realistic in early stages:

  • Pros:
    • Reduces friction for early adopters.
    • Gives you deep understanding of real-world data and configurations.
  • Cons (from an investor’s POV):
    • Service-heavy early on; you must show this transitions to productized, scalable onboarding.

You’ll want 2–3 early customers where you can say:

  • “We migrated them in X weeks, replaced Y, and now they save Z per year.”

5. Is this a convertible, money-making, fundable idea?

Convertible, money-making:

  • Yes, this can be a real business if you:
    • Start focused (e.g., incident + on-call with simple change/requests).
    • Close a handful of mid-market customers at 20–50k/year.
    • Use services (migration, setup) to win initial deals and learn.

Fundable (seed/Series A): You are not fundable on vision alone with this story; you’ll almost certainly need traction:

  • A few paying customers (even 3–5 at meaningful ACV).
  • Evidence that they switched from ServiceNow/BMC/etc. or seriously avoided those tools because of you.
  • Clear ICP and repeatable way to reach similar customers.

Investors will ask:

  • “Why will you win where the other ITSM challengers haven’t?”
  • “What is your wedge? Incident+on-call? Slack/Teams-native? DevOps-first ITSM?”

Right now, your wedge is mostly pricing + simplicity, which is a good starting point but needs sharpening.


6. Next concrete step (decision point)

To turn this from “good idea with plausible numbers” into a validated, fundable startup, the next key decision:

Choose one wedge to start with:

  • A) Incident + on-call (SRE/DevOps-focused, uptime and reliability story).
  • B) Requests + simple catalog (IT/helpdesk-focused, internal “service portal” story).

Once you pick A or B, your next moves should be:

  • Design a tiny v1 around that wedge.
  • Go back to those 5 hypothetical IT heads and turn them into real conversations about that specific wedge, not the entire ITSM suite.

If you reply with A or B, a tight one-sentence description of your wedge will be the last piece needed to have a “pitchable” version of this idea (even if you don’t raise yet).


1. Scope: you’re trying to ship too much

I already built this as one person

  1. Value prop: where you’re strong vs weak I will try to get Proof that these advantages lead to fast sales cycles and strong word-of-mouth.

About Pricing, At this ACV, selling to mid-market is viable if you can build a repeatable sales motion (inbound + light-touch sales or efficient outbound). I will learn these

  1. Migration: your plan is reasonable but needs proof Sure I will atleast have this done in one company and show this transitions to productized onboarding
  2. Next concrete step (decision point) I will choose A) Incident + on-call (SRE/DevOps-focused, uptime and reliability story).

Given you’ve already built the full product solo and chosen Incident + on-call (SRE/DevOps-focused) as your wedge, you are past “idea validation” and into early GTM + funding readiness. The question now is: Does this look like a real, fundable, money-making business if you execute the next steps well? The answer is: yes, plausibly, if you now shift all energy into proof, not more building.

Below is how to proceed from here.


1. Sharpen your wedge story

You picked the right wedge: Incident + on-call for SRE/DevOps, with uptime and reliability as the hero outcome.

Turn that into a one-sentence pitch:

“A modern incident and on-call platform that replaces heavy ITSM tools for mid-sized companies, with predictable pricing and simple configuration that doesn’t require consultants.”

Your messaging to prospects should emphasize:

  • Faster incident response and fewer dropped balls.
  • On-call that’s simpler and less painful to set up and maintain.
  • No per-seat pricing; predictable yearly cost.
  • Much easier to change workflows and fields without a consultant.

Do not lead with “cheaper ServiceNow”; lead with “better incident + on-call experience” and then “at a fraction of the cost of big ITSM.”


2. Turn 1–2 customers into undeniable proof

Your next milestone is not more features; it is 1–2 real companies live and happy.

For each early customer, aim to show:

  • They were using X (ServiceNow, BMC, a mess of tools).
  • You replaced all or part of that for incidents/on-call.
  • Go-live time (e.g., “We set them up in 2–4 weeks.”).
  • Tangible improvements:
    • “We cut license/consultant cost by Y.”
    • “We reduced incident response time / confusion.”

You already plan:

  • Done-for-you migration for early adopters.
  • Later, productized import/onboarding.

Make sure you frame that to customers as a white-glove implementation (sounds premium), not “we’ll hack around manually.”


3. Simple early GTM plan (next 60–90 days)

Since you’re willing to learn sales, keep it simple and manual at first.

  1. Target profile:
    • 200–2,000-employee tech/SaaS/IT-heavy companies.
    • They currently use ServiceNow/BMC/other ITSM or a messy combo (Jira + Slack + Sheets).
    • Have SRE/DevOps + IT.
  2. Initial reach (founder-led sales):
    • Your network: ex-colleagues, managers, SRE/DevOps/IT people you’ve worked with.
    • LinkedIn outreach to “Head of SRE / DevOps / IT / Service Desk Manager.”
    • Communities (DevOps/SRE/IT Slack groups, Reddit, etc.).
  3. Call script structure:
    • Understand current incident + on-call setup.
    • Explore pains: complexity, context switching, slow changes, cost.
    • Then show a short demo of your incident + on-call flows.
    • Close for: pilot / paid pilot / small contract with migration included.

Your goal: 3–5 serious evaluations and 1–2 paying customers as soon as possible.


4. Positioning for funding (realistic path)

If you execute your plan (proof of value, some ARR), the story for a pre-seed/seed investor can be:

  • Solo founder who already built a working ITSM/incident product.
  • Clear wedge: incident + on-call for mid-market teams sick of heavyweight ITSM.
  • 1–2 customers migrated, paying 25–50k/year with done-for-you onboarding, plus a small pipeline.

Investors will want to see:

  • At least some revenue (even 50–100k ARR is meaningful at very early stage in this space).
  • Evidence of strong user love (“this is so much easier than X; we’d hate to go back”).
  • A believable path:
    • Expand from incident + on-call → change/requests for the same accounts.
    • Replicate this motion with similar mid-market companies.

If you have no customers yet, the bar for funding is much higher, and most will say “talk after a few paying customers.”


5. Concrete next step for you (this week)

Given everything you’ve said, the single highest-leverage thing you can do this week is:

  • Pick 3–5 real companies (from your network or 1-degree out) that fit your target.
  • Reach out for a 20–30 minute call to:
    • Show them your incident + on-call-focused product.
    • Ask if they would:
      • Run a pilot, or
      • Replace part of their existing setup, for a clear price (even discounted for early adopters).

You already built the product; now the only question that matters for “money-making and fundable” is: Can you convert real IT/SRE leaders into paying customers?

If you want, next step can be drafting:

  • A crisp 1-paragraph pitch email/DM tailored to SRE/DevOps vs IT leaders, or
  • A simple “early adopter” offer structure (pricing + migration + support) you can send to those first 3–5 companies.

do this please

A crisp 1-paragraph pitch email/DM tailored to SRE/DevOps vs IT leaders, or A simple “early adopter” offer structure (pricing + migration + support) you can send to those first 3–5 companies.

Here are plug-and-play drafts you can use today. Adjust names, numbers, and details to match your product and personality.


1. Pitch DM/email to SRE/DevOps leaders

Subject: Quick question about your incident + on-call setup

Hi [Name],

I’m building a lightweight alternative to heavy ITSM tools for mid-sized engineering teams, focused specifically on incidents and on-call. Right now, teams like yours are stitching together ServiceNow/Jira + Slack + spreadsheets, or paying a lot for tools that are slow to change and painful to maintain.

I’ve already built a working platform that handles incident tracking, on-call rotations/escalations, and post-incident context in one place, with predictable, non–per-seat pricing and configuration that doesn’t require consultants. I’m looking for 3–5 SRE/DevOps teams to try it as early adopters and help shape the roadmap.

Would you be open to a 20–30 minute chat so I can learn how you’re handling incidents/on-call today and see if what I’ve built is worth a trial at your team’s scale?

Best, [Your name]


2. Pitch DM/email to IT leaders (Head of IT / Service Desk / IT Director)

Subject: Exploring a simpler incident + on-call tool for mid-sized IT teams

Hi [Name],

I’m working on a simpler incident and on-call platform for mid-sized companies that feel tools like ServiceNow/BMC are too heavy and expensive for how they actually work. The focus is on giving IT and engineering a clean way to manage incidents, on-call schedules/rotations, and basic change/ownership context, without complex configuration or per-seat pricing.

I’ve already built the product and am looking for 3–5 IT teams to use it as early adopters: I’ll handle migration and setup for you, and you’ll get predictable annual pricing (no user-based licenses) and direct influence on the roadmap.

If you’re open to a 20–30 minute conversation, I’d love to learn how you’re currently handling incidents and on-call, and see whether this could replace part of your current ITSM stack or avoid an upgrade to heavier tools.

Best, [Your name]


3. Early adopter offer structure (what you actually propose)

You can paste this into a follow-up email or slide after a good first call.

Early Adopter Program (limited to 3–5 customers)

  • Scope (v1 focus):
    • Incident management (creation, triage, owner, status, timelines).
    • On-call schedules and escalation policies for your SRE/DevOps/IT teams.
    • Basic linkage to applications/services so incidents are tied to what’s actually affected.
  • Pricing (example for 200–1,000 employees):
    • Flat $20k/year (founding customer rate).
    • No per-seat licensing; covers your whole engineering + IT team.
    • Price locked for 2–3 years as long as you stay a customer.
  • Migration & setup (done-for-you):
    • We audit your current incident + on-call setup (ServiceNow/Jira/Sheets/etc.).
    • We configure your services, teams, and on-call schedules in the new platform.
    • We import recent incident history where feasible (manually at first, later via tools).
    • Training for your team: 1–2 live sessions + short documentation/videos.
  • Support & roadmap access:
    • Direct access to the founder via Slack/Teams/email for issues and feature requests.
    • Feature requests prioritized: early adopters strongly influence the roadmap.
    • SLA for support (e.g., response within X business hours).
  • Low-risk trial path:
    • 30–60 day pilot focusing on a subset (e.g., SRE team or one major service).
    • If you don’t see clear value by the end (better workflow, simpler on-call, etc.), you don’t continue.
    • If you do, the pilot rolls into the annual contract and we broaden usage.

You can tweak the numbers (e.g., 10–25k/year instead of 20k, or a shorter pilot), but keep the structure: focused scope, flat pricing, white-glove migration, direct support.


If you paste your own rough draft reply to a specific person (sanitized), the next step can be tightening it further to sound sharper and more credible for that exact target.