---
title: "What fundraising asks of a CTO"
description: "What I had to make clear as CTO during an early raise: product evidence, demos, investor fit, diligence, and keeping sales learning alive."
canonical: https://prasad.tech/blog/raising-seed-round.html
source: html
generated_at: 2026-05-26T13:56:27.812Z
---
[Home](/) / [Blog](/blog/) / Fundraising 

 Sep 2025  9 min read Fundraising 

# What fundraising asks of a CTO

What I had to make clear as CTO during an early raise: product evidence, demos, investor fit, diligence, and keeping sales learning alive.

The round had many moving parts. My part, as founder and CTO, was to make the product real, make customer evidence easy to check, explain the technical choices plainly, and keep learning from sales calls while the round was in motion.

That work mattered because the sales motion was still early. Measured against the seed expectations a founder would face in 2026, the round could not rest on a mature sales machine or a long revenue history. The product had to carry more of the evidence. Mainteny later raised $2.7M, and the live product, customer conversations, and technical story helped make the company easier to believe.

The argument in one paragraph 

Fundraising gets clearer when the company is already worth checking. The CTO’s role is to make that review honest: show the product, know the customer workflow, explain the system, name the risks, and protect enough product time that the company keeps improving during the raise.

## The product has to carry part of the pitch

A deck can explain the market. A live product shows whether the team can turn market understanding into software. In early fundraising, that distinction matters because investors are trying to answer a simple question: can this team learn faster than the market expects?

My job was to make the demo survive real questions. If an investor asked how scheduling worked, I could show it. If they asked how a technician saw their jobs, I could explain the mobile flow. If they asked where the system was still simple, I could say so without dressing it up.

> The best fundraising conversations felt like accurate explanation. The strong parts were specific. The weak parts were visible. The next risks had names.

## Customer calls are part of diligence

Investors listen differently when the technical founder has been in customer conversations. You hear the buyer’s language directly. You know which objections are real. You can tell the difference between a product gap that blocks a deal and a feature idea that can wait.

At Mainteny, early customer and sales calls changed how I talked about the product. We were building field service management software for elevator maintenance companies, and the workflow was more than dispatch. Scheduling, quotations, technician updates, invoicing, and customer visibility all decided whether the office looked organized or lost control of the day.

What customer calls gave the raise 

Customer conversations turned the company story from “we are building software for maintenance teams” into a sharper claim: we understand how elevator jobs move through the business, where the workflow breaks, and which first version customers will actually try.

## Investor outreach rewards real homework

The outreach that got replies did not sound like a fundraising blast. It usually had a real bridge: a company the investor had backed, a founder they knew, a market they had already spent time on, or a problem their portfolio companies were likely to understand.

The exact note changes by stage. Before metrics are clean, the note has to prove that demand is real and the product exists. Once metrics exist, the note should put those metrics where an investor will see them fast.

|              | Early stage                                                      | Metrics stage                                                        |
| ------------ | ---------------------------------------------------------------- | -------------------------------------------------------------------- |
| Subject      | Specific buyer, workflow, first product evidence                 | Specific buyer, one headline metric, growth signal                   |
| Proof        | Live product, customer calls, first workflow, founder-market fit | Revenue, retention, conversion, usage, sales cycle, pipeline quality |
| Risk to name | Which first customer workflow becomes repeatable                 | Which motion scales without the founder doing every step             |
| Ask          | Advice on wedge, buyer, pricing, and first closes                | Advice on scaling GTM, hiring, expansion, and next milestone         |

The shape of the investor note changes once there are real metrics to share.

The subject line should carry the most relevant signal. For an early note, that is usually the buyer plus the live workflow. For a metrics note, it is the buyer plus the one metric that makes the note worth opening.

Example 1: early stage, closer to Mainteny

**Subject:** Elevator maintenance software, first workflow live in 3 months

Hi *\[Name\]*,

I saw your work in vertical software for services businesses. This may be close: we are building field-service software for elevator maintenance companies.

The first wedge is the request-to-invoice workflow. A service call becomes a technician visit, quotation, follow-up job, invoice, and customer update. Today that work still leaks into spreadsheets, WhatsApp, paper, and memory.

Where we are:

- First product version built in 3 months.
- Live workflow: work orders, scheduling, technician mobile updates, quotations, invoice PDFs, and basic customer visibility.
- Customer calls are already changing scheduling rules, invoice formatting, and technician context.
- The demo is real enough that buyers ask operational edge-case questions instead of category questions.

We are raising *\[amount\]* to convert the first customers and make this workflow repeatable. If field-service or vertical SaaS is close to your thesis, could we compare notes for 20 minutes?

Example 2: metrics stage, closer to Luminik

**Subject:** Luminik: *\[$X MRR\]*, *\[Y\]* events processed for B2B GTM teams

Hi *\[Name\]*,

I saw your work around B2B GTM infrastructure, especially *\[specific company or thesis\]*. Luminik may fit that map.

B2B teams spend heavily on events, but the pipeline record breaks across attendee lists, enrichment, pre-event outreach, meeting capture, and CRM attribution. Luminik gives teams one event-sourced record across source, enrich, sequence, capture, and attribute.

Current traction:

- *\[$MRR or ARR\]* across *\[paid customers or pilots\]*, growing *\[growth rate\]*.
- *\[X\]* events processed for *\[customer segment\]*.
- *\[Y\]* attendee or account records sourced and enriched, with *\[Z%\]* CRM match rate.
- *\[N\]* meetings, opportunities, or pipeline records attributed.
- *\[retention, sales-cycle, or expansion signal\]*.

We are raising *\[amount\]* to reach *\[next revenue or customer milestone\]* by *\[timeframe\]*. The question now is which GTM buyer repeats first and which parts of the event workflow the product should own next. If this is close to your thesis, could we compare notes for 20 minutes?

The order matters more than the exact wording. Start with why this investor is a fit. Explain the product in one plain paragraph. Give proof that the work is real. Name the commercial goal. Say why the founders have a right to work on it. Make a small ask.

The investor is reading for demand, not adjectives. A buyer with a project, a workaround, a deadline, and a budget owner is more convincing than a buyer with a vague problem.

What a good investor note has to prove

Fit**Why this investor**A portfolio company, thesis, founder connection, or market pattern that makes the note feel earned.

Demand**The buyer already has a job**A project, budget owner, current workaround, deadline, or internal promise already exists.

Product**One plain sentence**What the product does, who uses it, and where it fits into the buyer’s existing work.

Proof**Current evidence**Prototype, design partners, revenue path, customer categories, shipped product, or usage.

Ask**Specific next step**The round, milestone, advice needed, and a lightweight request for a call.

The note should help a good investor decide fast: this is my market, the demand is real, the product exists, the founders have a reason to win, and the ask is clear.

Reusable template

**Subject:** *\[buyer demand\]*, *\[current proof\]*, *\[stage\]*

Hi *\[Name\]*,

Thanks for *\[specific bridge\]*. I saw *\[portfolio company, thesis, founder, market, or program\]*. That caught my attention because we are building for *\[same buyer or adjacent buyer\]* from *\[specific angle\]*.

*\[Buyer\]* already has *\[live project, budget pressure, deadline, or internal promise\]*. Today they solve it with *\[current workaround\]*. We are building *\[product\]* so they can *\[specific job done\]* inside *\[existing tools/workflow\]*.

A few facts on where we are:

- *\[Live artifact\]*: prototype, demo, pilot, first customer workflow, or shipped product.
- *\[Customer evidence\]*: named logos if public, otherwise buyer categories and why they matter.
- *\[Commercial path\]*: possible MRR, paid pilot value, pipeline stage, or the first budget owner.
- *\[Product progress\]*: the part already built and the part being built next.

The founder-market fit is *\[specific reason\]*. I have *\[relevant proof\]*. My co-founder has *\[relevant proof\]*.

We are raising *\[amount\]* to reach *\[specific milestone\]* by *\[timeframe\]*. We would value your advice on *\[specific risk: GTM, wedge, buyer, pricing, channel\]*. If this is close to your thesis, could we compare notes for 20 minutes?

## The CTO owns technical credibility

Technical credibility during a raise means explaining why the system is shaped the way it is, which risks are real, and which decisions were intentionally postponed.

|                            | Question                                                          | What the CTO should make clear                                 |
| -------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------------- |
| Can the team build?        | Live demo, shipped workflow, customer-visible progress            | Show product behavior instead of only describing future plans. |
| Is the architecture sound? | Core stack, data model, deployment shape, reliability basics      | Explain tradeoffs in business language.                        |
| What is still early?       | Known gaps, manual steps, shallow integrations, missing analytics | Name limits before someone else finds them.                    |
| Can the team learn?        | Customer objections turned into product changes                   | Connect sales calls to roadmap decisions.                      |

The CTO's job is to make the product clear without turning every investor call into an architecture review.

## Diligence punishes vague claims

Diligence is where a story meets documents. Product screenshots, customer references, contracts, financial model, cap table, technical notes, hiring plan, and demo access all need to tell the same story.

The CTO should prepare the product side before the first serious investor asks. Write down the architecture in plain English. Keep a clean list of known limitations. Make sure the demo account works. Prepare answers for security, data handling, reliability, and what will change after funding.

CTO diligence checklist

- **Demo path.** One reliable flow that proves the product’s daily value.
- **Architecture note.** The stack, data model, deployment setup, and the reasons behind each choice.
- **Risk list.** What is fragile today, what gets fixed with capital, and what can safely wait.
- **Customer evidence.** What customers tried, what they asked for, what changed because of it.
- **Roadmap logic.** The next product bets and why they follow from customer evidence.

## Protect the company while the round is moving

Fundraising can eat the company if every founder spends the week reacting to meetings, follow-ups, deck edits, and diligence requests. The product still needs to get better. Customers still need support. Bugs still compound.

|                     | Fundraising mode                              | Company-building mode                                                       |
| ------------------- | --------------------------------------------- | --------------------------------------------------------------------------- |
| Investor calls      | Narrative, fit, objections, follow-ups        | Customer calls continue so the story stays connected to reality.            |
| Diligence           | Documents, references, technical notes        | Product reliability and demo quality stay protected.                        |
| Narrative iteration | Sharper wedge, clearer market, better answers | Roadmap decisions still come from customer evidence.                        |
| Terms and timing    | Decisions that shape the company for years    | The product must keep earning the round while the round is being discussed. |

A raise creates a second operating mode. The company needs both modes to stay alive.

## Good investor fit feels calm

The best investor conversations required clarity. A good investor asked better questions, understood the stage, respected what was still unknown, and helped sharpen the company without pushing it into a story that did not fit.

A bad fit usually showed up in the questions. If the investor wanted a different company, a different market, or a level of certainty the stage could not support, the right answer was to move on. Capital is useful when it increases the odds of doing the work. It is expensive when it forces the company into a shape the founders do not believe in.

## What I would do again

- **Put the product in the room early.** A real workflow changes the tone of the meeting.
- **Join customer calls.** The CTO should know the commercial objections firsthand.
- **Tell the truth plainly.** Investors can handle early-stage risk. They lose trust when the risk is hidden.
- **Separate fundraising work from product work.** Context switching makes both worse.
- **Choose investor fit carefully.** A seed investor becomes part of the company’s operating reality.

## What I would tighten next time

- **Prepare the data room earlier.** It is easier to improve the story when the underlying material is already organized.
- **Write the technical memo before diligence.** A clear memo reduces repeated explanations and exposes weak thinking early.
- **Track investor objections more systematically.** Repeated objections are market feedback. One-off objections are usually taste.
- **Keep the outreach list narrower.** A small group of well-fit investors beats a large list that creates false motion.

What stayed with me 

Fundraising is easier when the CTO behaves like a business owner. Build the product, sell through the workflow, explain the technical choices, prepare the evidence, and protect the company’s ability to keep learning.

![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) 

## Prasad Subrahmanya

Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team.

[LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) 

[ Back to blog](/blog/) 

## Filed under

Fundraising fundraisingCTOcustomer evidence 

## Related notes

[**Alfred: how I run repeated work as a solo founder**How I use Alfred to turn repeated company work into plans, summaries, draft replies, and pull requests I can review before anything ships.](/blog/alfred-solo-founder-operating-system.html)[**Separating agent work from founder work**Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me.](/blog/dedicated-mac-mini-solo-startup.html)[**gstack, CLAUDE.md, and founder coordination**gstack formalizes role-based agent work. The harder part is still product rules, cross-session context, and isolated branches.](/blog/gstack-solo-builder.html)