ARR is the simplest way for an investor to understand how the business is progressing.

This is a natural point for investors to ask for an updated annual recurring revenue (ARR) number. ARR is the simplest way for an investor to understand how the business is progressing. It helps them cut through the noise and focus on the real and predictable streams of cash flow. However, sourcing an accurate ARR number is not always straightforward for founders. In fact, it’s more art than one might expect.

Time and time again, we find ourselves asking founders, “Is this the right ARR figure?” because at this early stage, defining ARR isn’t black and white. While the concept itself isn’t so complicated, the grey area is in the framing of revenue(s) in a manner consistent with the way that investors (especially investors in the SaaS space) view it. ARR should only reflect confirmed, recurring, cash-in-bank revenue from fully executed contracts.

ARR should only reflect confirmed, recurring, cash-in-bank revenue from fully executed contracts.

One-time usage spikes, unverified gross payment volume before failed transactions are filtered out, or pipeline deals still awaiting signature are all scenarios where a founder could easily overstate ARR through optimistic assumptions rather than defensible evidence.

Let’s take a deeper look at a few of these scenarios.

Scenario 1: Usage Credits ≠ Recurring Revenue

A customer buys $1K in usage-related credits in their first week. The founder sees that the payment settled and reports to their investor that their ARR increased by $52K. Is this ARR?

In most cases, it’s not. There’s no promise that the purchase is recurring, and even if so, at a weekly cadence. The customer may have bought the credits expecting to use them for the whole month. The customer may have expected to budget that much for a week, but ends up using way less and doesn’t need to buy more. They may use the credits but decide not to continue, etc., etc.

Instead, it would be better for the founder to frame usage revenue as a projection or run rate in discussions, e.g., a run rate of $4K this month.

Usage credits aren't ARR. One week's $1K purchase doesn't guarantee $52K in annual recurring revenue, it's a run rate at best.

Scenario 2: Gross Signups ≠ Net ARR

A startup noticed 20 new accounts bought paid service subscriptions through their website. Each subscription costs $10 monthly, so they surmise that their ARR increased by $2.4K and reported such in their KPI submission. Is $2.4K the correct ARR number?

Again, most likely not. We’ve seen up to 30% of B2C subscription payments fail at the gate (meaning ARR is 30% lower, not even factoring in churn). Bad credit card numbers and bounced payments are incredibly common, especially if the users originated from a new paid acquisition channel or from an influencer. Kaplan states transaction failure rates can reach 15% of total transactions in certain sectors. As mentioned, we’ve seen 30%+ in certain scenarios

Payment failures alone can wipe out 30% of gross subscription revenue before churn even enters the picture.

A few tips here:

1. Payment platforms can be confusing because they offer multiple “revenue” metrics (e.g., MRR, Gross Volume, Net Volume). Don’t just take those at face value; double-check what is included in the figure.

2. Filter out any pending/unpaid payments. Revenue must be in the bank account to be relevant. If noise from bad payments is too high, implement stricter fraud payment controls.

Scenario 3: Pipeline ≠ Booked ARR

A founder is negotiating a $50K deal with a potential enterprise customer. They’ve progressed through many meetings, and the contract is out to the customer for review and signature. Negotiations have been smooth so far, and the founder reasonably expects the deal to close. Can the founder include the deal as part of their existing ARR?

No. Not until the contract is fully signed and executed. No matter how smooth the process has been so far, wait for pen to paper to celebrate. Until then, the nominal remains in the pipeline.

Pipeline optimism belongs in a probability estimate, not the revenue number. A deal isn’t ARR until it’s signed.

Instead, provide a reasonable judgment of the likelihood that potential deals in the pipeline close, e.g., an 80% chance that the XXX deal for $100K closes in the next month.

Measuring ARR is part science, part art

There are many other scenarios where we can debate what should be included in ARR because it’s not an exact formula. But if you recognize the pattern here, we tend to lean towards caution when making judgements. It’s very easy to pass on to investors an ARR formed from flawed methodology, and it’s very easy for investors to miss the flaw. There aren’t many data points for investors to verify against, and the number has an inherently high p-value. An investor’s visibility is limited to waiting for the actual cash inflow to hit the bank, which can lag in the form of Net 30, Net 45, etc.

At OCV, we’ve developed multiple lines of defense over time to protect against incorrect ARR reporting. Ultimately, the best defense is educating founders on conducting proper due diligence when measuring ARR.

When ARR is hard to verify, err conservative. Founders who can defend every dollar earn more investor trust.

Founders are eager to show growth. As investors, we understand this, but ARR should be defensible with clear evidence. It’s better to err on the conservative side if a founder is not sure whether something qualifies as ARR. Investors would be happier spending time discussing revenue upfront than getting a flag down the line.

There is no perfect playbook, but there are proven strategies you can use to build open core businesses that scale with community support. I recently shared these strategies with the Open Core Ventures portfolio companies, summarized below.

You need proprietary IP to monetize—it’s not negotiable

If you don’t have any proprietary IP as a software company, you’re in for a bad day. Without proprietary features, you’re essentially competing on support and services, which rarely leads to venture-scale outcomes.

I see this mistake often. Founders think they can build a business entirely on open source software. If you keep all the code open source, then not only will your competitors compete with you, but if you get popular, other people will start offering the same thing as a SaaS solution. This applies even when you’re not the original maintainer of the upstream project. You must create differentiated value through proprietary features that solve real customer problems.

Make all code source-available

This might seem counterintuitive, but transparency in your proprietary code creates significant advantages. I recommend that all OCV companies make all their code source available so anyone can contribute, even to the proprietary parts. I don’t think there’s a great reason not to do this. Maybe competitors are copying you, but I’ve never seen a startup die because of this. Startups die because no one cares enough about them, no one is using their product, and their product is not improving fast enough.

Automate yourself out of a job

Every time you run into a problem or need to hold someone’s hand, improve the code, improve the docs, and make it so that hands-on support is no longer needed. Many open source companies fall into the trap of building their business around support and implementation services. This is a dead end for venture-scale growth.

It’s tempting not to automate yourself out of a job because you think, “then they won’t need us next time.” But integration and automation are what unlocked the growth of GitLab. The installation became much, much simpler. Resist the temptation to build a support/services business around your open source project.

Keep all code in a single repository

I cannot stress this enough: separate repositories are technically clean, but drastically reduce monetization potential. Instead, integrate both open source and proprietary code into a single repository using subdirectories with separate license files. Make it available for both self-hosted and SaaS deployments. Use OCV’s licensing template. This makes it very clear which parts are proprietary and which parts are open source while maintaining the tight integration necessary for effective development and monetization.

Integrating the code is where I see the most resistance, and it’s where companies make their biggest mistakes. Put everything in the same repo. The companies that opt for “technically clean” over a single repo are often the companies that fail.

Offer both self-hosted and SaaS options

Most companies should offer a SaaS version of their software. This isn’t about replacing self-hosted options but rather providing customers with choice and creating an additional revenue stream. Keep your SaaS version and your self-hosted version as similar as possible.

Typically, the SaaS version will have all of the open source features offered in a free tier, but with usage limits like “no more than three users per team” or other restrictions. The code itself should still be visible and modifiable. Make the proprietary features available in both options. If you create them in the SaaS version, make them source-available in the self-hosted version, too.

Distinguish between open source version and free SaaS tier

This is a crucial distinction that many founders miss: There can be a big difference between your open source version and your free SaaS version. The open source codebase should not have artificial limits built in—that would be antithetical to open source principles. Someone would just send a PR to remove that limit. But you can build a free SaaS version and impose limitations. This applies to proprietary features, too. A free SaaS version may offer limited access to some proprietary features, creating an on-ramp to paid features.

When you don’t control the upstream repo, build trust first

Ideally, you’re in control of the repository, but many open core companies build on existing open source projects they don’t control. If you’re not the maintainer of the upstream project, focus on becoming an active contributor before seeking integration. You should be contributing to the open source codebase to the extent that project maintainers see you and your company as a positive influence. Once you’ve established yourself as a trusted contributor, consider asking the upstream maintainers if you can add your proprietary code directly to their repository.

This approach hasn’t been tested widely, but I believe it could work because you don’t necessarily need control of the repo. You just need someone’s OK to have a subdirectory in there. The key is demonstrating that maintaining separate repositories is creating extra work and inefficiency.

Improve the open source code faster than before

A common community concern when companies form around open source projects is that development will slow down as resources get diverted to proprietary features. It’s important that the open source part of the codebase expands more rapidly than it did before the company existed. Most of the people at your company are net new. As long as one of them sometimes adds something to the open source codebase, the open source codebase should be better off.

Focus on value creation over reputation management

Many founders get paralyzed by concerns about how the community will perceive their commercialization efforts. The best way to maintain community trust is to consistently deliver value through your open source contributions and maintain transparency in your approach. If you’re contributing meaningfully to the open source project and being transparent about your business model, the community will generally respond positively.

Use buyer-based open core for feature segmentation

The buyer-based open core model is straightforward: Ask for money for features that managers and up want, and make the features that individual contributors want open source. Consider the user persona rather than the technical implementation. Management features like access controls, audit logs, and compliance tools naturally fall into the proprietary category, while individual contributor features often belong in open source.

When in doubt, don’t default to making a feature proprietary, thinking you can open source it later. Feature placement decisions are sticky. Once something is proprietary, internal reluctance to open-sourcing it grows over time.

Make sharing free, monetize the control

Don’t put barriers around fundamental behaviors that drive growth. Sharing is a viral thing. Keep that free. But after sharing comes the complications. Managers will ask, “Can we limit public sharing? Can we get an overview of what documents are shared with whom? Can we prevent people from sharing documents outside of our organization?” Make sharing wide open by default, but charge for the governance and control features that managers and executives need.

Become the obvious choice

Make your software more user-friendly than alternatives. Make your open source offering better than other open source options in the same space. When you become the default choice for open source users, converting them to paid plans becomes much easier. You want people to come to you regardless of whether they are looking for open source software or a paid product.

Don’t be afraid of competition. If a large company like Microsoft is adopting your technology, embrace it and use it to establish yourself as the expert. If competitors are white-labeling your software without attribution, make sure everyone knows it is based on what you made. Make a page on your website that lists all the companies building on your software. Make your company look as big as possible. Then, look at what they’re selling, as it’s probably an indicator of demand. Look at which ones are successful and what they are selling, and go build that.

One of the pitfalls I see founders and early product development teams fall into is over-valuing the requirements of potential customers. When a potential customer says, “I’d love to buy the product… if it only had XYZ feature,” the worst thing to do is to make that. It seems counterintuitive, but if a sales conversation has taken this turn, the most likely outcome is that it’s not a good fit. Potential customers are looking for an easy way out of the question of why they won’t buy.

It’s tempting to do whatever it takes to secure early customers, but adding features to satisfy one potential customer is a high effort for short-term gain and detracts from more meaningful improvements. Potential users frequently ask for things that are a low priority. And, if there’s no signed contract, there’s no guarantee that the potential customer will buy the product once the feature is added. Sometimes people use missing functionality as an excuse when the truth is the budget for the tool never existed in the first place or has since been slashed. For all you know, the last requirement of a potential customer could be nothing more than a carrot on a string serving as a buffer between you and the hard truth that they are simply not going to buy your product.

There are plenty of times when the suggestion is well intended and the potential user really believes their feature request will make the product better. Exercise caution if you decide to implement that feature request. Someone who has never used your product can’t really know how to make it better. Even if the features sound like a good idea, get used to the idea that you could be wrong. In these scenarios, take a highly iterative approach to feature development. What’s the smallest possible improvement you could make? Keep it small, simple, and agile as you may need to adjust course midway through or multiple times.

A similar approach can be taken for larger organizations where sales teams are involved. Features are rarely sourced from feature requests but a case can be made for implementing certain small, short-term improvements. In this situation, the sales representative has a vetted and established relationship with the potential customer so there’s less risk. Still, not every sales request is worth acting on. Product and sales should make a list of the top 5-10 highest priority requests each quarter.

Listen to the needs of your heaviest users instead

Prioritize features based on who is asking for them not how frequently they are asked for. Current customers can provide more relevant feedback than potential customers as they are already using the product and are better equipt to understand its limitations than someone who has never used it. The heaviest users of your product will give the best feedback. These are the users who have found the product’s edges. They know what works well and what doesn’t. They have felt the joy of having something just work and the frustration of trying to troubleshoot for hours, maybe even days, with no solution in sight. The heaviest users are the ones who have most likely submitted issues and pull requests proposing code modifications that might solve the problem they are experiencing. The ability to contribute back to the product is one of the greatest benefits of open core products.

After filtering up the best feedback from the heaviest users, weigh feature requests according to effort versus value. Low-effort, high-value improvements are prioritized over high-effort, high-value features. Stability comes from growth so the quicker you can ship improvements, the better.

Ask your community to help

To be efficient with capital, build with the community. Once you’ve decided which feature requests to act on, plant seeds by shipping a small minimally viable change (MVC) and asking the community to help mature it. This is one way to operationalize user feedback and test the feasibility and overall impact of the change without diverting internal engineers from the product roadmap set by the company.

Shipping functionality that is incomplete to expand the scope sometimes goes against instincts. However, planting those seeds even in an incomplete state allows others to see the path and contribute. With others contributing, iterations happen faster. You can have a long tail of categories that are at a minimal maturity that don’t get investment until they show traction.

While MVCs come with a low level of shame they allow the wider community to contribute and people to express interest. It is much more common for people to contribute to categories that already exist rather than suggest something entirely new. People who care the most are using it and just want it to work better. They rarely add scope.

You control your product roadmap

Ultimately, the product roadmap is created by the company, not the users. It’s the product team’s job to determine the product scope and which features fit into that scope. The entire product scope is defined by the product team and roughly 90% of the features will come from them as well. The other 10% will come from customers, potential customers, or sales requests.

The product scope defines the end result: what will this product do? The product scope is made up of features and functionality. A company may have a single product scope defined but there are many ways to implement the features and functionality. Product scope is developed through research and testing, primarily done by the product team. Ideas for features and functionality can come from a wide variety of sources. Users, contributors, and potential customers shouldn’t be adding scope.

Final thoughts

Feedback is critical to product development but not all feedback is equal. Heavy users will give you the best feedback and you should invest a lot of time in understanding how they use the product and what limitations they are running into. Potential customers are not that familiar with your product—the quality of their feedback is bound to be lower than users. Potential customers who are using a missing feature as a reason for not buying are probably not a great fit. Don’t listen to the last objection.

You should think of paid advertising like pouring gasoline on a fire. If you’re starting with real heat, it amplifies what’s already working. Pour it on damp wood, and it will flare up and burn out.

YC’s canonical advice is to “do things that don’t scale,” like manually finding and talking to users. Paid marketing is the opposite of this. It focuses on scale, the mechanics of ad buys, and funnel optimization instead of actually understanding who your users are. But people tend to gravitate toward the path of least resistance, and for founders, this is usually building software, not talking to users. Executing ads feels like building. Manually engaging users is outside the comfort zone.

The result is founders often reach for paid ads before it can be helpful. A product needs to deliver real value, retain users, and prove that the core works before it can scale. Paid is not a substitute for that work. It’s a multiplier on top of it. If you scale before proving the foundation, you actually make it harder to determine what retains users or makes them churn.

Paid acquisition is a science built on understanding your cost per acquisition (CPA), customer lifetime value (LTV), and payback period. If you don’t know LTV, you’re making bets without knowing the odds.

At the early stage, you can’t know LTV because it takes time to measure. If your assumptions about conversion, retention, and gross margin are too far off, it could have massive implications for the viability of paid marketing as an acquisition channel.

Take what happened with meal prep services in the early 2010s, for example. Blue Apron, HelloFresh, HomeChef—venture money poured into these businesses, and most of it went into paid acquisition. They had their CAC, LTV, and payback periods modeled out, and it looked solid. But the math was built on false assumptions. People were signing up for free trials and not sticking around. They just moved on to the next service’s free trial or found the cheapest alternative. At the end of the day, meal prep delivery is a commodity service. All those venture dollars essentially subsidized consumers’ meals and ad platforms.

The same thing is happening with inference today. Commodity agent platforms (AI SDRs, AI recruiters, etc.) can acquire a ton of new users via paid channels, and weekly active users will increase as they keep pouring into the top of the funnel. But at the end of the trial period, users move on to the next platform offering a free trial. Some try to solve this by requiring a credit card on file to start the trial, only to learn that 1/3 of these cards are declined when the trial is supposed to convert. Many times, founders don’t realize the credit card failed because some payment systems (i.e., Stripe) still recognize these as “converted trial users” and count it as MRR. Once founders figure this out, they have a ton of overdue receivables they have no way to collect.

If you cut paid completely, WAU drops, which is the leading indicator of churn. Without a constant stream of new paid acquisition cohorts masking churn, the retention problem surfaces. If your oldest cohort is only a few months old, you haven’t seen enough churn yet to know what retention actually looks like at 6, 9, or 12 months. Expanding new users can paper over a churn problem that was always there, just not visible yet in a young cohort.

Another thing many founders fail to appreciate is that maintaining a constant growth rate requires exponentially increasing spend. That’s a pretty counterintuitive concept. In other words, if you want to continue growing at, say, 20% per month, you have to spend increasingly more money every month.

So if you’re acquiring users who cost you money (because you run at negative gross margin given inference costs, for example), this has a compounding deleterious effect. Increasing spend to maintain a consistent growth rate of costly users is a death spiral.

If you don’t know LTV, retention, and churn with confidence, and you don’t know why users are retained or churn, paid marketing will make it harder and more expensive to figure it out.

Paid marketing isn’t the enemy, but premature paid marketing is. Used at the right moment, it’s a powerful accelerant. Used too early, it’s a way to burn runway learning things you could have learned for free by talking to your first hundred users. Prove value, prove retention, prove unit economics, and then scale. Performance marketing has diminishing returns, and potentially compounding negative returns. Organic acquisition compounds positively. Build that first.

“If you rename what it is called,” he wrote, “you help to remove the ‘bait and switch’ controversy by openly recognizing it as an emerging standard business model with specific attributes associated to it (i.e. GPL core, with commercial extensions).” Adam also explains that the emergence of a standard business model for open source was welcome and necessary. However, he acknowledges that these perspectives often result in a “religious open source war” and it was only a couple years later that the Open Source Initiative (OSI) shared its definitive stance on “open core.”

Objections to open core

According to the OSI’s statement on open core, the fundamental problem is that open core is just a nickname for proprietary software and shares no advantages with the user. The blog post lists six scathing declarations on open core: “’Open core’ has NOTHING to do with ‘Open Source’. At this point, nearly every proprietary software product has various degrees of open source-licensed source code in its core.” The statement declares that open core puts the software user at a disadvantage in the same way that all proprietary software does, and calls open core companies that claim the advantages of open source deceitful.

I agree that open core ≠ open source, and that open source software is eating the world. The difference between open core and proprietary software is that open core produces a substantial amount of open source software, whereas solely proprietary software produces none. They both offer open source maintainers a way to get paid for their work, but open core contributes back to open source. Source available carries more advantages to the user than closed source. Most open core companies put a lot of effort into maintaining the core. Therefore, open core is better than proprietary software for all of these reasons. The argument isn’t open core over open source, it’s open core instead of proprietary.

A framework for feature segmentation

The perception of open core as faux open source is perpetuated when companies aren’t transparent about pricing models. While most open core companies will have a statement of intent regarding their relationship to the open source project, they usually don’t disclose how they place features and functionality. When open core companies aren’t explicit about their pricing model, it causes confusion and mistrust.

One of the questions I get asked most frequently about starting a new open core business is, “What features do I make open source, and which should be proprietary?” Yet, Adam Lampitt gave us the framework in 2008: “Some say that this dual license strategy is OK, but as long as you follow the spirit of segmenting by user base, not features.” I call this buyer-based open core and have been using this model to build GitLab since 2015. It’s the model we strongly encourage at OCV.

Buyer-based open core is a framework for determining which features are made to be open source and which are proprietary, based on who cares most about the feature. Features that appeal most to an individual contributor are open source and free. Features that appeal most to management or executives are proprietary and not free. It’s no longer about “Where is that feature technically?” Or “How much more work was it to make?” Or “Where in the repo does it live?” It’s about the end-user.

For example, the merge request feature in GitLab is free and open source, but the merge request approvals function is not. The rationale is that managers are more likely to care about approvals than individual contributors. While it’s not a completely objective framework, it provides a baseline that any company can adopt. It positions the question of open source or proprietary around which type of user gets the most value and begins to negate the bait-and-switch arguments.

Deciding which features to monetize can make or break a business: The worst-case scenario is giving too much away for free, and the business can’t sustain itself. The second-worst-case scenario is to build a company on top of an open source project and never contribute back. This is a balancing act, and companies are bound to get it wrong sometimes. Resist the urge to move features from the open source version into the licensed version. Doing this completely erodes trust. Use feedback from the community and users to refine where you place features as you build.

The buyer-based model provides guard rails for companies so they don’t overcorrect in either direction. It’s a monetization strategy that enables business growth while furthering the open source movement.

Good for business ≠ bad for open source

An open core business that builds on an open source project unlocks resources for the project that it may not get access to otherwise, allowing the project to grow and innovate more quickly. Meanwhile, the busines gets a return on investment in the core project, with the benefits of a community and their contributions that improve the core. Where they make money is by charging users who are also using the project for financial gain.

Founder and CTO of Authentik Security, Jens Langhammer, commented in the announcement about forming the company built on his open source project: “There are many things I wanted to do but couldn’t because I didn’t have the time. I’m excited about the opportunity for people to work full-time on the project. Both the future enterprise and open source versions will benefit.”

While open core may produce proprietary code, it does so alongside a fully operational and maintained open source core. It sustains open source and the contributors who pour their time and effort into creating it.

Our stack starts with Gobii AI, an OCV portfolio company that lets anyone spin up virtual coworkers. Gobii tackles some of our core operational and data processes—no code, workflow mapping, or APIs needed. We simply create AI agents that are onboarded the same way a new remote hire would, by communicating with words. We give them access to the same internal systems and accounts a real employee would use, and teach them the workflows conversationally. If you can explain it in plain language, you can build it.

One hard requirement for anything in our Ops stack is self-hosting capability. We run Gobii on our own infrastructure, which means the data our agents consume and store stays fully within our control.

Portfolio data auditing with Gobii

The first Gobii agent we created automates our portfolio data audit process. While it’s not quite a full operations analyst yet (more like a really good intern), the results have been promising.

Pulse is OCV’s internal VC ecosystem that houses key information on our portfolio (investments, financial metrics, founder teams, etc.), including profiles for each of our portfolio companies. Keeping those profiles up-to-date and complete is critical to our ability to manage operations. Manually auditing our growing list of companies is tedious and time-consuming. So we gave it to a Gobii agent, aptly named Pulsey Jackson.

Before Pulsey could get started, it needed access to Pulse. Instead of using an API or giving it access to an existing user, I created a dedicated login for Pulsey and gave it the only permissions it needed to do its job, just like we would for any new employee.

Once Pulsey was connected, I asked it to log in, review every portfolio company profile, and flag any data fields that appeared incomplete. Pulsey compared each company profile against a fully filled-out model profile that I audited myself. Once it was finished, it sent me a PDF report, which alerted me that the monthly projected burn rate was missing from a significant number of companies, alongside the list of all missing fields and the corresponding profiles they were missing from.

A task that would have taken roughly two hours a week to manually review was handled in a single automated run. Nice job, Pulsey.

As our portfolio continues to grow, this kind of data hygiene would only get harder to maintain without automation. The next step is to train Pulse on the nuances of our portfolio. Ultimately, we expect it to audit, edit, input, and broadly manage the data integrity of Pulse with only the minimal required human oversight. After that, we can integrate more Gobii agents to work with Pulsey to monitor the portfolio, dissect financial information, and expand our dataset.