Sales

Pre-Seed stage founders (typically the CEO) own the sales function. With lean teams consisting of just founders and a few engineers, hiring a dedicated salesperson rarely makes economic sense. More importantly, founders need constant contact with users and customers to discover product-market fit. Your initial hypothesis and understanding of the problem, market, and product are essential in driving sales efforts.

Don’t worry about not knowing how to sell at this stage—focus on understanding your customer. Spending hours planning target markets, messaging frameworks, or elaborate sales processes is a distraction at this stage. Instead, keep it simple: talk to users and prospective customers relentlessly, rank your hypotheses, and prove them right or wrong quickly.

Talk to users and customers

Your primary job is to understand customer needs and steer the product toward maximum revenue potential. This requires continuous engagement with both users of your open source project and potential commercial customers.

Talk to customers and users constantly. They provide the insights that inform product development decisions. Building in isolation is one of the most dangerous mistakes pre-seed companies make. Potential customers don't buy features—they buy solutions to their most pressing problems. Focus on the heaviest users of your open source project, as their needs often represent the most valuable commercial opportunities.

Avoid the consultant trap. While industry experts can supplement user feedback, generalist consultants cannot replace direct customer conversations. Agencies typically follow rigid internal methodologies to produce generic deliverables that aren't useful for the highly iterative nature of early-stage product development. You need the real-time feedback loop that only comes from talking directly with prospective customers.

Engage in market conversations

Build brand awareness through active participation in relevant discussions on platforms like Hacker News, LinkedIn, Reddit, and industry-specific forums. This engagement serves two purposes: it identifies potential customers and heavy users, and it helps you understand the problems they're trying to solve.

Focus on engaging directly with individuals rather than broadcasting marketing messages. The goal is understanding their problems and how your solution might address them. When engaging potential customers, focus on understanding their current state and pain points:

• "Can you tell me how you're using [open source project/similar tools/current processes] today?"

• "What's the hardest thing about that? Why is that hard? How often does this problem occur?"

• "Why is it important to solve this problem? How do you solve it now?"

Follow up with clarifying questions: "Can you tell me more about that?" or "What do you mean by that?" These conversations should be about understanding problems, not showcasing solutions.

First Customers

Your first customer acquisition will look completely different from later customers. Most open core businesses eventually target large enterprises, but these can be difficult to land initially. Don't be afraid to start with smaller customers or broader use cases while building your enterprise pipeline.

Key principles for first customers:

1. Don't anchor too much on ideal customer profiles. Beggars can't be choosers—get your first customer by any means necessary.

2. Let customers force product requirements. Ask: "What problem do you have that you're dying to pay money to make go away?" Let their needs drive your development priorities.

3. Do things that don't scale. Once you land your first customer, provide exceptional, hands-on service that wouldn't be sustainable at scale but creates deep customer success and learning opportunities.

4. Don't focus heavily on contract value initially. Getting reference customers and learning from their implementations is more valuable than maximizing early revenue.

Working with Large Customers Early

While challenging to acquire, large customers often provide the best product insights. They have sophisticated needs, domain expertise, and request features that smaller customers also want but can't articulate. These relationships can be worth pursuing even at lower initial contract values because they drive valuable product development.

Leverage the open source community

The communities around your open source project are your best source for identifying potential commercial customers. Look for the heaviest users—companies that have implemented your software extensively, contribute back to the project, or ask sophisticated questions about enterprise features.

These communities reveal not just who might pay for a commercial solution, but also what problems are most acute for real users in production environments.

Ask for customer intros

Be aggressive about asking for introductions to interesting companies from everyone in your network. OCV will introduce founders to connections in our network. We recommend using Happenstance and filtering to first-degree connections. Experiment with a few different potential ICP profiles and find companies that match those profiles from your connected networks.

When requesting an introduction, first confirm that your connection is OK with making the intro. Then send a self-contained email that the recipient can forward directly. Send a separate email for each request. For example, if you ask for 5 introductions, send 5 draft messages.

The email should include:

1. Company description

2. How the recipient can use your technology

3. Your ask (Let’s schedule time, a demo, etc.)

Example email

Subject: Fortify Gobii’s API‐First Agents with Enterprise-Grade Security

Rich, thanks for offering to introduce me to Gobii, blurb below,

Garak is the commercial evolution of NVIDIA’s Garak—an industry-leading LLM red-teaming framework built by the former Google Safe Browsing lead (protecting over a billion users). We stop data leaks, prompt injections, tool misuse, and drifting behavior throughout agent deployment and production.

Gobii’s API-first architecture can plug directly into Garak’s SDK to automatically audit every incoming request and outgoing response—catching PII exposure and injection attempts at the API gateway. Our real-time guardrails ensure that any malicious or malformed prompts are sanitized before reaching your core agent logic.

Can we set up a quick call to discuss embedding Garak into Gobii’s API pipeline?

Best regards,

Divya

Directly engaging potential customers

Doing things that don’t scale in engaging users directly will help founders more deeply understand their customers’ motivations and get honest feedback. Advertising efforts alone will not directly provide the essential insights that come from proactive sales in informing strategy for early-stage companies.

Outreach to potential customers should be proactive and focused on understanding their problems, not showcasing ideas that are not direct solutions. Some of the questions founders should be asking customers:

• Can you tell me how you are doing/using [open source software project, substitute for product, similar processes] today?

• What is the hardest thing about that? Why is that hard? How often do you have to do this?

• Why is it important to solve this problem? How do you solve this problem now?

Handling inbounds when you don't have a product

When prospects reach out before your commercial product is ready, treat these as discovery opportunities, not traditional sales calls. Your approach should focus on understanding their needs while positioning yourself as a potential solution.

Lead with questions, not pitches

Focus on understanding customer needs during early discovery calls. What caused them to reach out? What have they tried internally? What other solutions are they evaluating? Are they facing current production problems or anticipating future issues?

Use a qualification framework like BANT to assess whether prospects have:

• Budget: Money to spend on solving this problem

• Authority: Decision-making power or influence over the solution choice

• Need: A genuine pain point your product could address

• Timeline: A window for making a decision

Handle pricing questions strategically

When pricing comes up, respond with: "Right now, I want to understand what your problems are and how we might be helpful. I have questions to get that context, then I'll come back with a proposal."

Don't hide that you're early-stage. Frame it positively: "We're working with select design partners to ensure we're building exactly what solves their specific needs, rather than trying to sell an off-the-shelf solution."

Always set the expectation that you'll charge them. This qualifies their seriousness—if they won't pay, the problem isn't significant enough to warrant their attention or yours.

Position as a consultant

Approach each conversation as an unpaid subject matter expert, helping them find the right solution, whether or not that's something you'll build. Be willing to help them identify if they don't need you—it's better to discover this early than waste time on unqualified prospects.

Don't trade on their ignorance; capitalize on their sophistication. If they could solve their problem with your open source project alone, help them understand why they're considering a commercial solution. Ask directly: "Since [open source project] is available, why not run a POC yourself? What value do you see in a hosted/managed solution?"

What you're selling at this stage is you—your expertise, background, and ability to solve their specific problem.

Trials, Proof of Concepts, and Pilots

Proof of Concept

A Proof of Concept (POC) is a short-term feasibility test. Customers will use a POC to test your product in their environment and assess if it's a good fit before implementing it on a large scale. They are limited in scope and have clearly defined success metrics. The goal is to move from proof of concept to paid customer as quickly as possible while gathering the product feedback necessary to serve future customers better.

1. Discovery and scorecard: Establish clear, quantifiable benchmarks for success. Use a shared scorecard to assess whether the product achieves the goals and requirements of the customer or not. A good scorecard is objective, binary, and measurable. If the success criteria are met, it should lead to a purchase decision. The vendor (you) should define the parameters of the scorecard based on a discovery discussion with the customer about their needs and goals. Ask the customer to assess how your product compares to their current solution.

2. Timeline and terms: Set timelines and customer engagement expectations. The POC should have a clear end date and a check-in cadence to measure how you are benchmarking against the scorecard. The timeline should be reasonably aggressive. Set expectations for the level of customer engagement required. Identify which stakeholders need to be engaged and supportive.

3. Pricing: Discuss pricing upfront to ensure commercial intent. ****Establish an “on by default” price before starting the POC. The customer is automatically rolled into the paid plan once the POC period expires and/or the scorecard is achieved. Consider charging for the POC period if you are doing a significant amount of implementation work and support. You can offer a generous discount, but paying for a POC is a good filter for the seriousness of the customer.

4. Post-POC engagement and stickiness: Identify the metrics that indicate ongoing product usage and value. If a customer doesn’t continue using your product post-POC, they are highly likely to churn.

Script: Discovery call and scorecard proposal

Before we get a POC, it's important to us to understand what you are trying to achieve, your requirements, and how we can benchmark against those goals. We want to make sure we can accurately assess whether our product is delivering value to you.

We would suggest something like this [scorecard] but before we lock that in, we'd love to get a better understanding of your needs.

Competitor inbounds

Once the company takes off, it will likely draw attention from direct competitors in the market. We don't recommend taking competitor calls.

If the outreach is from Business Development or Corporate Development, it’s likely a fishing expedition to acquire the business early (at a premature, low valuation). It would not be a good use of time if you’re not planning on selling the business now. You’re also at risk of giving away competitive information about your product roadmap. Engaging in this would put a bigger target on your back. You should only talk to Corporate Dev if you’re looking to sell the business now (either the company is doing really well or really badly). See Paul Graham’s full article here.

If the outreach is from Product Teams seeking guidance on integrating open source components into their product, it doesn’t require a meeting. Kindly ask them to read the open source documentation and let you know if they have any questions. The competitor should engage with the open source project, making contributions to the project and doing their own engineering work. You don’t need to take a meeting for the competitor to integrate the open source project into their product.

When to hire a first sales representative

As a company grows, sales processes can move to representatives who will be able to execute effectively given insight and an established strategy after they take on an initial shape. This usually happens after a company has raised its Seed round.

Sales team structure

Sales teams are often divided between new sales (“hunters”) vs. account or relationship management (“farmers” for upsell) when you’re at scale (50+ salespeople). Depending on the size of the upsell opportunity and sales skills required, some organizations may reroute these back to the new sales team.

Generally, Customer Success doesn’t touch sales. They would alert the sales team to new leads that emerge from existing customers.

Important:

1. Sales data in the system must be accurate regardless of who’s managing it.

2. Be strict about revenue recognition policies.