What are the design rules for free tier seat limits, feature gates, and API quotas that trigger expansion motions in 2027?

A RevOps team watching a free tier quietly fail

Picture a Series A company selling a workspace tool. Signups look excellent: 4,000 free accounts a month, a growth chart that makes the board happy, a founder who tells everyone the product "sells itself." Then the RevOps lead pulls the cohort report and the picture inverts. Free-to-paid conversion sits under one percent. Support load scales linearly with the free base. And the accounts that do convert almost all converted in week one — meaning the free tier is not producing conversions over time, it is passively collecting the small number of people who arrived already intending to buy.

The instinct in that room is almost always to change the price or add a discount. Both are wrong, because neither touches the actual defect. The defect is where the limits sit. This company gave away 25 free seats and unlimited storage, gating only two obscure admin features nobody had ever asked for. A forty-person department could run its entire operating rhythm inside the free tier forever and never encounter a reason to open a purchase order. The free tier was not a funnel; it was the product, shipped at a price of zero, with a paid SKU sitting beside it that solved a problem no existing user had.

Now flip the failure. A second company, same stage, different mistake: three free seats, a hard wall at the fourth, no viewer tier, and a paid plan with a ten-seat minimum. Their conversion rate looks respectable in isolation, but their expansion motions are dead. Every champion who tries to bring a teammate in gets stopped cold, and the ask they have to carry upstairs is not "approve one more seat" — it is "approve ten seats we don't need yet." Some fraction of those champions go get budget. Most quietly stop inviting people, and the account freezes at three users, permanently, with a competitor one search away.

Both companies made the same category error. They treated the free tier as a marketing decision — how generous should we look? — rather than as revenue infrastructure. The correct frame is that a free tier is a manufacturing line whose output is qualified expansion demand. Its yield metric is not signups. It is the number of accounts per month that reach a limit while already dependent on the product, and step through that limit under their own power. A free tier judged by signups is a vanity machine. A free tier judged by qualified demand produced is a revenue machine, and the limits are the machinery.

That reframe changes who owns the decision. Free-tier limits are usually set once by a founder or a product manager in a packaging meeting and then never revisited, because no function feels ownership. In practice the owner should be whoever owns expansion revenue — typically RevOps in partnership with product and finance. RevOps is the only function that sees the full loop: signup cohorts, limit-hit telemetry, conversion rates by gate, cost-to-serve per free account, and the downstream expansion ARR that results. Product sees usage. Finance sees margin. Sales sees the accounts that raised a hand. Only RevOps sees all four at once, which is why limit design that lives outside RevOps tends to drift from the economics it is supposed to serve.

There is a diagnostic worth running before any limit is touched. Take your free accounts and rank them by behavioral intensity: weekly active users per account, number of distinct workflows touched, presence of multiple people from the same email domain, and recency of use. Then look at the top decile. If that top decile contains a healthy population of accounts that look, by every behavioral measure, exactly like paying customers — heavy daily use, five or six colleagues, mission-critical workflows — and they have never converted, you are not running a funnel. You are cannibalizing. Those accounts are the visible edge of revenue you would otherwise have earned, and they exist because the free ceiling was set above what a typical paying customer actually needs.

How the mechanism actually works

Every durable freemium model gates one or more of three axes, and each monetizes a different kind of growth. Seats monetize team and org adoption. Feature depth monetizes workflow sophistication. Usage and API quotas monetize scale and integration. The strategic question is never "which lever is best" — it is "which axis does my product's value scale along?" Gating the wrong axis puts a toll booth on a road nobody wants to drive down.

The diagnostic is blunt: what does a happy customer do more of as they get more value from you? If the answer is "invite more people," seats are the axis. If it is "do more sophisticated things," features are the axis. If it is "push more volume through," usage is the axis. The honest answer is sometimes uncomfortable. Founders often want to gate seats because per-seat revenue forecasts cleanly and investors understand it, even when the product's value plainly scales with volume. Picking the lever you wish were true rather than the one your value curve follows produces a free tier that fights its own product.

Once the axis is chosen, the mechanism itself is a sequence, not a wall. A user signs up, reaches an aha moment, builds a workflow that depends on the product, and only then approaches a limit. Every one of those steps has to happen in order. A limit that bites before dependency forms is not a trigger — it is a churn event wearing a trigger's costume. This is why time-to-limit is a leading indicator that deserves more attention than it usually gets: if your accounts hit the gate before they hit value, the fix is almost never to move the gate. The fix is to accelerate onboarding so value lands first.

The closure of that loop is the whole point. A non-conversion at a limit is not a dead end, it is data with two possible readings: the limit bit too early, or onboarding failed to deliver value in time. Both are fixable, and both feed straight back into the next quarter's limit settings. Teams that run this loop deliberately watch their free tier converge toward its right configuration. Teams that don't are defending a guess someone made in a conference room two years ago.

The seat mechanism has a specific shape worth spelling out. The rule is: a single individual should extract full personal value for free; the paywall appears exactly when collaboration starts to matter. That is why so many strong free tiers allow unlimited solo use or a small team of one to five. The product proves itself completely to one person, that person becomes an internal champion, and the limit converts when the champion tries to bring colleagues in. At that moment an employee of the prospect — someone who already trusts the product — is advocating for the purchase in meetings you will never attend. There is no more efficient sales motion in software, and it exists only because the limit was placed after the champion was created rather than before.

A refinement that widens the mechanism considerably: charge for creation, not consumption. Split seats into editors who pay, commenters who are free or steeply discounted, and viewers who are free. This lets the account spread without the price spiking, which keeps the expansion conversation friendly, and it raises switching costs dramatically. Once two hundred viewers across an org depend on documents that twenty editors maintain, removing the tool stops being a procurement decision and becomes a political project. A vendor charging for every set of eyeballs caps its own footprint at the number of people someone is willing to make a line item. Viewers are also a recruiting pool — a commenter who keeps trying to take edit actions is one role change from needing a paid seat, and instrumenting that intent surfaces expansion demand inside an already-paying account.

Feature gates run on a different mechanism, governed by what is best described as the fence-post principle. Free features must form a complete, coherent workflow — a user can finish a real job — while paid features deepen, automate, or scale that same workflow. The free path cannot have a hole in the middle of it. The practical test: write the user's first real job as a numbered sequence of steps. If a gated feature falls inside that sequence rather than at the end of it, the gate is mis-placed. The gate belongs at step N+1 — the first thing a user wants after succeeding, not step four of a seven-step task. Free should feel like a finished room. Paid should feel like a second floor.

Usage quotas convert on a psychology unlike either of the others. Seats and features are binary: I can or cannot do X. Usage is continuous: I am running out of X. That continuity is a gift to the designer, because it produces a gradient of urgency you can instrument precisely, warn against early, and convert against gently. It also changes the cadence of expansion. A seat-gated product expands in discrete jumps — five people, then nothing for six months, then ten more. A usage-gated product expands continuously and often invisibly as the customer's own business grows, with no renewal conversation required. That is the structural appeal, and also the structural risk, because automatic expansion becomes automatic bill shock the moment transparency slips.

Real numbers, ranges, and benchmarks

The 80% rule is the most-cited heuristic here and the most frequently misread. It does not mean "give away 80% of your features." It means: for the smallest coherent use case your product serves, the free tier should deliver roughly 80% of that use case's value and then stop. The remaining 20% — and crucially, the entire value of larger use cases — sits paid.

Why 80 and not 50 or 95? At 50%, the product never proves itself, no habit forms, and there is nothing to expand from. At 95%, dependency forms beautifully and no paywall moment ever arrives, because the user already has everything. Eighty is the durable middle where the user reaches genuine value and habit and simultaneously feels a specific, nameable thing they cannot do. The craft is choosing which 20% to withhold so the missing piece is both visible and wanted, not an obscure capability nobody notices is absent.

Seat numbers cluster in a narrow band for a reason. Free tiers that work tend to allow unlimited solo use or a small team of roughly three to five, because that is the size at which collaboration starts to matter and the champion's internal case becomes concrete. Paid tiers should permit adding seats one at a time at the standard rate with no artificial minimum. That last detail is worth more than it sounds: a five-seat free tier paired with a ten-seat paid minimum turns a fifteen-dollar decision into a fifteen-hundred-dollar decision and hands the champion an awkward conversation they did not sign up for. The expansion increment must match the felt need.

Conversion benchmarks give you a sanity check rather than a target. Free-to-paid conversion in the low single digits — roughly two to four percent — is a commonly cited PLG band, though it varies enormously by category and by how the free tier is scoped. The important arithmetic is what that implies: if 96 to 98 percent of your users never pay and each one carries real cost-to-serve in support tickets, infrastructure, and occasional security review, freemium only works at scale, with low marginal cost per free user, and with organic or viral acquisition holding CAC near zero. A high-touch product with expensive per-user infrastructure and a small addressable market can be bankrupted by its own free tier while the signup chart points cheerfully upward.

For usage quotas, the graduated response beats a cliff at every threshold. A workable ladder: an early warning at 70 to 80 percent of quota delivered in-product and by email with a one-click upgrade path; an escalated alert at 90 to 95 percent, with sales-assist engaged for large accounts; a soft cap at 100 percent that throttles rather than stops, or grants a grace overage; and beyond grace, transparent overage billing or a required upgrade. The rule that must never break for a production API: your quota does not silently take down the customer's running system. A throttle that slows responses is recoverable and forgivable. A hard rejection that kills the customer's checkout flow is neither, and that customer does not upgrade — they rage-churn and write about it.

The PQL signal hierarchy is where the numbers get operationally useful. Limit proximity outperforms generic engagement as a predictor, because it is intent expressed as behavior rather than inferred from activity. An account at 80 to 90 percent of any hard limit is a very strong signal warranting an in-product nudge plus a sales-assist alert. Hitting a feature gate three or more times is a strong signal calling for a contextual CTA at the gate itself. An account that has filled its free seats and is trying to invite more is among the strongest signals available — offer a team trial, and route to a human above roughly twenty seats. API usage growing more than twenty percent week over week warrants proactive outreach before the customer discovers the trajectory on an invoice. Multiple users from the same email domain is a moderate signal that should trigger an account-level rollup and a team-expansion play.

That sales-assist threshold deserves a number of its own. Somewhere in the range of twenty to fifty paid seats, a human — sales-assist or a CSM — starts producing better expansion economics than letting the account self-upgrade one seat at a time. Below that band, the fully loaded cost of the human exceeds the marginal revenue. Above it, a human negotiates an annual commit, an org-wide rollout, and a multi-team land-and-expand that self-serve motions never surface. Getting the threshold wrong is expensive in both directions: humans inserted too early burn capacity on accounts that would have self-served at higher margin, and inserted too late leave large accounts stalled against a self-serve ceiling they would gladly have blown past with a guide.

Testing windows have their own arithmetic. Read a limit change over 60 to 90 days minimum, on new-cohort signups only, with limit-hit-to-conversion as the success metric rather than signups. Two weeks measures signup behavior, which is not the thing you changed. Expansion plays out on the rhythm of a team adopting software, which is weeks to months. And never reduce a limit on existing free users — a takeaway generates churn and anger wildly out of proportion to its economic value, and the reputational cost outlasts the experiment by years.

Five metrics govern limit health, and they must be read in pairs rather than alone. Limit-hit rate tells you whether the gate creates any pressure at all. Limit-hit-to-conversion is the core yield number. Time-to-limit tells you whether the gate arrives before or after value. Limit-hit-to-churn tells you whether the gate reads as punitive. Free-tier gross margin tells you whether the whole apparatus is solvent. The diagnostic pairing that matters most: a low limit-hit rate means the limit is too generous and accounts never feel pressure; a high limit-hit rate paired with high churn means the limit is punitive and bites before value lands. The target is a high limit-hit rate paired with a high conversion rate — accounts reliably reach the gate and reliably step through it.

Trade-offs, alternatives, and the expansion ladder

The most sophisticated designs do not deploy a single limit. They sequence several into a ladder where clearing one reveals the next, and each step is a natural expansion motion rather than a wall. The user is never stuck; they are always one visible step from more value.

A four-rung ladder in a collaboration product might run: free with unlimited solo use, a complete core workflow, roughly five collaborators, and modest storage — enough that one user gets complete value and the product proves itself. Then a per-seat tier triggered by the seat gate when the team outgrows five, adding unlimited collaborators, unlimited uploads, version history. Then a business tier triggered by the admin gate when IT and security get involved, adding SSO, advanced permissions, private team spaces, bulk export. Then enterprise, triggered by the governance gate when procurement and compliance arrive, adding audit logs, provisioning, dedicated success, and an SLA.

Each rung is gated by a different axis, so the account climbs as it matures rather than slamming into one wall. That is the structural reason multi-axis models outperform single-lever ones: a single-lever model has exactly one conversion event per account, while a well-built ladder has three or four — each smaller, each better-timed, each owned by a different buyer inside the customer.

The same logic transfers cleanly to developer infrastructure with different axes. A hobby tier with generous build minutes and bandwidth lets an individual engineer prove the platform on real if small work. A pro tier raises those quotas and adds team collaboration, triggered when the side project becomes a production app. Enterprise adds SLAs, SAML, audit logs, and custom quotas, triggered when the app is business-critical. Notice the axis shifts as the account climbs: usage-gated early, governance-gated late, because what the customer needs changes as they mature from one engineer to a production-critical organization.

Price spacing on the ladder is where teams reliably slip. The rungs should be spaced to match the value jumps, not to look tidy on a pricing page. The step from free to the first paid tier is often a small absolute gain in value — a couple of power features — and should therefore be cheap and frictionless enough to clear on a personal card without approval. The step from mid-tier to enterprise is a large jump in value, involving governance, SLAs, and dedicated support, and can carry a correspondingly large price step because a procurement-led buyer is now weighing it against a budget line. Compressing those two very different transitions into the same increment makes the first rung needlessly expensive and the last rung needlessly cheap.

A second ladder discipline: every rung must be reachable from the one below without a rip-and-replace. If moving from pro to business requires re-importing data, retraining the team, or reconfiguring integrations, that is not a step — it is a cliff with a competitor at the bottom. The point of a ladder is that the customer climbs it inside the same product, carrying data, habits, and configuration upward.

The largest trade-off sits one level above all of this: whether freemium is the right instrument at all. A time-boxed free trial delivers the same value demonstration without an indefinite cost tail, and for many profiles it is simply the better tool. The deciding variable is time-to-value. If your product's genuine aha moment takes longer than a trial window — common in data products, complex platforms, and anything that needs accumulated history before it shines — the trial expires before value lands and converts terribly. A free tier removes the clock, which is exactly what a slow-to-value product needs. Conversely, a product whose value is obvious within a day pays an indefinite cost tail for nothing when a trial would have done the same job.

Large addressable market with low marginal cost favors freemium. Small market with a high-touch product favors a trial. A strong viral or collaboration loop favors freemium, because a trial's expiry cuts the spread short. A complex enterprise sale can use either: a free tier as a PQL feeder underneath a sales motion, or a trial as a mid-cycle accelerant. The counter-case is not that freemium is bad — it is that freemium is a specific instrument for a specific market-and-margin profile, and deploying it outside that profile is an unforced error.

Usage-based models carry a trade-off of their own that seat models do not. Under per-seat pricing, spend is a decision the customer makes deliberately. Under usage pricing, spend is an emergent property of the customer's own product behavior, which they may not fully control. That loss of control — not the dollar amount — is the real source of bill-shock anxiety. The countermeasures work because they hand control back: real-time usage dashboards, configurable spend alerts, hard customer-controlled caps, and forecasted-bill estimates. A usage-based vendor with weak billing transparency has effectively capped its own growth, because every customer eventually installs a defensive ceiling out of fear and never removes it.

The mature answer to that tension is the committed-use discount layered over pay-as-you-go: a customer whose volume has stabilized commits annually in exchange for a lower unit rate, converting an anxiety-inducing variable bill into a budgetable fixed line. It is the cloud-infrastructure playbook applied at the application layer, and it functions as a fourth rung that pure usage models grow naturally. Treat the commitment conversation as an expansion motion in its own right — it is the moment a human can right-size a customer to their actual trajectory rather than their current snapshot, and a customer who has committed to a year of volume has also raised their own switching cost.

Common pitfalls and how to avoid them

Gating the solo user is the first and worst. If the free tier is too crippled for one person to succeed at a real task, no champion is ever created, and there is nothing for an expansion motion to act on later. Every other design decision downstream assumes a champion exists. Avoid it by defining the smallest complete job one person can finish and guaranteeing the free tier covers it end to end.

The hard wall is the most insidious pitfall because it looks like discipline. When a champion has rallied a team and hits an instant "no," the emotional charge of that moment is negative — frustration rather than desire. A soft limit at the identical seat number ("you've added your sixth teammate — start a fourteen-day team trial or upgrade now") converts the same moment into momentum, because the collaboration is already happening and you are merely formalizing it. The swing in conversion between a hard wall and a soft limit at the same number can be substantial, and the mechanism is entirely emotional: one version punishes the user for succeeding, the other rewards them.

Mid-workflow gating kills habits silently. A user who can start but not finish a real job leaves with a memory of friction and no memory of value, and they never appear in your churn analysis as anything but an inactive signup. Run the numbered-steps test on every gate before it ships.

Gating table-stakes capability reads as hostage-taking, not premium. Charging for basic data export, basic search, or basic access to a customer's own data produces angry public reviews, poisons word of mouth, and attracts exactly the kind of journalistic and regulatory attention no vendor wants. Whatever sits behind the gate must represent genuinely more value, never the removal of artificial pain you introduced.

Feature-gate sprawl defeats buyers before sales ever engages. Forty individually gated capabilities spread across four tiers means nobody can reason about which tier they need, and decision paralysis defaults to staying free. The related failure is tier blur, where tiers differ in ways nobody can articulate. The tell is simple: ask your sellers to state, off the top of their heads, the one-sentence reason a customer moves from pro to business. If they cannot, buyers certainly cannot, and buyers who cannot articulate a boundary stay put.

Gating the wrong buyer is a subtler packaging error with the same result. Power features convert the individual power user who has outgrown doing things manually. Admin and governance features — SSO, audit logs, roles, provisioning — convert the IT and security organization. Scale features convert the operations owner who cannot risk a critical workflow breaking under load. A tier that mixes all three has no single internal owner and stalls in committee. One buyer per tier means one champion per tier. This also explains the sequencing: power features belong at the earliest paid tier because the same person who fell in love with the free product wants them, while governance features belong at later tiers because they require the champion to go recruit a buyer further from the product's entry point. Putting SSO behind the cheapest paid tier asks a security organization to care about a small decision, and security organizations do not engage at that altitude.

Metering a proxy metric instead of the value metric breeds resentment that compounds over time. If customers think in monitored hosts, meter hosts and not log lines. If they think in messages sent, meter messages and not API calls. The test: imagine the customer's CFO reading the invoice. If the line item connects to the business's own activity, the metric is right. If only an engineer could explain it, the metric is a proxy and proxies generate disputes, and disputes generate spend caps.

Setting a free quota below your variable cost-to-serve turns the free tier into a subsidy with a leak, where scale multiplies losses rather than funnel. The trap is that freemium feels free to offer — signups climb visibly while cost accumulates quietly in support load and infrastructure where no growth dashboard displays it. The fix is procedural: put free-tier cost-to-serve on the same dashboard as free-tier signups so the two numbers are always read together.

Shipping a limit without instrumentation is the pitfall that makes all the others unfixable. A limit set once and never measured is a guess that calcifies into doctrine. Every limit should emit four events from the day it ships — approached, hit, hit-then-converted, hit-then-churned — because the first cohort hitting the first version of a limit is the most valuable data you will ever collect and it cannot be recovered retroactively.

One refinement most teams miss: the limit-proximity signal has two distinct flavors that warrant opposite responses. A trajectory signal — usage climbing steadily toward a limit over weeks — indicates an account maturing on schedule, and the right response is a calm, well-timed nudge as it nears the gate. A collision signal — an account slamming into a limit within days of signup — means something else entirely: either the limit is set far too low, or this account has needs the free tier was never scoped for. The collision account often wants a human right now; the trajectory account wants to be left alone until it is ready. A mature system reads the shape of the approach, not just the proximity number. A wave of collision signals across many accounts is the clearest evidence a limit needs to move; trajectory signals are evidence it is working.

Finally, watch for dilution. A vast free base pulls support, community, and roadmap attention toward people who will never pay, and the loudest voice in a community forum is often a free user with strong opinions and no commercial stake. A roadmap steered by that voice drifts from what paying customers need. There is a brand version of the same risk: a product known as "the free thing our interns use" is a harder room in procurement than one encountered fresh. Some deliberately enterprise-first companies skip freemium entirely for this reason, preferring a smaller, higher-intent funnel to a large noisy one.

Related questions

How often should free tier limits be re-audited?

Quarterly. Read limit-hit rate and limit-hit-to-conversion together for each gate, plus free-tier gross margin. Changes ship to new cohorts only and are read over 60 to 90 days. Never reduce a limit on existing users.

Who should own free tier limit design?

Whoever owns expansion revenue — typically RevOps, partnered with product and finance. RevOps is the only function seeing signup cohorts, limit telemetry, conversion by gate, cost-to-serve, and downstream expansion ARR simultaneously. Limit design outside RevOps drifts from its economics.

Should a free tier gate all three axes at launch?

No. Pick the single axis most tightly coupled to your value curve, instrument it, and understand it before adding a second. Gating three axes from launch makes poor conversion undiagnosable — you cannot tell which gate caused it.

What is a reverse trial and when does it help?

New users get full paid access for a fixed window, then downgrade to a permanently free tier rather than losing everything. Loss aversion converts harder than aspiration. Make the downgrade graceful — the workflow still works, just less automated — so habit survives.

How do you detect free tier cannibalization?

Rank free accounts by behavioral intensity and inspect the top decile. Accounts with heavy daily use, multiple colleagues, and mission-critical workflows that never convert are cannibalization made visible. Your free ceiling sits above what a typical paying customer needs.

FAQ

What is the main job of a free tier?

To manufacture qualified expansion demand, not to look generous. Every seat limit, feature gate, and quota is a hypothesis about where a user crosses from evaluating to depending. Judge the tier by how many dependent accounts reach a gate and step through it each month, not by signup volume.

Where exactly should the free ceiling sit?

At roughly 80% of the value of the smallest complete use case your product serves. Below about half, no habit forms and there is nothing to expand from. Near 95%, dependency forms but no paywall moment ever arrives. Choose the withheld 20% so the missing capability is both visible and genuinely wanted.

Why do soft limits outperform hard walls?

Because the emotional charge at the moment of contact determines the outcome. A hard "no" makes a champion feel punished for succeeding. A throttle, grace overage, or team-trial offer at the identical threshold makes them feel rewarded for it, and the collaboration they started keeps running while they sort out payment.

What is the strongest product-qualified lead signal?

Limit proximity — an account at 80 to 90 percent of any hard limit, bouncing off a feature gate repeatedly, or trying to invite past its free seat count. It outperforms logins and feature breadth because it is intent expressed as behavior rather than engagement inferred from activity.

How do you prevent bill shock under usage-based pricing?

Hand control back to the customer: real-time consumption dashboards, configurable spend alerts, customer-set hard caps, and forecasted-bill estimates. The anxiety comes from spend being an emergent property of their own systems rather than a deliberate decision. Committed-use discounts convert a variable bill into a budgetable line.

When is a free trial the better instrument?

When your addressable market is small, cost-to-serve per user is high, or value is obvious within days. A trial delivers the same demonstration without an indefinite cost tail. Freemium wins when value takes months to accumulate, marginal cost is near zero, or a collaboration loop drives organic spread.

Sources

• https://hbr.org/2014/05/making-freemium-work — Harvard Business Review on freemium model design and conversion economics
• https://www.productled.org/foundations/what-is-product-led-growth — Product-Led Growth foundations, including free-tier and PQL frameworks
• https://openviewpartners.com/blog/product-qualified-leads/ — OpenView on product-qualified leads and usage-based expansion signals
• https://docs.stripe.com/rate-limits — Stripe documentation on API rate limiting and throttling behavior
• https://aws.amazon.com/free/ — AWS Free Tier structure, service quotas, and usage limits
• https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html — AWS service quota documentation and limit-increase workflow
• https://sso.tax/ — The SSO Tax, documenting how vendors gate single sign-on across pricing tiers
• https://a16z.com/the-new-business-of-ai-and-how-its-different-from-traditional-software/ — a16z on gross margin and cost-to-serve pressures in software business models
• https://cloud.google.com/docs/quotas — Google Cloud documentation on quotas, limits, and increase requests

Related on PULSE

• What are the economics behind freemium conversion rates in B2B SaaS?
• How should freemium pricing strategy be structured for a new product?
• When does a product-led growth motion need a sales overlay?
• How many pricing tiers should a SaaS company run?
• How do you model CAC payback under usage-based pricing?
• Why did HubSpot keep its free CRM instead of killing it?