The minimum viable fundraising system

What a fundraising system has to do

Strip away the software and a fundraise is a decision loop. Every working day during a raise, you make the same three decisions, whether you name them or not:

1. Who do I move forward today, and how?
2. Which conversations have gone quiet and need a nudge before they die?
3. What did I just learn that changes the order of everything else?

A system exists to make those three decisions fast and correct. That is the entire job. Anything in your setup that does not feed one of those three decisions is decoration. Color coding is decoration. A "priority" column you never sort by is decoration. A second tab nobody opens is decoration.

So the minimum viable system is not defined by features. It is defined by the smallest set of objects and fields that lets you answer those three questions in under a minute, on any day of the raise.

The four objects

Most founders model a fundraise as one flat list of firms. That breaks the moment a real round gets complicated, because the things you track do not live at the firm level. They live across four objects, and conflating them is why the 140-row sheet stops answering questions.

Fund. The entity that writes the check. Check size, stage, thesis fit, whether they lead.

Person. A human you talk to. A partner, an angel, an associate, a scout. People move between funds. An associate who passed at one firm shows up as a partner at another a year later. If your unit is the firm, you lose that person. If your unit is the person, you keep the relationship.

Path. How you got to the person. A warm intro from a portfolio founder, a cold email, a conference, an existing angel. The path is its own object because the quality of the path predicts the quality of the conversation, and because you need to know who to thank and who to route the next intro through.

Conversation. A specific exchange or meeting and what came out of it. Conversations are where the real state lives. Not "in progress." The actual content: what they liked, what they pushed on, what they asked you to send, what they said the next step was.

A firm is not an object you track. It is an attribute of a fund. The mistake is treating the firm as the row. The row should be the person, because relationships and conversations attach to people, and people outlast funds.

The fields that earn their place

Here is the minimum schema. Every field below exists because it feeds one of the three daily decisions. If you cannot connect a field to a decision, cut it.

PERSON (the primary row)
  name
  fund                  -> link to Fund
  role                  partner | associate | angel | scout
  path                  -> link to Path (how you reached them)
  stage                 not-started | reached-out | in-conversation |
                        diligence | committed | passed
  conviction            1-3   (your read on how likely, not their politeness)
  next_action           one sentence: the literal next thing YOU do
  next_action_date      when that action is due
  last_touch            date of last real contact
  waiting_on            you | them   (who owes the next move)

FUND
  name
  check_size
  stage_focus
  leads               yes | no | unclear
  thesis_fit          notes, not a score

PATH
  type                warm-intro | cold | event | existing-angel | inbound
  source              who or what opened the door
  strength            strong | weak    (only for warm intros)

CONVERSATION
  person              -> link to Person
  date
  summary             3 lines max: what they liked, what they pushed on
  they_asked_for      the artifact or answer they requested
  agreed_next_step    what THEY said happens next

Ten fields on the person, five on the fund, three on the path, four on the conversation. That is the whole thing. It fits in a spreadsheet, a Notion database, an Airtable base, or an index card stack. The format does not matter yet. The discipline does.

Two fields do most of the work and most trackers omit both.

`waiting_on` is the single most useful column in a fundraise and almost nobody has it. At any moment, every live deal is either waiting on you or waiting on them. If it is waiting on you, that is a task and it should have a `next_action`. If it is waiting on them, that is a follow-up timer. Sorting by `waiting_on = you` gives you your work for the day. Sorting by `waiting_on = them` and `last_touch > 7 days` gives you your follow-up list. Two sorts, and you have answered decisions one and two.

`conviction` is your private read, on a 1 to 3 scale, separate from their stage. A partner can be warm, responsive, and three meetings deep, and still be a 1 because you can tell they will never lead. Stage measures progress. Conviction measures truth. Keeping them in separate fields stops you from confusing motion with momentum.

How to run it daily

The schema is half the system. The routine is the other half. Three sorts, once a day, ten minutes.

First sort: `waiting_on = you`, ordered by `next_action_date`. This is your to-do list. Draft the follow-up, send the deck, answer the diligence question. Clear it.

Second sort: `waiting_on = them` and `last_touch` older than seven days. These are the threads going quiet. For each, decide: nudge, send a reason to re-engage like an investor update, or mark dead. Silence is a decision too. Make it on purpose.

Third sort: anything where stage or conviction changed since yesterday. A new commit reorders your urgency. A surprise pass frees up time you were spending on a dead deal. This is decision three, the learning loop, and it is the one founders skip because it feels like admin. It is not admin. It is the thing that keeps you working on the right deal instead of the loudest one.

Where a spreadsheet holds, and where it breaks

A spreadsheet runs this system fine up to a point. For the first thirty or forty people, with one founder driving, a sheet with these fields and three saved sorts will beat almost any tool, because you built it around your decisions instead of someone else's feature set.

It breaks in predictable places. Watch for these migration signs:

• You have a cofounder also talking to investors and you no longer know who touched whom. The sheet has no concept of "who owns this conversation," and two of you just double-emailed the same partner.
• Your `next_action` column is full but you stopped trusting it, because nothing reminds you when a date passes. The system only works if overdue actions surface themselves.
• The same person appears three times because they moved funds and you pasted a new row each time. Your person object has no identity.
• You are spending the ten daily minutes maintaining the sheet instead of using it. The moment upkeep costs more than the decisions it informs, the tool is working against you.
• You cannot reconstruct what a partner asked for two weeks ago, because the conversation summary lived in your email, your notes app, and your memory, and none of them agree.

Those are not reasons to buy a tool sooner. They are the signal that you have outgrown a flat file, and they tell you exactly what the next tool has to do: enforce one identity per person, surface overdue actions on its own, and hold conversation memory in one place.

Where RoundOS fits

RoundOS is built on exactly this object model. Funds, people, paths, and conversations, with the person as the unit and the firm as an attribute. The difference from a spreadsheet is that it pulls the raw material from where your round already lives, your email, calendar, meeting notes, and investor exports, and assembles the conversation summaries and `waiting_on` state for you instead of asking you to retype them at 11pm.

The daily three sorts become a decision queue that is already ordered: who owes you a move, which threads went quiet, what changed since yesterday. You still make the calls. The system just stops making you rebuild it every morning. It earns its place only after you have outgrown the sheet, which is the honest order to do this in.

The artifact, again, so you can use it today

You do not need RoundOS to start. You need the schema above and the three sorts. Copy the field list into whatever you already have open. Delete every column that does not map to a daily decision. Add `waiting_on` and `conviction` if you do not have them. Then run the three sorts tomorrow morning and see how long it takes to answer your cofounder's dinner question.

If it takes under a minute, you have a system. If it does not, you have a tracker, and now you know which fields are missing.