An LP fundraising pipeline for a first-time fund

The problem

During a raise, the usual direction of diligence reverses. LPs (limited partners, the investors in a fund) diligence the fund the way the fund diligences companies. Inside the firm, that creates the question founders usually face: where does the raise actually stand?

Mid-raise, the honest answer at many funds is a feeling. Conversations live in individual partners' inboxes, the target list is a spreadsheet with three owners and no dates, and "how much is committed against target?" gets answered from memory. A first-time fund feels this hardest: much of the book is outreach that has not been answered yet, and there is no prior raise to calibrate against.

What we built

Three structural decisions, all inside the CRM the firm already uses.

LPs became a first-class object. Rather than wedging investors in among portfolio companies, LPs got their own object in Attio, with the raise itself as a pipeline list over those records. Each entry carries the fields a raise actually needs: target commitment, probability, owner, lead source, last contact date, interest level, and LP type (family office, institution, and so on). Owner and last contact date are the two that keep the raise honest; the rest make it reportable.

Stages that match how LP conversations move, each with a probability. The funnel was extended in both directions: a Contacted stage at the top, because early in a first raise much of the book is unanswered outreach, and a Closed / Wired stage at the bottom, because a verbal commitment is not capital until it is wired. Each stage maps to a probability. Multiply each entry's target commitment by its stage's probability, sum across the live entries, and you have the weighted pipeline: a single coverage number the fund can hold up against its target every week. If the weighted pipeline covers the target several times over, the raise is on track; if it covers a fraction, the problem is at the top of the funnel, and no amount of closing effort will fix it.

Eight saved views, each answering a weekly partner question. By owner: who is carrying which relationships, and who is overloaded. By stage: where the funnel is thick and where it is thin. By LP type: is this raise leaning too hard on family offices. Stale contacts: live entries whose last contact date has slipped past a threshold. The stale-contacts view is the hygiene loop of the raise. In fundraising, silence is how commitments die, and a view that surfaces every relationship going quiet turns "we should circle back to them" from a memory into a queue.

What happened

The build surfaced three Attio API traps worth knowing before you script a pipeline like this one.

• Creating an attribute through the API requires a config object even when there is nothing to configure; leave it out and the request is rejected with a 400 error.
• The order of stages cannot be set through the public API at all. Someone has to drag them into order in the interface, so it belongs on the plan as a manual step.
• Saved views can be listed through the API but not created or changed. The 8 views were built by hand in the app; the scripted work stopped at objects, attributes, and options.

None of these are defects in the design, but each one silently reshapes a build plan that assumed the API could do everything, so we document them wherever this work comes up.

Outcome

The raise runs as a pipeline instead of a feeling. The weighted coverage number is a figure the partner meeting can open with, every conversation is logged against the LP it belongs to, and the stale-contacts view keeps the follow-up queue honest without anyone maintaining a spreadsheet. Because the whole structure lives where the rest of the firm's data already lives, there is no second system to keep alive after the raise closes; the LP object and its history simply become part of the fund's database.