Founder and investor reporting — Avirup Chakraborty

01

What a founder owes

When an investor funds a startup, the founder owes them reports — for as long as the money is in the company. This is one of them. It has to be written again next quarter, and the quarter after that, in a slightly different shape for every investor who asks.

Fig. 01A quarterly update, finished and ready to send. Headline summary, the vitals an investor asks for first, then the metrics behind them. — Keel, founder interface

Today that runs on email, Excel and Google Docs, and the cost lands on both ends. A founder rebuilds the same numbers per investor. An investor holding ten companies cannot tell who is late without asking each one.

Both halves are the same missing thing: the obligation is not an object anywhere. It exists as a sentence in somebody’s inbox, so it cannot be tracked, chased or closed without a person doing it by hand.

The bet the product is built on: an investor’s request becomes an item in the founder’s queue with a date on it, not an email. Everything else here follows from that — how the update gets written, what it is made of, and what the investor can see without asking anyone.

02

Where this came from

The research was small and I would rather state its real size than inflate it: five interviews — two investors and three founders, all at stealth stage — alongside a founder with deep domain knowledge in the space, who worked the synthesis with me. Five is enough to find a shared problem. It is not enough to claim a market, and nothing here leans on it as though it were.

Fig. 02A stakeholder session. The participant is blurred deliberately — they agreed to talk about their work, not to appear on a portfolio. — Keel, research

Everything went onto one board, and it came out in two columns — what an investor wants and where it hurts, then the same for a founder. That split is why this is two products rather than one. It was not a design instinct; it was the shape the evidence arrived in.

One theme surfaced across the interviews, and one investor put it plainly: “Founders update data that they want, not those which the VC want to see.” That asymmetry is what the entire investor side is built to answer.

Fig. 03The synthesis board. Investor on the left, founder on the right; goals, pain areas and candidate solutions down each side. — Keel, research synthesis

Fig. 04The flows that came out of it — writing an update, building a deck, and summarising a document in the repository. — Keel, research synthesis

Two things on that board decided scope before any screen existed. Related-party flagging was an explicit investor ask, down to how the data would be sourced. And several notes are tagged AI feature in our own hand — so the assistant was scoped during research rather than added to a finished product later, which is the usual order and the wrong one.

What none of them disliked was reporting in principle. They disliked doing it again, in a slightly different shape, for the fourth time that quarter.

03

Writing the update

An update can start three ways, and the founder picks one up front: write it manually, start from a template, or ask the AI to draft it. Different starting points, the same document at the end, built from the same blocks.

Fig. 05Templates, typed by what they are for — quarterly reporting, monthly, fundraising. Most founders are not starting from nothing. — Keel, founder interface

Fig. 06The blank path. A slash menu inserts charts, metric tables, freeform tables and media into the document. — Keel, founder interface

The AI route is its own mode, and it is composed rather than typed. A founder does not describe an update in a paragraph and hope. They assemble it — which metrics, which files, what tone, which charts — and only then ask for the draft.

Fig. 07The AI route. Context in the box if you want it, but the substance is in the controls beneath: metrics, repository sources, tone, charts, files. — Keel, founder interface

Decision A

The AI drafts only from sources the founder attached

What was true: An investor update is a reporting obligation, not content. A number in one that nobody can trace back is worse than no number, because it will be read as fact and acted on.
What I chose: The founder picks sources from the Data Repository first. The assistant drafts from those and nothing else, the draft is refined in chat, and every version is restorable. The AI writes; the founder signs.
What it cost: Two minutes assembling sources before anything is generated — slower than a blank prompt. That buys never having to defend an unattributable number to a board, and the founder can save the selection and format as a template, so the same metrics and layout do not have to be picked again next quarter.

Fig. 08Metrics are chosen before drafting, not cited afterwards — the order is the guarantee. The rail keeps the running selection visible. — Keel, founder interface

Fig. 09Draft, refine in chat, restore any earlier version. The document is the object; the chat is a rail beside it. — Keel, founder interface

However it was written, sending it does one more thing: it offers to make the update recurring — quarterly or monthly, to that investor. That is the same idea as the dated request in section 09, arriving from the founder’s end. A thing that was going to be remembered becomes a thing that is scheduled.

Most investors end up seeing a deck rather than a document. So decks are built here too, from numbers that are already in the product, and edited either directly or by asking for a change. Nothing gets exported to slides and cut off from its source.

Fig. 10The deck editor. Slides are generated from the same sources as the update, then modified directly or by prompt. — Keel, founder interface

04

Metrics, dashboards, and who arranges them

Every block in that update is built from a metric, so the metric model is the real foundation under it. It runs in three steps: define the metric, decide how it presents, then arrange where it lives.

Decision B

Metrics are formulas, not a catalogue

What was true: Every investor asks for something slightly different. A fixed list of supported metrics is wrong for everyone on day one, and wrong in a different way for each of them.
What I chose: Metrics are defined in the UI as formulas over other metrics — Gross Margin is Gross Profit ÷ Revenue × 100 — with frequency and format set by the founder. Sheets or Excel cloud can be connected to map the inputs in.
What it cost: Setup work the founder has to do once, before the product does anything useful for them. Common metrics ship predefined — revenue, gross profit, EBITDA and the like — so the first hour is filling gaps rather than starting from an empty list. A closed catalogue would have looked complete on day one and been unfixable on day thirty.

Fig. 11A metric is its definition. Frequency and format are part of the metric, not display settings hidden elsewhere. — Keel, founder interface

Fig. 12How it presents is a property of the metric too — chart or table, label, colour, decimal places, and the insight stated alongside it. — Keel, founder interface

Those metrics render into a dashboard, and the dashboard is the founder’s to arrange. It has a name, it can be renamed and duplicated, and a copy can be reworked without disturbing the original. A founder ends up with more than one — because the view you use to run the company and the view you send to an investor are not the same view.

Fig. 13Financial Performance, on a named dashboard. Edit layout, duplicate, rename and export sit together in one menu. — Keel, founder interface

Fig. 14Duplicating states plainly what it protects: a copy to customise without affecting the original. — Keel, founder interface

This pattern pays for itself a second time on the investor side, doing a different job. An investor keeps a performance view for conversations with their own limited partners and a reporting view for chasing what has not been filed — the same mechanism, two problems.

05

Cash reporting, deliberately thin

Bank transactions are the easiest place in this product to build charts, and charts are what everyone expects to see there. That is exactly why this was worth deciding rather than defaulting.

Decision C

Analytics deferred — but related-party flagging ships in the MVP

What was true: An analytics layer over bank data is the obvious first build and the one investors on the board never actually asked for. What they did ask for was a way to see related-party transactions, down to how the counterparties would be identified.
What I chose: Transactions across banks, categorised, and nothing else — plus a related-party register covering individuals, companies and trusts, in from day one.
What it cost: It looks unfinished next to a dashboard of charts. I took that, because related-party transactions are precisely what an investor or an auditor goes looking for — that is a governance surface, and a chart is not.

Fig. 15Transactions across banks, categorised by hand or re-tagged, with high-value entries flagged and related parties named inline. No analytics layer — a scoping decision, not an omission. — Keel, founder interface

Fig. 16The related-party register: individual, company or trust. Kept when the charts were cut. — Keel, founder interface

06

The fund, across ten companies

The other end of the loop. An investor arrives with two questions at once — how is the fund doing and who has not filed — and they are usually answered on two different screens, by two different teams, on two different days.

Here they are one table. Deployed capital, current value, MOIC and net IRR sit above fund value over time and allocation by sector; the reporting-status column runs down the same rows. Performance and compliance in one view, because an investor is never asking only one of those things.

Fig. 17The portfolio. Fund-level performance at the top, per-company status in the table below — including who is overdue, without anyone being asked. — Keel, investor interface

Investors also report upward themselves — to their own limited partners, and in India under SEBI’s requirements for alternative investment funds. So the same obligation repeats one level up, which is why this side is built to gather rather than just to read.

07

One company, up close

The asymmetry from the research board lands hardest here. A founder writes about one company they own and know completely. An investor reads about ten they do not own, whose numbers arrive second-hand, late, and only when someone files them.

So each group of metrics is labelled with the question it answers, not just its name — Growth: is it getting bigger? Profitability: does it keep what it earns? Cash: how long does the money last? An investor is reading about a business they do not run, so the question has to be on the screen. A founder already knows it, which is why their side does not do this.

Fig. 18One company. Position at the top — invested, current value, MOIC against the hurdle — then the three questions, then everything they have filed. — Keel, investor interface

Fig. 19Everything filed across the portfolio. Each update carries an AI digest that links back into the founder's own document. — Keel, investor interface

08

What the AI is allowed to say

The assistant does two different jobs and they are kept apart on purpose. It raises things nobody asked about, and it answers things somebody did.

The raising half came straight off the research board, where the same example appears in both columns: a 50% jump in quarterly sales where 10% is normal. The investor wanted the deviation flagged. The founder wanted to be asked for the reason before anyone else saw it. One signal, two jobs — and two different orders on the screen: alerts rank by severity, insights by how many companies a pattern touches. Either can be starred for review rather than only dismissed.

Fig. 20Signals raised from what founders actually filed, split into insights and alerts. Each one can be starred for review rather than only dismissed. — Keel, investor interface

Fig. 21An answer that names its coverage and its sources, and says plainly that the figures are as reported rather than modelled. — Keel, investor interface

On the investor side the numbers belong to someone else, so the assistant follows two rules it does not need on the founder’s. Every figure it gives links back to the update it came from. And every answer says what it could not see — “2 of 8 companies that have filed” — because the companies that have not reported are usually the point.

Fig. 22The same assistant on the founder's side, where the verbs change: someone writing about themselves summarises and analyses rather than screens a portfolio. — Keel, founder interface

09

The request, and where the loop closes

Everything above is upstream of one moment: an investor wants something, and that want has to become work with a date on it rather than a message someone has to remember.

Decision D

The request is an object, not an email

What was true: An investor asking for numbers had no way to make that ask exist inside the founder's work. It went out as a message and lived in whatever the two people did next.
What I chose: A request form on the investor side that picks companies, metrics, period and deadline, and creates a dated obligation in each founder's queue. Its state is visible to the investor from then on, without a chase.
What it cost: Two products instead of one. The founder side alone would have been a shippable tool; the loop only closes if the other end is designed too, and that roughly doubled the surface I had to get right.

Fig. 23Companies, metrics, period, deadline. The summary rail restates the request as the founder will receive it, before it is sent. — Keel, investor interface

Fig. 24The handoff. Asking the assistant to draft a request opens the form already filled, and names the question that produced it. — Keel, investor interface

The second screen is the whole bet in one action. Ask the assistant to draft a request and you do not get a paragraph back — you get the form, already filled in with the right companies and the right period. Reading the portfolio and asking a founder for something are one click apart.

10

Declared, not built

Two areas are in the navigation with nothing behind them, on purpose. LP reporting — the fund reporting up to its own limited partners — and SEBI reporting are both real obligations that came up in the research, and neither is designed yet.

Both are marked Coming soon, and each screen says what it will do. LP reporting will build the quarterly pack — capital accounts, NAV, drawdowns and distributions — from figures the founders have already filed, instead of exporting them to a spreadsheet first. SEBI reporting will assemble the return from data the fund already holds, rather than asking for it a second time.

Saying that on the screen tells a fund the obligation is on the way and how it will be met, which is something they can plan around. A section quietly missing is one they only discover after committing.

Fig. 25LP reporting, declared and not built. The screen says what it will do rather than pretending to do it. — Keel, investor interface

Fig. 26SEBI reporting, the same. Explaining the obligation is useful on its own; a non-functional form would not be. — Keel, investor interface

11

The rest of the surface

Ten product areas, because a reporting tool that only reports is not where the source material lives. The repository holds what the updates are drafted from — which is why it is a first-class area rather than an attachments folder — and it carries its own sharing history, contacts and broadcast inbox alongside it.

Fig. 27The Data Repository. This is what decision A draws from, and where a document can be summarised or compared against an earlier version. — Keel, founder interface

Fig. 28The empty state. A reporting product is at its emptiest on the day someone starts using it, which makes this the first screen, not an edge case. — Keel, founder interface

12

What I'd watch

The setup cost in decision B is the risk I took on knowingly. Metrics as formulas is right for the third quarter of use and hardest in the first hour of it. If founders stall during setup, the answer is not to ship a catalogue after all — it is that the Sheets and Excel mapping has to do more of the work than it currently does.

Three ways to start an update is generous, and generosity at the blank page is where products go to die. Manual, template and AI each earn their place on the research, but a founder opening this for the first time has to choose before they have any basis for choosing. If one path turns out to carry almost everyone, the other two should stop being a fork and start being an escape hatch further in.

And whether putting a date on the obligation is kinder than an email. Tracking the ask is the point of the product, but it also makes being late visible — between two people who are not equals. So the design keeps it factual: no scoreboard ranking founders against each other. Whether that is enough, only real use will tell, and it is the first thing I would look at.