lumencare-tier-matrix

activetype/area-docdomain/commercialdomain/operations

LumenCare tier matrix

TL;DR

Reusable LumenCare packaging splits one-time build work from recurring maintenance so delivery quality, margin, and liability stay controlled. This version is intentionally set to Lane A (price-sensitive UMKM lane) with max one-time build at Rp 30 jt. LumenDev itself is UMKM-scale (~Rp 50 jt/year revenue) and currently run as a side hustle outside the primary role at Anabatic; see [[Areas/LumenDev/LumenDev#Business scale (UMKM)|business scale]]. SLA commitments are calibrated for a lean delivery team (up to 5 people) and business-hours operations only.

Tier matrix (build vs recurring)

Tier	Fit boundary	One-time build fee (IDR)	Recurring maintenance (IDR/month)	SLA hint	Included	Excluded
LumenCare Foundation	Brochure/company profile site or low-change app, minimal integrations	5,000,000 - 10,000,000	300,000 - 900,000	P3-focused support, P2 when needed, business-hours only	Basic monitoring, monthly dependency updates, minor content/config changes, 1 monthly review	New feature delivery, major redesign, deep data migration, 24/7 on-call
LumenCare Growth	Operational app with transactions/integrations and moderate change velocity	10,000,000 - 20,000,000	900,000 - 2,000,000	P2/P3 operational support with faster business-hours response	Everything in Foundation, release support, incident handling, monthly hardening, prioritized bug fixes	Net-new module build, legacy system rewrite, high-volume perf tuning projects
LumenCare Scale	Higher-impact UMKM system needing tighter handling in a non-enterprise model	20,000,000 - 30,000,000	2,000,000 - 3,500,000	Full P1/P2/P3 matrix in business hours, best effort outside hours by agreement	Everything in Growth, change advisory cadence, stronger rollback readiness, quarterly resilience review	Product discovery, strategy consulting, large re-architecture unless separately scoped

SLA matrix (lean team, <=5 people)

Coverage window

Monday-Friday, 09:00-17:00 WIB (excluding Indonesian public holidays).
Outside coverage is best effort only and not contractually guaranteed unless separately contracted.

Priority	Definition	Initial response target	Workaround target	Resolution target
P1 - Critical	Production down or core transaction fails for most users; business operation blocked	<= 4 business hours	<= 1 business day	<= 3 business days (or next agreed hotfix window)
P2 - High	Major feature degraded; workaround exists but with significant business friction	<= 1 business day	<= 2 business days	<= 5 business days
P3 - Normal	Minor bug, low-risk defect, content/config request, non-urgent improvement	<= 2 business days	N/A	Bundled into next scheduled release (target <= 10 business days)

Policy notes

Build fee and recurring maintenance are always priced independently to avoid "lifetime support" assumptions.
Recurring maintenance bands are baseline ranges and can move lower or higher based on actual monthly scope and resource footprint.
Low-resource projects (for example, mostly static content changes with minimal infra/API usage) may be priced below the listed recurring range by agreement.
High-resource projects (for example, AI token usage, high-volume API calls, paid third-party platforms, or heavier infra load) may be priced above the listed recurring range by agreement.
Infra, AI/API token usage, third-party SaaS, message credits, domain, and cloud services are pass-through costs billed at actuals (plus agreed admin fee in statement template) and may be charged outside recurring maintenance based on contract agreement.
Work outside inclusions is priced as scoped change request or separate project phase.
Target ranges are baseline anchors; final pricing follows complexity, data sensitivity, integration risk, and timeline compression.
SLA language in proposals should explicitly reference the P1/P2/P3 table above and business-hours support limits. No default commitment to 24/7 on-call, strict uptime percentages, or financial service credits.
At UMKM revenue scale, a single under-priced Scale-tier client (or free infra) can dominate annual margin — default down-tier or scope-split when fit is unclear.

Tiering checklist

User/business criticality: non-critical, operationally important, or revenue-critical.
Integration depth: none/light, moderate, or high-coupling integrations.
Change velocity: monthly low-touch, regular releases, or continuous delivery.
Risk profile: tolerance for delayed restore and slower response vs strict recovery expectations.

Payment schedule (orthogonal to tier)

Tier bands assume standard build billing (Path A). For lower upfront, build installments, or full subscription with min term, use [[Areas/LumenDev/playbooks/commercial-payment-models|commercial payment models]] — LumenCare bonuses differ by path (generous on Path A, embedded on Path C).

[[Areas/LumenDev/playbooks/commercial-payment-models|Commercial payment models]]
[[Areas/LumenDev/playbooks/msa-sla-clause-template|MSA/SLA clause template]]
[[Areas/LumenDev/playbooks/client-migration-script-wa-email|Client migration script (WA + email)]]
[[Areas/LumenDev/playbooks/monthly-infra-statement-template|Monthly infra statement template]]