The pre-revenue valuation methods that angel groups actually use — Berkus, Scorecard, Risk Factor Summation, the VC Method, First Chicago, market multiples — live in textbooks, worksheets and spreadsheets. Search GitHub for any one of them and you find a scatter of single-method, zero-star scripts; every commercial tool that implements them keeps the arithmetic closed. I released openvaluation to be the missing piece: all eight methods in one MIT-licensed, pure-Python library with no runtime dependencies, no API key and no usage limit, where every result carries its own derivation.
The division of labour that makes this useful to AI agents
Language models get asked what a startup is worth every day, and they answer badly in a specific way: the reasoning reads well, but the multiples are invented and the arithmetic quietly slips. The fix is not a smarter prompt. It is a division of labour: the model does what it is genuinely good at — reading documents and pulling out structured facts — and hands those facts to an engine that does the arithmetic deterministically, with the working attached. Chain the two and you get the full promise: pitch deck in, defensible valuation range out, deterministically, from any AI agent. That sentence describes the chain; this package is the deterministic end of it. It ships with an MCP server, so an agent can call the methods as tools — free, with no metering.
Eight methods, constants exposed
The method constants people most often need to check are stated in the documentation and exposed as constructor arguments, not buried as literals:
- Scorecard weights (Payne, 2019 revision): 30% management team, 25% size of opportunity, 15% product, 10% competitive environment, 10% marketing and sales, 5% need for further investment, 5% other.
- Berkus Method: five elements, up to $500,000 each, capping pre-money value at $2,500,000.
- Risk Factor Summation: twelve risk factors, $250,000 per rating step, adjusting a comparable average by at most plus or minus $6,000,000.
- VC Method baseline discount rates: 60% at seed, 50% at Series A, 40% at Series B.
If your angel group uses different weights, you pass different weights. Overriding a constant does not require forking the library, and the result records which values were used.
Every result shows its working
A valuation that cannot be challenged line by line is a negotiating liability, so the unit of output here is not a number but a derivation: the arithmetic steps, the assumptions in force, the limitations that apply, the exact input fields read, and citations for the method and any benchmark data used. A readiness report says which methods can run on the facts you have, and ranks each missing field by how many further methods it would unlock. Running everything applicable at once reports the spread of disagreement between methods — which is itself information about how much the number should be trusted. One invariant is tested outright: a method reported as ready always runs.
What executable documentation caught
Every worked example in the documentation is executed by the test suite. Writing the docs under that constraint caught four errors before release: three where my hand-computed example numbers were wrong, and one where I mispredicted which methods would run on a given input. It also surfaced two real defects — a floating-point residue that returned a Scorecard valuation of 5875000.000000001 through the API, and a lowercased label that rendered a limitation as if it contained a typo. The first CI run across Python 3.9 to 3.13 caught another: a module-level import guard was silently skipping the entire 37-test tool layer on every version without the optional MCP dependency installed. The suite now stands at 311 tests, and since v0.1.1 a guard asserts that the version number agrees across packaging metadata, the module and the citation file, because three hand-maintained copies drift silently.
Rewritten from the published sources, not ported
I built the valuation engine behind Wakeworth, a production valuation product, and the obvious move was to open-source that engine. I did not. The internal implementation carries about a dozen tuning constants with no citable source — publishing them would dress private judgement up as authority. The public package is implemented from the published descriptions and cites them; what carried over is the architecture: a declarative model of what each method needs, and the hard split between probabilistic extraction and deterministic calculation.
What it is not
- Not investment advice, and not a 409A valuation. These methods produce negotiating anchors and sanity checks; a valuation with legal or tax standing needs a qualified appraiser.
- Not an extractor. It takes structured facts; reading those facts out of a pitch deck is a separate job, and a good one for a language model.
- Not a market data source. The shipped benchmark figures are labelled illustrative placeholders, and any valuation that touches them says so in its own limitations.
- Simplified textbook methods, each with an explicit applicability boundary — the readiness layer and every result state which boundary applies.
Where it sits
openvaluation is the calculation layer of a product I built and operate alone. It is what the governed-systems claim looks like in practice: the probabilistic part stays with the model, and the part that must be reproducible is deterministic code with its derivation attached. The canonical record for the package, including maturity, evidence links and a machine-readable companion, lives on this site under projects.