How To Start A Company

Great companies usually start with a simple belief: something should exist that does not exist yet.

At zero, you do not need a perfect plan, a team, funding, or a polished product. You need a problem worth exploring, a customer you can learn from, and enough momentum to take the next step.

This chapter is about what you do from literal zero.

Should You Start a Company?

Everyone should try to start a company at some point in their lives.

It's hard, takes a while to pay off, and sometimes comes with significant risks. But you end up with something you built yourself. The real question is whether it's the right time for you to make an attempt.

A good starting point is if

• You have seen a painful problem up close.
• You understand a customer or industry better than most people.
• You have access to a market other founders cannot easily reach.
• A new technology makes something possible that was not possible before.
• You keep coming back to the same problem even after trying to ignore it.

If any of these are true, and you're in a place where you've got extra time (for a side project) or want to take some risk, it's probably the right time to start a company.

How to Come Up With Startup Ideas

Startup ideas can come from many places. Most good ones start with a problem.

A problem gives you something real to test. If people already feel pain, already spend money, already use awkward workarounds, or already complain about the current options, you have signal. You may still be wrong about the solution, but you are pointed at something that matters.

Most startup ideas come from three sources

Here's where to look for problems to solve.

The best source is a problem from your previous work.

A second source is your personal life.

A third source is customer research.

The iPhone created the mobile app boom. Cloud infrastructure made it easier to start software companies without buying servers. Modern AI is creating new ways to build, search, automate, generate, and interact with software.

When a new technology arrives, it changes what is possible. Things that were too expensive, too slow, or too awkward suddenly become practical. That creates startup opportunities. But it needs to be mapped to a problem space.

The important thing is to connect the technology to a real customer pain.

“We are using AI” is not a startup idea. “We help paralegals review discovery documents in half the time” might be. The technology is the unlock, not the reason customers care.

what became newly possible that customers already wanted?

Some startup ideas come from a specific opportunity you have unusual access to.

This is called alpha — opportunity you have that's higher than the market has access to.

These opportunities can be powerful because they give you a head start.

Use alpha as a wedge to build something durable. A relationship can help you win the first customer, but the company still needs repeatable value. A regulatory change can create urgency, but the company still needs a product. A unique distribution channel can get attention, but the product still needs to retain customers.

Evaluate Startup Ideas

Not all startup ideas are worth pursuing. Whenever you want to go for something, evaluate the idea critically across four lenses.

The market should be big already or small but likely to become huge. A big existing market means people already spend money in the category — demand is proven. The opportunity is to serve a specific segment better than the current options.

A small but growing market can be even better. New technologies, regulations, platforms, and behaviors often create markets before they look large on a spreadsheet. The risk is timing, but the upside is that you can enter before the answer is obvious. Do not choose a market solely because it is large. A market is useful when you can identify a reachable customer with a painful problem and a budget. If your market is too small, you will run into serious issues growing revenue.

Founder/market fit means you are able to understand and serve the market. Maybe you worked in the industry. Maybe you are the customer. Maybe you have relationships that help you get early meetings. Maybe you understand the culture and constraints of the buyer better than outsiders do.

What this means in practice is: do you have a realistic shot at actually starting this company? With software, in 2026, the answer is probably yes. But if you're not a lawyer trying to start a law firm, it's probably not.

The best startup ideas solve painful problems. Pain means the customer already cares — they are losing money, wasting time, missing opportunities, taking on risk, or bound by a workflow they hate. A nice-to-have product can work, but it is much harder to sell. A painful problem pulls the product into the market.

what does the customer do today because your product does not exist, and would they pay you to fix it?

A unique insight is something you believe that most people in the market have not realized yet. It might be that a customer segment is underserved because incumbents are focused upmarket. It might be that a workflow can now be automated because of a new model. It might be that buyers dislike the current tools more than outsiders realize. It might be that a product that worked in one country or industry can work in another.

Without a unique insight, you are probably entering the market the same way everyone else sees it. That does not mean you cannot win, but it makes the path harder.

Some examples of positive signals

• You are building something you personally want.
• It only recently became possible.
• There are successful analogs elsewhere.
• Customers already hacked together a solution.
• The market pulls the product from you.

Common mistakes

• Avoiding ideas that seem too hard.
• Avoiding boring industries.
• Being too afraid of competitors.
• Waiting for the perfect idea.

Pick a Wedge Market

A startup idea is the wedge. The market is the world around it. Picking a market matters because it determines who you learn from, how you sell, how much customers can pay, how large the company can become, and what kind of product you need to build.

A good early market has a few traits

• The customer is easy to describe.
• The pain is frequent or expensive.
• The buyer has budget.
• You can reach customers without needing a giant sales team.
• The current alternatives are bad, expensive, slow, or outdated.
• The market is changing in a way that creates an opening.

Start narrow. This feels counterintuitive because founders want the company to be big. But the best way to become big is often to start with a small group that cares intensely.

Do not say your customer is “small businesses.” Say your customer is “independent dental practices with three to ten locations that struggle with insurance claim denials.” Do not say your customer is “creators.” Say your customer is “YouTube educators selling paid cohorts who need to convert viewers into students.” Specificity helps you build, sell, and learn. You know where to find customers. You know what language to use. You know which features matter. You know who to ignore.

Pick a Name and Domain

Naming feels important because it is visible — and it is. You're building a brand. People will know your company by this brand. A good name should be simple, memorable, easy to spell, and flexible enough to survive changes in the product. You do not need a perfect name. You need a name that does not get in the way.

A few rules

• Avoid names people cannot spell after hearing once.
• Avoid names that lock you into a tiny feature.
• Avoid names that sound too similar to existing companies.
• Avoid cleverness that only makes sense after an explanation.
• Check basic trademark risk before you get attached.
• Make sure you can get a reasonable domain and social handles.

.com

Other options are .co, .app, .io, .ai, .dev, .tv (if in media), or .xyz (if you're in crypto). Do not use other TLDs — they rank lower and confuse customers. Startups will sometimes pick a good name then add “try” or “use” to the beginning of a common domain name.

Take the Leap

The beginning of a company should turn uncertainty into motion. Do not try to solve the next five years. Solve the next week. Start the company.

What comes next

Once you have chosen a problem and are committed to testing it, the next step is to build and deploy your MVP. That's what Chapter II covers.

How To Build A Product

Setting up an engineering department is more than just writing code. You need architecture, a database, infrastructure, testing, design, deployment, and a plan to keep it all running as you grow. Most first-time founders dramatically underestimate this; they think “building” means opening a code editor and hacking until something works. That approach gets you a prototype (which are still important when you start!). It does not get you a company.

This chapter walks through the full lifecycle of building a software product, from initial spec to production deployment to ongoing infrastructure management. At each step, we'll show you what matters, what most people get wrong, and how Cofounder can handle the heavy lifting so you can focus on your product.

Come up with a spec

Before you write a single line of code, you need a plan: a clear, minimal specification of what your product does and who it's for.

The goal at this stage is to define your minimum viable product (MVP). This is the smallest version of your product that delivers real value to a real user. It is not a landing page. It is not a demo. It is a working piece of software that solves a specific problem well enough that someone would actually use it.

To define your MVP, answer three questions

Once you have answers, write them down. This is your spec. It doesn't need to be formal — a one-page document or even a detailed bullet list works. What matters is that you've thought through the scope and committed to a boundary.

Create a repository

Git repository

If you're not familiar with Git, here's the short version: Git is a version control system that tracks every change you make to your code. GitHub is a platform that hosts your Git repositories in the cloud, lets multiple people collaborate on the same codebase, and provides tools for code review, issue tracking, and automation.

Why does this matter? Because without version control, you're one bad edit away from losing hours (or days) of work. With it, you can experiment freely, roll back mistakes, and work with teammates without stepping on each other's code.

Setting up a repository involves a few things

• Initialize the repo
• Set up branch protection
• Configure a README
• Add a .gitignore

branch

GitHub's own Getting Started guide

Set Up Deployments

Before you start coding, set up deployment. Yes, before. This is counterintuitive but important.

Here's why: if you wait until you've written a bunch of code to figure out deployment, you'll inevitably run into environment-specific bugs, configuration headaches, and “it works on my machine” problems. By setting up deployment first, every change you make is immediately visible in a real environment. This tightens your feedback loop dramatically.

Vercel

You need three environments

Deployment

With Cofounder, you can skip local development entirely — agents write code and deploy it to preview environments, so you review live URLs instead of running anything on your laptop. If you do want a local setup (and some founders prefer it for speed), Cofounder can help you configure that too.

Staging

Production

preview environments

Preview environments become even more powerful when you're working with AI agents. In a traditional development workflow, you'd review code in a pull request, try to visualize the changes in your head, and maybe run the branch locally to actually see them. With preview environments, every PR an agent opens is immediately deployed to its own live URL. You can see exactly what the agent built, click through it, and decide whether to merge — all without pulling a single branch to your local machine.

This matters because agents work fast. A single agent can open multiple PRs in the time it takes you to review one. Preview environments let you keep up: you can review several changes in parallel, each in its own live environment, and merge the ones that look right. It turns code review from a bottleneck into a lightweight quality gate. Instead of being the person who writes every line, you become the person who steers — directing agents, reviewing their output, and shipping the good stuff. This is what agent-native development looks like, and preview environments are the infrastructure that makes it practical.

Secret Management

never

environment variables

A few rules of thumb for secrets management

• .env
• Use different secrets per environment.
• Rotate secrets periodically,
• Limit access.

Start Building: Scaffold Your App

Now it's time to actually write code. The first step is scaffolding — setting up the foundational structure of your application.

Any modern web app has two sides:

• The frontend
• The backend

For your tech stack, we recommend

• Next.js
• Supabase

This stack — Next.js + Supabase — is battle-tested, well-documented, and one of the fastest ways to go from zero to a working product. It's also what Cofounder is optimized for.

On cost: GitHub is free for private repositories. Supabase has a free tier that's more than enough for development and early users, with paid plans starting at $25/month when you need more storage or compute. Between Vercel and Supabase, you can realistically run a production app for under $50/month until you have meaningful traffic. Don't let infrastructure costs scare you — the expensive part of building a startup is your time, not your server bill.

The Backend: What You Need at Minimum

Your backend is the foundation everything else sits on. Get it wrong and you'll be dealing with security vulnerabilities, data loss, and architectural rewrites down the line. Get it right and it quietly does its job while you focus on the product.

At minimum, your backend needs four things:

Authentication is how your app knows who a user is. It covers sign-up, login, password reset, session management, and (increasingly) social login via Google, GitHub, etc.

Do not build your own authentication system. This is one of those areas where rolling your own solution is almost always a mistake. Auth looks simple on the surface — it's just a login form, right? — but under the hood, there are dozens of security concerns: securely storing passwords, managing login sessions, preventing brute-force attacks, handling “forgot password” flows, and more. Getting any one of these wrong can expose your users' accounts. Use a proven solution.

Supabase Auth handles all of this out of the box. It supports email/password login, magic links (passwordless login via email), and social login with providers like Google, GitHub, and Apple. It also integrates with Supabase's database security so you can control what data each user is allowed to see — for example, ensuring users can only access their own records, not anyone else's.

You need somewhere to store your data. Supabase gives you a full database that can handle everything from simple user profiles to complex data with many relationships between different types of records. It's the same type of database (PostgreSQL) that powers some of the largest apps in the world, so it won't be something you outgrow.

Think carefully about your data structure early. What are the main things your app tracks? Users, orders, messages, projects? How do they connect to each other? For example, a user has many orders, and each order has many items. Getting this structure right early saves you from painful restructuring later.

That said, don't overthink it. Your data structure will evolve as your product evolves. Start with what you need for your MVP and iterate.

database migrations

Your API layer is how the pages your users see communicate with your server and database. When a user clicks “submit” on a form, or a page needs to load a list of items, those requests go through your API. In Next.js, you define these directly in your project — no separate server needed.

Your API handles things like: loading data for a page, saving form submissions, running business logic (“when a user does X, also do Y and Z”), and talking to third-party services like Stripe or Postmark.

Keep these routes clean and well-organized. Make sure they check that incoming data is valid before doing anything with it, and that they return helpful error messages when something goes wrong. These are the boring fundamentals that separate a production-quality app from a hackathon project.

Almost every real product needs to integrate with external services. Two are nearly universal:

Payments.

Setting up Stripe involves creating an account, adding Stripe's code library to your app, building the checkout experience your users will see, and setting up webhooks. Webhooks are how Stripe tells your app about events — “this payment succeeded,” “this subscription was cancelled,” “this card was declined.” Your app needs to listen for these notifications and respond appropriately (e.g., granting access after a payment, or sending a follow-up email after a cancellation). This is one of those integrations that seems simple but has a lot of edge cases: failed payments, refunds, subscription upgrades, partial charges, and so on.

Transactional email.

Other integrations you might need depending on your product: file storage (Supabase includes this), analytics (covered in the Scale chapter), error monitoring, and various SaaS APIs specific to your domain.

This is the one that trips up most first-time founders. You are responsible for making sure your app doesn't leak user data. This means:

• Only send users the data they need.
• Don't trust anything that comes from the browser.
• Make sure users can only see their own data.
• Keep secrets out of your codebase.
• Use HTTPS everywhere.

This is not optional. A data breach can kill a startup — both legally and reputationally. Even if you're using Cofounder to help set things up, it's still on you as the founder to understand your security posture and ensure user data is protected.

The Frontend: Building What Users See

The frontend is where your product comes to life. It's what users interact with, and it's often the difference between a product people love and one they abandon after thirty seconds.

TypeScript

That said, the agent is only as good as your direction. You need to deeply understand your UX and business logic:

• What are the core user flows?
• What happens at each step?
• What does it look like?

Traditionally, building a frontend meant hiring a designer to create mockups in Figma, then handing those designs to a developer to implement. This was slow, expensive, and created constant back-and-forth between design and engineering.

In 2026, agents can design directly in code. Instead of creating a static mockup and then translating it, you describe what you want and the agent builds a working version immediately. You can see it, click through it, and iterate on it in real time. This collapses the design-to-code pipeline into a single step.

This doesn't mean design thinking is irrelevant. You still need to understand your user flows, information hierarchy, and interaction patterns. But the artifact you produce is working code, not a Figma file. And because iteration is nearly instant, you can try ten variations in the time it used to take to get feedback on one mockup.

Once you have this clarity, building the frontend is largely execution. You're translating your flows and product thinking into components, pages, and interactions.

Deploy to Production

You've got a working app in staging. It's time to go live.

Deployment is the process of taking your tested code and making it available to real users. If you set up Vercel earlier (which you should have), this process is straightforward:

Quickly test in preview environments.

Test thoroughly in staging.

Merge to main.

Deploy.

Verify in production.

Vercel Workflows

Vercel Workflows lets you run background processes alongside your app. Here's the problem it solves: a normal API request needs to respond in a few seconds, but some operations take much longer — sending 1,000 emails, processing a large file, or running a multi-step AI pipeline. Workflows lets you kick off these long-running tasks, and it handles the hard parts automatically: if a step fails, it retries it; if the process is interrupted, it picks up where it left off; and you get a dashboard showing exactly what ran and when. Unlike older approaches that required setting up separate infrastructure, Workflows lives inside your existing Vercel project — no extra services to manage.

Testing and Quality: Avoiding AI Slop

AI slop

Avoiding slop requires discipline. Here's how:

Automated tests verify that your code works as expected. There are several types:

• Unit tests
• Integration tests
• End-to-end (E2E) tests

You don't need 100% test coverage on day one. Start with tests for your core flows — the critical paths that, if broken, would make your app unusable. Then expand coverage over time.

when using agents to write tests, verify that the tests actually test something meaningful.

Linters are tools that automatically scan your code for common mistakes and style inconsistencies — think of them like spell-check and grammar-check for code. The standard tools for JavaScript/TypeScript projects are ESLint (catches potential bugs) and Prettier (keeps formatting consistent). Set them up to run automatically every time code is saved or committed. This is especially important when AI agents are writing code, because different agents (or the same agent on different days) might use slightly different styles. Linters keep everything consistent.

agents.md

Good rules files include:

• Your tech stack and versions.
• Coding conventions (naming, file structure, import patterns).
• What libraries to use (and not use) for common tasks.
• Examples of well-written code in your project.
• Common pitfalls specific to your codebase.

The better your rules file, the better your agent output. Think of it as onboarding documentation for an AI team member.

Finally, use your own product. Constantly. Every feature you build, use it the way a real user would. Click through the flows. Try edge cases. Use it on your phone. Use it on slow internet. This kind of hands-on testing catches things that automated tests miss — awkward flows, confusing copy, interactions that technically work but feel wrong.

When Things Break: Debugging in Production

Your app will break. Not if — when. A database query will time out. An API integration will return unexpected data. A user will find a flow you never tested. This is normal, and how quickly you can diagnose and fix issues is one of the most important skills you'll develop as a founder.

where do you look?

Vercel logs

Supabase logs

Browser developer tools

error tracking

The key insight about debugging: most bugs aren't mysterious. They're usually one of a few things — a typo, a missing environment variable, an API that changed its response format, or a database query that doesn't account for a new edge case. The hard part isn't fixing the bug; it's finding it.

Infrastructure Management

Congratulations, your app is live. Now you have to keep it running.

reliability

As your user base grows, your database needs to handle more data and more people using it at the same time. Supabase manages most of this for you — it can automatically scale its resources up and down based on demand.

What you need to watch for:

• Slow data lookups.
• Storage growth.
• Too many simultaneous users.

Vercel handles frontend and API scaling automatically — it spins up more resources as traffic increases and scales them back down when it drops. This is great for handling traffic spikes without manual intervention.

The catch: this can get expensive quickly at scale. Vercel charges based on usage, and if you're not careful, a traffic spike (or a bot repeatedly hitting your app) can run up a significant bill.

Strategies for managing compute costs:

• Cache aggressively.
• Rate limit your APIs.
• Monitor your usage.
• Optimize your functions.

There's a classic founder dilemma here: do you throw money at infrastructure to move fast, or do you optimize ruthlessly for efficiency? The answer depends on your stage. Early on, optimize for speed — your time is more valuable than your server bill. As you scale, efficiency becomes critical because infrastructure costs can eat into your margins.

What Comes Next

Building is not a one-time event. It's a continuous cycle of shipping, learning, and iterating. Once your MVP is live, the real work begins — watching how users interact with your product, identifying what's broken or confusing, and improving relentlessly.

How to Sell

But first: ship something. The best product plan in the world is worthless if it stays in a document. Get your code into production, get it in front of real people, and start learning. Everything else follows from there.

How To Sell To Customers

Now that you've built an MVP, you need to get users.

Distribution is everything. You cannot launch a product, send a few cold emails, and expect users to show up. You need a brand, a website, a sales process, and a way to create demand over time.

Sales and marketing are the two sides of distribution. Marketing helps people discover you. Sales turns the right people into customers.

This chapter is about building that system.

Build a Brand

You need a brand.

A brand is not just a logo. It is the story people attach to your company. It tells customers why you exist, what you believe, and whether they should trust you.

A brand has three parts

The story of the company.

A set of values.

A visual identity.

Start with story — start with why. Uber's early story was simple: someone waited 20 minutes for a cab and realized the system was broken. The problem was obvious, emotional, and easy to repeat.

Your story doesn't need to be dramatic, but it does need to be a story.

Maybe you watched finance teams spend every Monday reconciling spreadsheets. Maybe you saw clinics lose money because insurance claims were impossible to track. Maybe you kept building the same internal tool at every job because the market options were terrible. That is the seed of the brand.

Your brand values should be just as clear. They should not sound like corporate posters. They should shape product and marketing decisions.

Examples of brand values

• Nike:
• Airbnb:
• Patagonia:
• Stripe:
• Shopify:
• Apple:

The visual identity is how the brand shows up — your vibe. It does not need to be perfect. It needs to feel intentional and consistent.

Elements of a visual identity

• A logo
• A color palette
• Fonts
• Button and layout styles
• Image, illustration, or screenshot style
• Basic rules for how everything should look together

Build a Website

Once you understand your brand, you need a website.

Your website is the home base for distribution. Sales emails link to it. Customers use it to understand what you do. Marketing campaigns send people there. Investors look at it before they take you seriously.

The first thing your website should do is tell any reader what your company does.

A good early website should answer

• Who is this for?
• What painful problem does it solve?
• What does the product do?
• Why is this better than the current way?
• What should the visitor do next?

Sign up

Do not overcomplicate the first version. You need a clear homepage, a simple product explanation, a few screenshots or visuals, and a call to action. If you run a software company, it should also convert readers into signups (self serve) or demos (enterprise).

Get Your First User

If you followed along with chapter 2, you should now have a product. Since you have a product, you need someone to use it.

Start with people close enough to give real feedback — friends, former coworkers, industry contacts, advisors, or people you know through your network. The important thing is that they understand the problem and will not immediately shut you down.

Do not just send a link and ask, “What do you think?” Watch them use the product if you can. Ask them to share their screen. Sit next to them. Pay attention to where they hesitate, what they misunderstand, and what they try to do that your product does not support yet.

You are trying to learn

Take the feedback seriously, but do not obey every request. Users are good at revealing problems. They are not always good at designing the solution.

Building a good company is a function of how well you solve your users' problems. Your first users also help refine your ICP.

Define Your Ideal Customer

Most people start too broad. They say they sell to founders, marketers, realtors, doctors, developers, small businesses, or enterprises. These categories are too vague for sales. You cannot write good outreach, build a strong pitch, or prioritize leads if your customer is “everyone who might maybe use this.”

Ideal Customer Profile

The second version tells you where to look, who to message, what pain to lead with, and what language to use.

trigger event

Good sales starts with good targeting. If your ICP is wrong, everything downstream gets harder.

Understand Your Competitors

Competitors are not proof that you should quit. They are proof that customers already care about the problem. The mistake is copying them.

If you copy their website, features, pitch, and customer list, you become a weaker version of something that already exists. The goal of competitor research is not to blend in. The goal is to find the opening.

Search the main keyword in your category and study the first few serious companies you find.

Look at

• Who their homepage speaks to
• What pain they lead with
• Which features they highlight
• What industries they mention
• How they price
• What their reviews complain about

what are they missing?

Choose Your Sales Motion

A sales motion is how you sell. The right motion depends on your customer, price, product complexity, and how much trust the buyer needs before they pay.

There are three questions to answer

A simple rule

• Cheap, obvious, low-risk products can be self-serve and product-led.
• Expensive, complex, high-trust products need consultative sales.
• If nobody knows you exist yet, you need outbound.

Choose the simplest motion that can close your first customers.

Set Up the Sales Workflow

Sales needs a system. The first version does not need to be complicated — it needs to help you track who you are selling to, what happened, and what happens next.

A CRM is where you track customers. A structured spreadsheet can work. A lightweight CRM can work. What does not work is trying to remember every conversation in your head.

Your CRM should answer

• Who are we selling to?
• Who is the decision maker?
• What stage is the deal in?
• What did we last discuss?
• When do we need to follow up?
• Why did we win or lose?

Cold email only works if your email lands in the inbox. New domains have no reputation. If you create a domain and immediately send hundreds of emails, email providers may treat you like spam.

Before outbound, set up the basics

• Use a real business domain.
• Configure SPF, DKIM, and DMARC.
• Send a small number of targeted emails first.
• Ramp volume slowly.
• Keep bounce rates low.
• Make it easy for people to opt out.

A lead list is a list of companies or people who might buy. Start with the ICP, then look for evidence that a company has the problem now. Hiring posts, funding announcements, product launches, new executives, regulatory changes, industry news, and public complaints can all be useful signals.

A good list is

• Relevant.
• Repeatable.
• Reachable.
• Rare.

Then score the leads

Tier 1:

Tier 2:

Tier 3:

Spend most of your time on Tier 1 and strong Tier 2 leads.

The ICP tells you which companies to target. The decision maker tells you who to contact. The right person is not always the most senior person — it is the person who feels the pain, understands the workflow, and can influence the purchase.

Look for

• Problem fit.
• Budget or influence.
• Timing.
• Familiarity.

Do not spend forever finding the perfect contact. Pick the best person, test the message, and move.

Nobody wants to engage with spam. Good outreach is casual, clear, concise, and contextual.

This works because it references a trigger, names a problem, says what the product does, and asks for a small next step. Cold email is useful, but it works best when the prospect can also find a real website, a real point of view, and real signs that your company understands the market.

Run the Sales Process

A pipeline is the path a deal moves through from lead to customer. The stages should reflect real progress — a deal should only move when something objective has happened.

A simple early pipeline

Open

Trying to Contact

Contacted

Consult

Pitch

Verbal Commit

Closed Won

Closed Lost

Review the pipeline weekly. Ask what needs follow-up, what is stuck, what should be closed lost, and which deals deserve more attention.

A consult call is where you learn enough to decide whether you can help. Do not treat it like an interrogation. The best consult calls feel like real conversations — you are listening for pain, urgency, authority, budget, and fit. You are also qualifying them. Not every prospect should become a customer.

You want to learn

• What problem are they trying to solve?
• Why does it matter now?
• How do they handle it today?
• What is broken about the current approach?
• What happens if they do nothing?
• Who else is involved in the decision?
• What would a successful outcome look like?

A pitch is not a deck. A deck can help, especially in a consultative sale. But the pitch is the story you tell about the customer, their problem, and the better outcome you can help create.

A strong pitch usually follows this structure

Here is what we heard.

Here is why it matters.

Here is what changes.

Here is how the product helps.

Here is proof.

Here is the next step.

Talk about outcomes more than features. Customers do not buy a dashboard because it has filters. They buy it because it helps them see which campaigns are wasting money.

Closing is not a trick. If you have targeted the right customer, understood the pain, built trust, and pitched a useful solution, closing should feel like the next logical step. A good closing process makes buying feel safe.

Make sure you have

• A clear price
• A clear scope
• A clear buyer
• A clear approval process
• A clear timeline
• A clear onboarding plan
• A clear next meeting or signature date

Re-establish the business case before talking terms. Then make the next step concrete.

Improve the Sales Process

Once you have a few dozen real conversations, start looking at the process. Your CRM is how you diagnose where sales is breaking.

Look at the conversion between stages

• Leads to contacted
• Contacted to consult
• Consult to pitch
• Pitch to verbal commit
• Verbal commit to closed won

Do not obsess over tiny numbers. Early data is noisy. But review the process monthly and look for patterns. Sales improves the same way product improves: observe, learn, change one thing, and measure again.

How to do Marketing

Marketing creates awareness and generates warm leads. Sales converts those leads into customers.

A successful business usually does both. In the beginning, consumer companies tend to be more marketing-heavy. Business-facing companies tend to be more sales-heavy. But even B2B companies need marketing. Cold outreach works better when people can see that your company has a point of view.

Marketing starts by turning your brand into content. Content is not just posting for attention — it is how you teach the market what you believe, explain the problem, show your product, and make the company easier to remember.

Before you make content, decide what kind of content fits your market. The right content depends on your customer. Developers may want technical guides. Operators may want templates. Executives may want benchmarks. Consumers may want short videos or social proof.

Examples of content types

• Essays or blog posts
• Images and social posts
• Short videos
• Educational guides
• Templates and checklists
• Product demos
• Customer stories
• Benchmark reports
• Micro-apps — small free tools that solve a narrow problem and bring the right audience into your orbit

Most startup content is bad because it is rushed, generic, or written for no one in particular. One useful guide that says something specific is better than ten vague posts about “the future of work.”

Good content usually has one clear idea. It can teach something, show a workflow, explain a customer pain, compare approaches, launch a feature, tell a founder story, or give away a useful tool.

You can use AI tools to produce the assets. Image models like gpt-image-2 can help generate campaign visuals. Midjourney can help explore art direction. HyperFrames can help create motion videos from web-based compositions. HTML can be used to make social assets, product visuals, and decks.

The important thing is not the tool. The important thing is taste. Refine the output until it looks like something your company should actually publish.

Do not try every marketing channel at once. Pick a strategy that matches your market and your strengths.

• SEO
• Paid
• Organic
• Influencer or partnership marketing

Pick one primary channel and one supporting channel. Run them seriously for long enough to learn.

Making content is not enough. You have to put it where people will see it — publishing on your blog, posting on X or LinkedIn, uploading to YouTube or TikTok, sending a newsletter, launching on a community, running ads, or giving partners assets to share.

The platform should match the customer. Do not post everywhere because you feel like you should. Post where your ICP already spends attention.

You will need to create the accounts yourself. Use the same brand identity across them so the company feels consistent.

Marketing should create a learning loop. Do not confuse attention with progress. A post can get a lot of likes and produce no customers. A niche guide can get fewer views and produce three excellent leads.

Track the basics

• Which content gets attention?
• Which content brings qualified visitors?
• Which visitors become leads?
• Which leads become meetings?
• Which meetings become customers?

The goal is not to be famous. The goal is to create demand from the right people.

Tell a Consistent Story

Sales and marketing both depend on story. Not fake storytelling. Not manipulation. A good story is a clear explanation of why the customer should care now.

The customer is the main character, not you.

A simple story has five parts

The customer has a goal.

Something is getting in the way.

The old way is no longer good enough.

Your product creates a better path.

The customer gets a better outcome.

This story should show up everywhere: your website, outreach, consult calls, pitch, demo, proposal, content, ads, and onboarding.

If the story changes every time you tell it, the market will feel confused. If the story is clear, customers start repeating it back to you. That is a strong signal.

What comes next

Once you've got this down, you'll have to start scaling functions like customer support, product analytics, and others. That's what Chapter IV covers.

How To Scale A Company

Now you've had some early success, have a product, and have some customers. Now it's time to scale.

Scaling starts with the loop you already proved: build, sell, learn, and improve. Your job now is to make that loop faster, cleaner, and more durable. You need to understand what users do, where they get stuck, why they leave, which customers are worth acquiring, and what to build next.

This chapter covers the systems you need once your product has real users: product analytics, customer support, unit economics, and expansion.

Start With the Scaling Loop

A startup is not a static product. It is a loop.

You build something. You sell it. Users try it. Some get value. Some get confused. Some leave. Some ask for features. You take that signal, decide what matters, and build again.

That is the scaling loop

Build

Sell

Observe

Support

Learn

Iterate

Early on, you can run this loop manually. You can talk to every user, watch onboarding sessions, and fix bugs in real time. You should do some of this — it gives you a feel for the customer that no dashboard can replace.

But manual observation eventually breaks down. You need systems that capture signal as usage grows. Not just servers and databases, but the operating systems that help you understand, support, and improve the business.

Add Product Analytics

You cannot iterate well if you do not know what is broken.

Product analytics tells you what users are doing inside your app: how many sign up, how many complete onboarding, which features they use, where they drop off, and whether they come back. Without analytics, you are guessing. Analytics does not replace user conversations, but it keeps you honest.

PostHog

Setting up product analytics has two parts: installing the tool and deciding what to measure. The installation is straightforward — create a PostHog project, add the library to your app, include the project key and host in your environment variables, and identify users after they log in.

The measurement part is where founders usually get it wrong. They either track almost nothing or track everything. Both are bad. Start with the few events that show whether a user is moving through your product successfully:

• signed_up
• onboarding_completed
• core_action_completed
• trial_started
• checkout_completed
• subscription_upgraded
• teammate_invited
• support_ticket_opened

Use clear names, keep staging and production data separate, and do not track sensitive information like passwords, payment details, private documents, or API keys.

• A funnel
• A custom event
• A session replay
• Retention

A good analytics loop

Find a drop-off or unusual pattern.

Watch replays for that segment.

Talk to a few affected users.

Form a hypothesis.

Ship a small change.

Measure whether the metric improves.

Add Customer Support

The users you fought to win have given you something valuable: trust. That trust has a limit.

There are only so many times a product can confuse someone before they leave. Customer support exists to catch friction before it becomes churn.

Early on, support should be founder-led. Watch your first customers use the product. Ask what they expected to happen. Fix bugs in real time. Listen to the words they use to describe the problem. This does not scale, but it teaches you what the product feels like from the customer's side.

Fin by Intercom

A support agent is only as good as the knowledge and procedures behind it. Fin can handle common questions like password resets, billing updates, teammate invites, import failures, plan changes, and basic troubleshooting.

It should not blindly handle refund disputes, security concerns, data loss, angry enterprise customers, or bugs affecting many users — those should escalate to a human or become product work.

Support automation is not about hiding humans from customers. It is about resolving common questions quickly and routing uncommon questions correctly.

A knowledge base is the set of help articles, troubleshooting steps, and policies your support system uses to answer questions. Write docs in the language customers use, not the language your codebase uses. If users repeatedly ask the same question, either the product is unclear or the documentation is missing. Usually it is both.

Start with the basics

• Getting started
• Core workflows
• Billing and plans
• Troubleshooting
• Account management
• Known limitations

A support decision tree is a structured path for handling a category of issue. Decision trees make support consistent and make escalation cleaner — the person receiving the issue can see what has already been tried.

Start with the most common and painful categories

• Login problems
• Billing questions
• Import failures
• Permission issues
• Core workflow errors
• Cancellations
• Bugs that block users from getting value

Understand Unit Economics

Revenue tells you how much money is coming in. Profit tells you how much you keep. Both matter, but they describe the business from far away.

unit economics

Growth can hide a broken business. You can increase revenue by spending aggressively on acquisition, but if every new customer costs more to acquire than they are worth, you are not scaling — you are buying revenue at a loss.

Here are the core metrics

The rate at which customers leave. Logo churn measures the percentage of customers who leave. Revenue churn measures the percentage of revenue that leaves. Be precise about the time period — a 5% monthly churn rate is very different from a 5% annual churn rate.

How long a customer stays before churning. The time period must match the churn rate — if monthly churn is 20%, average customer lifetime is about 5 months.

Average revenue per user or customer.

Lifetime value — how much revenue or gross profit you expect to earn from a customer over their lifetime.

Customer acquisition cost. Early CAC is easy to understate because founder time often looks free. It is fine to do founder-led sales early, but do not assume that motion will scale without cost.

Compares how much a customer is worth to how much it costs to acquire them. If LTV is lower than CAC, something is broken — you need to increase retention, raise pricing, improve margins, lower acquisition cost, or revisit your ICP.

payback period

Do not obsess over precision too early. With small datasets, these numbers will be noisy. The point is direction. Are customers staying longer? Paying more? Costing less to acquire? If yes, the machine is getting healthier.

Expand the Business

Once the core product works, support is manageable, and your economics are improving, the next question is how to expand the ceiling of the business.

There are two broad paths.

The danger in both cases is distraction. Do not expand because you are bored. Expand because the evidence says the current ceiling is too low or the adjacent opportunity is too strong to ignore.

Before expanding, ask

Fundraising may become relevant at this stage, especially if the expansion opportunity is clear but requires more capital than the business can fund on its own. Fundraising is not the goal of scaling. It is a tool. The goal is to build a durable business that creates value for customers and captures enough of that value to keep growing.

What Comes Next

Scaling is not a single milestone. It is a discipline.

Add analytics so you can see what users do. Add support so you can hear where they struggle. Understand unit economics so you know whether growth makes the business stronger or weaker. Then use that signal to build better product, sell to better customers, and expand with intention.

The company gets better when the loop gets better. Keep the loop moving.

This chapter is still being written. Check back soon.