Project-Based Pricing

Master this essential documentation concept

Quick Definition

A pricing model where costs are determined by the number of projects, documentation sites, or instances rather than the number of users.

How Project-Based Pricing Works

graph TD A[Organization Subscription] --> B{Pricing Tier} B --> C[Starter: 3 Projects] B --> D[Professional: 10 Projects] B --> E[Enterprise: Unlimited Projects] C --> F[Project 1: Product Docs] D --> F D --> G[Project 2: API Reference] D --> H[Project 3: Help Center] E --> F E --> G E --> H E --> I[Project N: Client Portal] F --> J[Unlimited Contributors] G --> J H --> J I --> J J --> K[Writers] J --> L[Reviewers] J --> M[SMEs] J --> N[Stakeholders] style A fill:#4A90D9,color:#fff style B fill:#F5A623,color:#fff style J fill:#7ED321,color:#fff

Understanding Project-Based Pricing

Project-Based Pricing is a licensing and billing approach used by documentation platforms and tools where the cost structure is tied to the number of distinct projects, documentation sites, or instances rather than the number of individual users accessing the system. This model has gained significant traction among documentation teams because it aligns costs with the scope of documentation work rather than team headcount.

Key Features

  • Costs scale with the number of documentation projects or sites, not user accounts
  • Unlimited or large numbers of contributors can collaborate within a single project without additional charges
  • Clear pricing boundaries based on deliverables rather than access levels
  • Often includes project-level permissions, versioning, and publishing controls
  • Supports multiple documentation portals or knowledge bases under a single subscription tier

Benefits for Documentation Teams

  • Predictable budgeting since costs are tied to project scope rather than team growth
  • Encourages broader collaboration by removing barriers to adding reviewers, subject matter experts, and stakeholders
  • Simplifies procurement and vendor negotiations by focusing on output rather than headcount
  • Scales efficiently for agencies or consultancies managing multiple client documentation sites
  • Reduces administrative overhead associated with managing individual user licenses

Common Misconceptions

  • Project-Based Pricing does not always mean unlimited projects — tiers typically cap the number of active projects or sites
  • It is not inherently cheaper than per-user pricing; cost-effectiveness depends on team size and project volume
  • A single project does not always equate to a single document — it often represents an entire documentation portal or product line
  • This model does not eliminate the need for role-based access controls within projects

Real-World Documentation Use Cases

Software Agency Managing Multiple Client Documentation Portals

Problem

A documentation agency handles technical writing for 8 different software clients, each requiring a separate branded documentation portal. Per-user pricing becomes prohibitively expensive when each client project involves 5-10 internal writers plus client-side reviewers.

Solution

Adopt a Project-Based Pricing plan that allows the agency to create one documentation site per client without paying for each individual contributor across all projects.

Implementation

1. Audit all active client projects and estimate future project growth over 12 months. 2. Select a pricing tier that accommodates current projects plus 20% buffer. 3. Onboard all writers, editors, and client reviewers into their respective projects without license concerns. 4. Set project-level permissions so each client only accesses their own documentation. 5. Report cost savings to management by comparing old per-user costs versus new project-based costs.

Expected Outcome

The agency reduces licensing costs by 40-60%, can onboard client reviewers freely, and presents cleaner project-based invoicing to clients.

Enterprise with Product-Specific Documentation Silos

Problem

A large software company has 6 distinct product lines, each with its own documentation team of 15-20 writers. Per-user pricing across all teams costs over $50,000 annually, and adding seasonal contractors spikes costs unpredictably.

Solution

Switch to Project-Based Pricing where each product line is treated as a separate project or documentation instance, allowing unlimited contributors per project.

Implementation

1. Map each product line to a dedicated documentation project within the platform. 2. Negotiate an enterprise tier covering all 6 product projects. 3. Define project ownership and admin roles for each product documentation lead. 4. Onboard contractors directly into specific projects without purchasing new seats. 5. Review quarterly whether project count aligns with active product lines.

Expected Outcome

Predictable annual documentation costs, seamless contractor onboarding, and clear project ownership across all product lines.

Open Source Project Maintaining Public and Internal Docs

Problem

An open source foundation maintains a public-facing documentation site for community users and a separate internal wiki for contributors and maintainers. They need to involve hundreds of community contributors without paying per-user fees.

Solution

Use Project-Based Pricing to create two separate documentation projects — one public, one internal — while allowing unlimited community contributors to submit and review content.

Implementation

1. Identify the two distinct documentation audiences: public users and internal contributors. 2. Create two separate projects within the platform under a single project-based subscription. 3. Configure public project with open contribution settings and review workflows. 4. Restrict internal project to verified maintainers using role-based access. 5. Establish a content review pipeline that moves approved community contributions from draft to published.

Expected Outcome

Hundreds of community contributors participate without licensing costs, and the foundation maintains clear separation between public and internal documentation.

SaaS Startup Scaling Documentation Across Product Versions

Problem

A growing SaaS startup releases major product versions every quarter, requiring versioned documentation sets for v1, v2, and v3. Treating each version as a separate project under per-user pricing triples their documentation tool costs.

Solution

Implement Project-Based Pricing where each major version or documentation site counts as one project, enabling the team to maintain multiple versioned documentation portals without per-user cost increases.

Implementation

1. Define what constitutes a distinct project — in this case, each major product version. 2. Select a pricing tier that supports at least 4-5 active version projects simultaneously. 3. Archive deprecated version projects to stay within tier limits. 4. Set up version-specific navigation and branding within each project. 5. Train the documentation team on project archiving workflows to manage tier limits proactively.

Expected Outcome

The startup maintains clean versioned documentation for all active product releases while keeping documentation tool costs flat as the team grows.

Best Practices

✓ Audit and Define Project Boundaries Before Purchasing

Before committing to a Project-Based Pricing tier, conduct a thorough audit of all existing and planned documentation efforts to clearly define what constitutes a 'project' in your organization. Misunderstanding project boundaries can lead to unexpected tier upgrades.

✓ Do: Create a documentation inventory spreadsheet listing all current portals, knowledge bases, and planned documentation initiatives. Map each to a distinct project definition before selecting a pricing tier.
✗ Don't: Assume every document or topic cluster is a separate project. Most platforms define a project as an entire documentation site or product portal, not individual documents.

✓ Negotiate Future Project Growth Into Your Contract

Project-Based Pricing tiers are most cost-effective when you negotiate headroom for growth upfront. Locking in a rate for additional projects before you need them prevents costly mid-year tier upgrades.

✓ Do: Estimate your project growth over 18-24 months and negotiate a contract that includes a buffer of 2-3 additional projects at the current rate. Request annual review clauses for tier adjustments.
✗ Don't: Purchase only the exact number of projects you currently need. Unexpected product launches or client acquisitions can force rushed and expensive tier upgrades.

✓ Leverage Unlimited Contributors to Improve Documentation Quality

One of the greatest advantages of Project-Based Pricing is the ability to involve subject matter experts, engineers, and stakeholders as contributors without incurring additional costs. Use this to build a broader review culture.

✓ Do: Actively invite engineers, product managers, and customer success representatives as reviewers or contributors within each project. Create structured review workflows that make their participation efficient.
✗ Don't: Limit documentation contributions to only the core writing team out of habit from per-user pricing models. This wastes the primary benefit of project-based licensing.

✓ Establish a Project Archiving and Lifecycle Policy

Active project counts determine your pricing tier, so maintaining a clear policy for archiving completed, deprecated, or inactive documentation projects keeps your costs predictable and your tier appropriate.

✓ Do: Define a documentation project lifecycle with clear stages: Active, Maintenance, Deprecated, and Archived. Schedule quarterly reviews to move projects through the lifecycle and free up project slots.
✗ Don't: Allow old or unused documentation projects to accumulate in your active project count. This inflates your tier costs and obscures which documentation is current and relevant.

✓ Align Project Structure with Organizational or Client Billing Units

For agencies and consultancies, structuring documentation projects to mirror client billing units simplifies both internal cost attribution and client invoicing. This alignment makes Project-Based Pricing a financial management tool, not just a licensing model.

✓ Do: Create one documentation project per client or per billable product line. Use project-level analytics and activity reports to generate accurate time and resource reports for client invoicing.
✗ Don't: Mix multiple client documentation efforts into a single project to stay within a lower tier. This creates access control risks and makes client-specific reporting impossible.

How Docsie Helps with Project-Based Pricing

Book a Demo

Build Better Documentation with Docsie

Join thousands of teams creating outstanding documentation

Book a Demo