The One-Line Summary
We don't bill every package as a full project. Each scanned project is automatically sized into one of four tiers — nano, micro, small or standard — and billed as a fraction of a project. We total the fractions across your estate and round down to the nearest whole number. That total is your billable projects.
Tagline: We count a Lambda as a tenth of a project.
Why Micro-Project Pricing Exists
Modern repositories — especially serverless monorepos — can contain hundreds of tiny packages. Billing each one as a full project would penalise exactly the multi-stack, monorepo-heavy teams Vibgrate is built for.
A Lambda handler is not the same unit of work as a 200-file service, so we don't charge for it as if it were. The mechanic is measurable, automatic, and transparent — there are no manual exceptions and no support tickets to reclassify a project.
The Four Tiers
A project is placed in the lowest tier whose limits it meets. A project qualifies for a tier when it satisfies at least two of the three limits for that tier. The tiers nest strictly, so a package that earns nano always also earns micro — the smallest-first evaluation simply bills it at the cheapest tier.
| Tier | Qualifies on any 2 of 3 | Billing weight | Plain English |
|---|---|---|---|
| Nano | < 10 source files · < 1 MB source · < 5 dependencies | 1/25 of a project | A tiny single-purpose serverless function |
| Micro | < 20 source files · < 2.5 MB source · < 10 dependencies | ⅒ of a project | A serverless function or tiny micro-service |
| Small | < 30 source files · < 5 MB source · < 25 dependencies | ⅓ of a project | A modest component or library |
| Standard | Anything larger | 1 project | A normal product service or app |
The step between adjacent tiers stays small and predictable, so trimming one dependency or splitting one file never produces a large bill swing — and there's no incentive to game a single metric.
How Classification Works
Every scan measures three signals per project:
- Source-file count — number of source files in the project.
- Source byte size — total size of those source files.
- Dependency count — number of declared dependencies in the package manifest.
Why "Any 2 of 3"
A typical Lambda handler — an index file, a few utilities, a handful of tests, and a few dependencies — would fail a strict "fewer than 10 files AND ..." test the moment a test folder grew. Requiring any two of three catches real micro-projects without being defeated by one chatty test folder or one extra dependency.
A criterion only counts when it is a valid measurement: file count must be at least 1, source size must be greater than 0, and a dependency count of 0 is valid (a package may legitimately have no dependencies). A project with no usable metrics is billed as standard — the conservative, full rate.
What Counts as "Source" Size
The size and file-count signals measure source code only. The following are excluded so they can't inflate a genuinely small project past a threshold:
- Lockfiles and generated manifests:
pnpm-lock.yaml,package-lock.json,yarn.lock,bun.lockb,Gemfile.lock,poetry.lock,Pipfile.lock,composer.lock,Cargo.lock,go.sum,gradle.lockfile,deno.lock, and similar. - Vendored dependency directories:
node_modules,vendor,Pods(CocoaPods),Carthage, and similar — third-party source, not code you maintain. - Build-output directories:
dist,build,out,.next,.nuxt,.output,.svelte-kit,coverage,bin,obj,.turbo,.cache, and similar. - Binary assets — images, fonts, video, audio, archives, and compiled artifacts.
A single pnpm-lock.yaml can exceed 1 MB on its own. Excluding it is why a one-file Lambda with a big lockfile is still correctly billed as nano.
Calculating Billable Projects
billable_raw = (standard_count x 1)
+ (small_count x 1/3)
+ (micro_count x 1/10)
+ (nano_count x 1/25)
billable_projects = floor(billable_raw) <- always rounded DOWN
The headline number you are billed for is always rounded down to the nearest whole number. Never to nearest; never up.
Worked Examples
| Scanned projects | Raw calculation | Billable raw | Billable |
|---|---|---|---|
| 200 micro · 27 small · 20 standard | 20 + 9 + 20 | 49.0 | 49 |
| 9 micro | 0.9 | 0.9 | 0 |
| 1 standard + 5 micro | 1 + 0.5 | 1.5 | 1 |
| 3 small | 1.0 | 1.0 | 1 |
| 250 micro | 25.0 | 25.0 | 25 |
The first row is the canonical estimator line: 247 detected -> 49 billable.
Reclassify Gently: Mid-Cycle Changes
A project's tier is re-evaluated on every scan, but billing changes are applied carefully so a bill never rises unexpectedly mid-month:
- Crossing up a tier (a micro project grows into small): the project keeps its cheaper rate for the rest of the current billing cycle, and the higher rate takes effect from the next cycle. The pending change is flagged in Vibgrate Cloud as a pending upgrade.
- Crossing down a tier (a project shrinks): the cheaper rate applies immediately — lowering a bill mid-cycle is always fine.
So the classification you see always reflects the latest scan, while the rate you're billed only ever increases at a cycle boundary.
Fairness Guarantees
- Billing weight is never risk weight. Nano, micro and small projects roll up fully into DriftScores, the portfolio view, and every risk and compliance report. Only the billing weight is reduced — the CTO dashboard never under-counts risk.
- No silent mid-cycle increases. Upward reclassification is deferred to the next cycle and flagged in advance.
- Automatic and measurable. There are no manual exceptions, hidden multipliers, or per-customer overrides — the same three signals are applied to every project on every scan.
Where You'll See It
- CLI (
vg scan) — after the drift score, the classification breakdown and a billable line:Classified: {nano} nano · {micro} micro · {small} small · {standard} standardand{total} detected -> {billable} billable. - Dashboard — a nano/micro/small/standard breakdown widget with the billable total and any pending upgrades.
- Pricing estimator — the
{total} detected -> {billable} billableheadline with the per-tier breakdown. Drag the average project size slider to model a nano-heavy or standard-heavy estate. - Billing API —
usage.projectsincludesbillableProjects(floored),billableProjectsRaw, per-tier counts, and a per-repository breakdown.
FAQ
I have a serverless monorepo with hundreds of functions. Will I be billed for all of them? No. Each function is measured automatically and billed as a fraction of a project — a typical Lambda counts as a tenth. We total the fractions and round down, so 247 detected projects might be just 49 billable.
Does a big lockfile push my project into a higher tier? No. Size is measured on source code only — lockfiles, generated files, and vendored or build directories are excluded.
My project grew. Will my bill jump immediately? No. An upward reclassification keeps your current rate for the rest of the cycle and the new rate starts next cycle, flagged in advance. A project that shrinks gets the cheaper rate right away.
Do micro projects count less toward my DriftScore too? No. Billing weight is not risk weight. Every project — micro, small, or standard — is fully included in DriftScores and the portfolio view.
How is the billable number rounded? Always down. 1.9 billable raw is billed as 1.