Per-seat SaaS pricing is under fresh scrutiny after the builder of a new Linear-style issue tracker argued that the infrastructure behind a modern product-management tool can cost dramatically less than its subscription revenue. The underlying math is provocative, but the bigger lesson for founders and buyers is that hosting cost is only one input into what software should cost.

In a recent post on r/SaaS, the founder behind Nonlinear described building a five-person-team alternative with issues, projects, cycles, triage, saved views, documents, inboxes, boards, timelines, GitHub pull-request links, Slack notifications, and keyboard-first workflows. The claim was simple: a small deployment can run for roughly the cost of a few coffees per month, while a much larger base might still be inexpensive relative to what a conventional per-user issue tracker collects.

That claim resonated because nearly every growing team has felt the same tension. The more a collaboration product succeeds inside a company, the more colleagues need access—and the more the bill rises. Yet the software does not necessarily consume proportionally more CPU, database capacity, or bandwidth every time another product manager, engineer, or stakeholder is invited.

Still, the conclusion should not be that every seat-based SaaS product is overpriced. It is that per-seat pricing is primarily a value-capture and go-to-market model, not a transparent pass-through of cloud expenses. Understanding that distinction helps founders choose a business model and helps buyers ask better questions before moving a core workflow into a low-cost or free tool.

The Reddit post that reopened the pricing debate

The original r/SaaS post came from the builder of Nonlinear, an early-stage issue tracker intentionally modeled around the workflow expectations that Linear popularized: fast navigation, structured issue triage, project planning, cycle management, and integrations with engineering tools.

The builder disclosed their personal stake and described a practical experiment. Their small team had been paying a per-user fee for issue tracking, so they wanted to estimate what it would cost to operate a product with comparable broad capabilities after removing the sales and marketing layers associated with established SaaS companies.

Their reported early numbers were approximately:

Around $20 per month for compute and database services while hosting a handful of workspaces on a small server.
Email delivery using a free tier, with authentication codes costing less than a cent each to send.
A rough estimate of $300 to $800 per month for a deployment serving around 1,000 workspaces.
A plan to keep the product free without seat limits or feature tiers at first, and potentially introduce a flat workspace fee if operating costs eventually require it.

The post also acknowledged an important reality often skipped in infrastructure-cost debates: writing core product features was not the hardest part. Email deliverability, security headers, abuse prevention, account protection, and support consumed more thought than the basic application stack—and those responsibilities do not neatly scale by seat count.

That caveat is the most valuable part of the discussion. It turns a simplistic claim—servers are cheap, therefore software should be cheap—into a more useful question: which costs actually rise with users, which rise with customers, and which arise because a product must be dependable enough for real teams?

Why per-seat SaaS pricing persists

Per-seat SaaS pricing has remained common because it is easy to explain, easy to meter, and often aligned with the way customers experience value. A CRM used by 100 sales representatives is usually more valuable than the same CRM used by two. A design tool used across a company becomes more deeply embedded as more contributors can create, review, and approve work.

For vendors, seats also create a familiar expansion path. Land a small team, demonstrate value, then grow alongside the account as adoption broadens. Revenue rises without requiring the company to find an entirely new customer every time it wants to grow.

Pricing is not the same as cost allocation

A common mistake is assuming that a price must map directly to the marginal cloud cost of delivering one more user account. In most SaaS products, that marginal cost is tiny. Adding one more person to a workspace may mean a few more database rows, notifications, API requests, uploaded files, and support interactions. For a well-designed service, it usually does not mean a new server.

But a subscription price has to support much more than incremental compute. It can fund product development, security engineering, infrastructure redundancy, customer success, legal work, finance operations, documentation, integrations, incident response, and the long sales cycles common in larger accounts. It also needs to support the unprofitable experiments and failed features that customers never see.

That does not make every price reasonable. It simply means that comparing a product's annual recurring revenue with a single hosting estimate does not establish a fair price on its own.

Seats are often a proxy for organizational value

A 30-person team using an issue tracker is not merely consuming 30 times the authentication traffic of a solo user. The product may coordinate a more valuable product roadmap, help avoid costly missed handoffs, make work auditable, and reduce time spent deciding what to do next. The buyer may rationally pay for those outcomes even if the vendor's infrastructure cost rises only modestly.

The downside is that proxy pricing breaks down when access is broad but active use is narrow. Executives who occasionally review roadmaps, support teams who check issue status, external contractors, and customer-facing teams may all need visibility. Charging for every viewer can discourage collaboration precisely where collaboration software is supposed to help.

The infrastructure math is directionally useful—but incomplete

The Nonlinear founder's estimate is plausible in one important sense: a lean web application can be remarkably inexpensive to host at an early stage. A compact service with a managed database, object storage, caching, and a transactional email provider can often serve a meaningful number of customers before cloud spend becomes the dominant constraint.

Issue tracking is also not inherently one of the most resource-intensive categories of SaaS. It generally handles structured text, metadata, comments, basic attachments, notifications, search indexes, and integrations. Those workloads can be optimized efficiently compared with products involving real-time video, large-scale analytics, AI inference, high-volume communications, or enormous media files.

What a small-server estimate leaves out

The issue is not that a lean-server calculation is wrong. The issue is what it cannot show. Early costs may not include every piece of a production-grade operating model, especially if the product gains adoption among companies that expect reliability and compliance.

A fuller cost model may include:

Redundancy and recovery: Backups, multi-region planning, monitoring, alerting, disaster-recovery tests, and the ability to restore customer data quickly.
Security operations: Dependency patching, secrets management, audit logging, vulnerability response, penetration testing, access controls, and incident handling.
Integration maintenance: GitHub, Slack, email, calendar, identity, and AI integrations all evolve. Every external API can become a source of breakage.
Data lifecycle costs: Search indexes, attachments, exports, retention policies, deleted-data workflows, and customer requests for data portability.
Support and onboarding: A self-serve product still needs answers when login emails fail, imports are malformed, syncs duplicate records, or a workspace owner leaves.
Abuse and fraud controls: Free products attract bot signups, spam, credential stuffing, excessive API use, and attempts to exploit generous limits.
Business continuity: Insurance, legal review, taxes, payment processing, accounting, and the human capacity needed when something fails at an inconvenient time.

None of these categories proves that a particular $8, $12, or $15 seat price is justified. They do show why comparing a mature vendor's revenue to a founder's first cloud bill creates an incomplete picture.

The meaningful distinction: marginal versus fully loaded cost

For founders, the useful calculation is to separate marginal cost from fully loaded cost. Marginal cost asks what one more active user or workspace costs right now. Fully loaded cost asks what it takes to make the product trustworthy, supportable, and durable over years.

A company can have close-to-zero marginal cost per additional seat while carrying substantial fixed costs. That is exactly why digital products can deliver exceptional gross margins once they reach scale. It is also why startups can underprice themselves when they confuse a low cloud bill with a sustainable business model.

What the community reaction got right

The r/SaaS discussion did not simply applaud the free alternative. Commenters raised several practical objections that are more useful than a generic debate over whether established SaaS companies charge too much.

One common response was that open-source and self-hosted trackers already exist. Tools such as Plane and other mature project-management platforms can offer teams meaningful control, lower vendor dependence, and an alternative to paying a premium per user. That is a fair challenge: building a familiar Linear-like interface is not automatically a reason to create another tracker unless the product has a clear workflow, deployment, or business-model advantage.

Another commenter pointed to the danger of resembling an incumbent too closely through naming, visual design, and branding. In competitive software, copying the interaction patterns users love can be legitimate inspiration, but copying recognizable identity cues is strategically risky. A new product needs an identity that helps users understand the category without making its future dependent on confusion with a better-known company.

The trust problem with free SaaS

The strongest critique concerned durability. A free product may look like an obvious bargain, but an issue tracker contains institutional memory: decisions, project history, customer bugs, engineering context, and roadmaps. If the tool disappears, changes direction, suffers an outage, or introduces pricing after teams become dependent on it, migration can be painful.

This is why buyers do not assess price in isolation. They assess the risk-adjusted cost of adoption. A paid vendor with a track record, clear terms, robust exports, reliable support, and a visible business model may be the lower-risk choice even when its monthly invoice is larger.

For a new free product, the question is not merely, Is it free? It is, Why will it still be available in two years, and how can we leave safely if it is not?

Trust signals that reduce that concern include:

Clear data-export options and documented formats.
Published backup, retention, and deletion practices.
A transparent roadmap and honest statement of current limitations.
An explanation of how the service will be funded if usage grows.
Status reporting and incident communication.
Security documentation appropriate to the customer segment.
A migration path from incumbent tools, including CSV import and integration support.

The founder's own admission that CSV import and mobile support were still missing reinforces the point. An early product can be useful without feature parity, but teams should distinguish between trying it on a new project and moving their entire operational system of record.

Flat per-workspace pricing is compelling, with trade-offs

The alternative proposed in the post is a flat fee per workspace rather than a fee for each person. This model is especially attractive for collaboration tools because it removes the internal debate over who deserves a paid license. Invite the product lead, support manager, contractor, and executive stakeholder without turning every invitation into a budget decision.

It also gives the buyer a more predictable bill. If a company hires rapidly, opens access to additional departments, or includes external collaborators, its issue-tracking spend does not jump unexpectedly just because participation increases.

Where workspace pricing works best

Flat workspace pricing tends to work well when the vendor's costs are driven more by the number of customer environments than the number of people. This may apply to project trackers, internal knowledge bases, lightweight help desks, or developer portals with moderate usage patterns.

The model is particularly strong when network effects matter. If the value of the software grows when more people participate, charging per person can suppress adoption. A workspace fee instead encourages teams to make the tool the shared source of truth.

For example, a 12-person startup may invite every employee into its tracker at no incremental cost. Product, engineering, design, sales, support, and leadership can all see the same priorities. That can make the product stickier—and can make a flat fee economically rational for the vendor even if it looks cheaper on a spreadsheet.

Where it can fail

The commenter who noted that a 30-person company could receive an unusually good deal compared with a solo founder identified the main weakness. A single flat fee can create a large mismatch between customer value, support burden, and payment.

The mismatch becomes greater for organizations with thousands of users, enormous storage needs, intensive API use, enterprise security reviews, advanced permissions, or guaranteed support response times. In those cases, a flat price can effectively subsidize the most demanding customers with revenue from smaller ones.

A better version of workspace pricing often introduces value-based guardrails without reverting to pure seat billing. Possible levers include:

A base workspace subscription with reasonable included usage.
Charges for high-volume automation, storage, or API activity.
Add-ons for enterprise identity, audit logs, advanced permissions, or dedicated support.
Separate pricing for external portals, custom data retention, or private deployment.
A flat team plan with a fair-use policy and negotiated enterprise agreements for unusually large accounts.

This approach preserves the psychological benefit of unlimited internal collaboration while recognizing that not all workspaces place equal demands on a service.

Linear-style issue trackers compete on workflow, not feature checklists

The original post lists a broad set of familiar issue-tracking features. That matters, but feature parity alone is rarely what makes teams choose or keep a tracker. Mature products win because the system feels coherent at the moment work is being planned, discussed, triaged, delegated, and shipped.

Linear's public product positioning and pricing structure reflect that it competes as more than a database of tickets. Its product is designed around a disciplined operating cadence for product and engineering teams, including cycles, projects, roadmaps, triage, and integrations. Any emerging alternative needs to match not just screens but the behaviors those screens make easier.

The hard parts users notice later

A tracker can look convincing in a demo yet fail in daily use if it handles the following poorly:

Keyboard navigation and speed under heavy use.
Flexible but understandable permissions.
Search quality across issues, projects, and documents.
Reliable notifications that inform without overwhelming.
GitHub and Slack synchronization without duplicate or stale updates.
Historical integrity when projects, teams, labels, or workflows change.
Reporting that is useful without encouraging performative ticket management.
Data migration that preserves links, authors, statuses, comments, and dates.

This is why the statement that the software was easy should be interpreted carefully. It may be true that a skilled builder can create a highly capable first version quickly. The difficult work is maintaining behavioral quality as teams introduce edge cases, integrations multiply, and data becomes too important to lose.

The AI-agent angle could change what teams expect

One commenter suggested adding a Model Context Protocol, or MCP, integration because their team uses Linear as an operational memory layer for Claude. That observation points to a broader shift: issue trackers are becoming structured context sources for AI agents, not only planning interfaces for humans.

A well-integrated agent can search for related bugs, summarize project history, identify unfinished work, draft issue descriptions, connect pull requests to requirements, or answer questions about a team's current priorities. The data model behind an issue tracker—owners, statuses, labels, dependencies, initiatives, and discussion history—is unusually useful for this kind of automation.

More access creates more governance needs

The opportunity comes with risks. Connecting AI systems to internal work data raises questions about authorization, data scope, retention, prompt injection, audit trails, and whether an agent should be allowed to write back into a team's tracker.

For a new issue-tracking product, MCP support or another agent-facing API should not be a marketing checkbox. It should include granular permissions, clear read-versus-write boundaries, logs of agent activity, secure token management, and controls that respect workspace membership.

This is also another reason pricing cannot be evaluated from server cost alone. AI-enabled workflows may increase API demand, create new support expectations, and require stronger observability. A vendor that becomes a trusted context layer for agents takes on more responsibility than one that merely stores tickets.

A practical buying framework for small teams

For small teams evaluating a free, flat-fee, or per-seat issue tracker, the best decision is not always the cheapest plan. The right choice depends on the maturity of the product, the importance of your data, the cost of migration, and whether the tool improves the way your team actually works.

Before moving active projects, use a structured pilot. Create a representative project, import or recreate a limited set of issues, connect only the integrations you can test safely, and include users from product, engineering, and any team that needs visibility.

Ask these questions during the pilot:

Can we export all critical data in a usable format without vendor help?
Does the product support the way we plan work, or are we adapting our process to fit its limitations?
Are notifications and integrations reliable enough to become part of our daily routine?
What happens if the vendor changes pricing, pauses development, or shuts down?
Who can access sensitive issues, and can those permissions be audited?
Does the tool offer the support, uptime expectations, and compliance posture our customers require?
Will broader access improve collaboration enough to justify a flat-workspace model?

For authentication-heavy SaaS products, another small but meaningful operational detail is email reliability. Magic links and one-time login codes are inexpensive to send, but expensive in user frustration when they land in spam or arrive late. Teams building this type of product should treat sending reputation, domain configuration, and address hygiene as core infrastructure; a free address verification tool can help reduce avoidable delivery failures before transactional messages are sent.

A practical pricing framework for SaaS founders

Founders should take the Nonlinear post as a useful challenge: do not hide behind infrastructure costs when your real pricing logic is value, expansion, and market convention. Customers are generally sophisticated enough to understand that a seat price is not a direct measurement of database usage.

The stronger approach is to be explicit about what your model is designed to accomplish. If you charge per seat, explain why broad adoption creates more value and how you avoid punishing read-only collaborators. If you charge per workspace, define reasonable usage boundaries and identify the enterprise features that carry higher support or security costs.

Start from a unit model, then test willingness to pay

A durable pricing model should combine four views:

Cost to serve: Infrastructure, support, payment fees, third-party services, and operational overhead.
Value to the customer: Time saved, risk reduced, revenue enabled, collaboration improved, or complexity removed.
Competitive alternatives: Incumbents, open-source software, self-hosting, spreadsheets, and the cost of doing nothing.
Expansion behavior: Whether usage naturally grows through seats, workspaces, transaction volume, data volume, or premium capabilities.

Do not assume a free product can always add pricing later without consequences. Free users may be price-sensitive, but they can also generate meaningful support, moderation, and reliability obligations. A free tier works best when it has a deliberate acquisition purpose, a low support burden, a clear upgrade path, or a strategic reason to maximize adoption.

Equally, do not assume a per-seat model is inevitable because competitors use one. If your product gets more valuable when everyone participates, charging for every participant may limit the very behavior that makes customers successful. A workspace model, usage-based model, or hybrid could produce better adoption and stronger retention.

The larger lesson: low hosting cost is a competitive opening

The most interesting takeaway from this discussion is not that incumbents are necessarily overcharging. It is that cloud infrastructure and modern development tools have lowered the cost of launching credible vertical SaaS alternatives.

A focused team can now build polished software, integrate with widely used platforms, deploy globally, and operate a functional product without the capital once required for enterprise-grade web applications. That creates room for pricing innovation, especially in categories where customers are tired of seat-count friction.

But the same forces that make entry easier also make trust harder to earn. Buyers have more options, more migration anxiety, and more reason to ask whether a new product will survive. The winning alternative will not be the one that merely says its servers are cheap. It will be the one that combines a better workflow, sensible economics, credible durability, and a clear answer to what happens as customers grow.

For buyers, per-seat SaaS pricing deserves scrutiny—but not cynicism. Compare price against value, switching cost, data portability, reliability, and support. For founders, the opportunity is to replace inherited pricing habits with a model that encourages the customer behavior your product needs most.

FAQ

Is per-seat SaaS pricing based on actual hosting costs?

Usually not directly. Hosting and database costs may rise somewhat as more people use a product, but per-seat pricing more often reflects customer value, sales strategy, account expansion, support needs, and market convention than the marginal infrastructure cost of one extra user.

Is flat per-workspace pricing better than per-seat pricing?

It can be better for collaborative tools because it encourages teams to invite everyone who needs access. However, a pure flat fee can undercharge very large or demanding customers, so many sustainable models combine workspace pricing with usage limits, enterprise add-ons, or negotiated plans.

Are free issue trackers safe for a startup to use?

They can be, especially for low-risk projects or pilots, but teams should evaluate data export, backups, security, business sustainability, integrations, and support. The real risk is not only downtime; it is becoming dependent on a product with no clear long-term operating model.

What should a Linear alternative offer before a team migrates?

At minimum, assess issue and project workflows, imports and exports, search, permissions, GitHub and Slack integrations, notification reliability, performance, and support. A polished interface matters, but migration quality and operational trust matter more once the tracker becomes a source of truth.

Can AI agents use issue trackers as company memory?

Yes. Issue trackers contain structured knowledge about plans, bugs, decisions, owners, and development status. Agent integrations can be valuable, but they should use strong permissions, auditable actions, secure credentials, and careful controls over whether an AI system can modify work records.

Per-Seat SaaS Pricing: What Issue Trackers Really Cost