Native Mobile, Custom Billing and SaaS Multi-tenancy: Use/Not-Now Decision

Three technologies, three problems, three independent decisions

Consider a web-first SaaS product with a responsive PWA, provider-hosted subscriptions, and a small group of business customers in one shared deployment. Leadership proposes one “maturity” roadmap item: native iOS/Android clients, a custom billing engine, and per-tenant infrastructure. The bundle sounds coherent only because three different problems have been collapsed into one upgrade story.

Native Mobile must start from a measured capability or distribution gap: does background work, Bluetooth, a device API, offline behavior, or app-store distribution solve something the existing web/PWA path cannot? Custom Billing must start from a billing-model gap: is there a subscription, invoice, contractual, or state-ownership requirement the current provider cannot express? SaaS Multi-tenancy must start from a tenant/isolation/residency requirement: is there contractual isolation, regional residency, or a measured noisy-neighbor risk the shared deployment cannot satisfy?

Android architecture guidance recommends clear UI/data boundaries and adapting recommendations to app needs; that fact does not say every web product needs a native app. [ANDROIDARCH] Stripe Billing models subscription lifecycles and recurring billing state; that fact does not make a custom billing engine necessary. [STRIPEBILL] Azure multitenancy guidance describes tenancy and isolation models with trade-offs among sharing, cost, reliability, and customer requirements; it does not prescribe one tenancy architecture for every SaaS product. [AZTENANCY]

The lesson artifact is Native/Billing/Tenancy Adoption Decision Matrix v1 with three independent rows: NATIVE_MOBILE, CUSTOM_BILLING, and SAAS_MULTI_TENANCY. Allowed states are USE, PILOT, NOT_NOW, UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, and DISPUTED. Missing decisive evidence never becomes USE or PILOT simply because the technology may be useful later.

Planned active time: 45 minutes.

This lesson is for a learner who must audit problem fit and lifecycle burden for the three axes before adoption.

It does not publish apps, replace real billing, migrate production tenants, or absorb the adjacent Microservices/Offline Studio or Portfolio/Marketplace outcomes.

HARD prerequisite — AWR-001

Before the Fast Path, state the relevant AWR-001 boundary in one sentence: why is a “serious/modern technology” label not an adoption trigger, and what evidence must exist before USE? Then name one AWR-001 non-goal that must not enter the Native/Billing/Tenancy decision. If you cannot separate a concrete problem, measured trigger, simpler alternative, owner, and operating cost, the Fast Path is not open.

Bounded bridge: recover only this evidence rule — technology name or modernity is not adoption evidence; a concrete problem, measurable trigger, simpler alternative, operational owner, burden, and revisit trigger must be visible, and NOT_NOW can be a correct result. This bridge does not complete or fabricate the Kubernetes/Kafka outcome from AWR-001.

Diagnose the gap before choosing the technology

Answer four diagnostics:

1. A feature needs the camera, but there is no background-work, offline, or distribution requirement. Does that alone justify Native Mobile?
2. A new pricing plan is already supported by the current billing provider. Is Custom Billing required?
3. A SaaS product has five small customers and no explicit isolation or residency requirement. Does the word “enterprise” require a new tenancy architecture?
4. One regulated customer adds strong isolation and regional residency. Can that evidence change only the tenancy row while Native and Billing remain unchanged?

Four correct responses → Fast Path. Two or three → Repair Path. Zero or one → Foundation Path. The Fast Path compresses terminology; it never removes negative evidence, lifecycle burden, rollback, or transfer.

Self-check: do not turn a capability into a requirement, a provider feature into a provider gap, tenant count into isolation pressure, or NOT_NOW into a maturity failure.

Mental model: three evidence chains, not one maturity ladder

NATIVE_MOBILE → product gap → native-only/device/distribution/offline requirement → simpler web/PWA option → owner + support/migration/rollback → bounded state

CUSTOM_BILLING → billing-model gap → provider capability gap → subscription/invoice/tax ownership → simpler provider configuration → owner + support/migration/rollback → bounded state

SAAS_MULTI_TENANCY → tenant definition/count → isolation/residency/noisy-neighbor requirement → simpler shared deployment → owner + support/migration/rollback → bounded state

For each axis, separate the problem from the technology name, measure the trigger, test the existing alternative, then expose lifecycle burden. If the trigger is measured absent, NOT_NOW can be an evidence-backed result. If the decisive trigger or owner is unresolved, preserve UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, or DISPUTED rather than converting uncertainty into success.

Keep three authority layers distinct. External FACT explains mechanisms and capabilities. Local evidence establishes the product/commercial/isolation condition. MAKNOW DESIGN defines the state vocabulary and acceptance gates. If the diagram is unavailable, this ordered flow is the full text fallback for asset://AWR-005/AWR-005-ASSET-FLOW.

Foundation: the evidence contract for each axis

NATIVE_MOBILE

Name product_capability_gap, then separate native_only_requirement, device_api_requirement, distribution_requirement, and offline_requirement. “We need the camera” is only a capability statement. If a web/PWA path can satisfy the workflow at the required reliability, the native-only gap is not established. Record operational_owner, support_burden, simpler_alternative, migration_cost, and rollback_path. Android architecture guidance is a capability/architecture fact, not adoption authority. [ANDROIDARCH]

CUSTOM_BILLING

Record billing_model, subscription_state_owner, invoice_tax_requirement, and provider_capability_gap. The important question is not whether billing is important; it is which required model or state behavior the current provider cannot express and who will own correctness after custom logic is introduced. Stripe Billing documents subscription lifecycles and recurring billing primitives, but it does not establish a need for a custom engine. [STRIPEBILL]

SAAS_MULTI_TENANCY

Keep tenant_definition and tenant_count separate from isolation_requirement, data_residency_requirement, and noisy_neighbor_risk. Tenant count does not by itself choose an isolation model. Azure describes multiple tenancy/isolation patterns and their trade-offs; the decision still depends on actual requirements, reliability/cost, and operations. [AZTENANCY]

Every row also requires evidence_ref, learner-authored rationale, decision_state, review_due, and stop_or_pivot_trigger.

Building Native/Billing/Tenancy Adoption Decision Matrix v1

Step 1 — Create three rows. Never collapse them into an “enterprise maturity” score. One row can be PILOT while another is NOT_NOW and the third REVIEW_REQUIRED.

Step 2 — For Native, connect device capability to the real workflow. Bluetooth background scanning, reliable background camera processing, offline capture/sync, or a distribution policy can be relevant, but evidence must show where the PWA path fails. “Better experience” without a measurable gap is not enough.

Step 3 — For Billing, prove a provider gap with a concrete requirement. Usage-based contractual invoicing, state ownership, tax/invoice semantics, or reconciliation may matter. If the current provider already supports the pricing model, the same evidence cannot justify Custom Billing.

Step 4 — For Tenancy, distinguish customer requirements from architecture fashion. Regulated isolation, residency, noisy-neighbor pressure, or contractual separation must be explicit. Shared deployment remains a valid simpler alternative while it serves the core requirement.

Step 5 — Add ownership and burden. Native expands client release/support surfaces. Custom Billing creates state-correctness, reconciliation, and invoice/tax responsibilities. Multi-tenancy creates isolation, observability, placement, migration, and incident-boundary work. Do not invent real pricing; record a burden class and the accountable role.

Step 6 — Define rollback before adoption. A native pilot without a route back to the web workflow, a billing migration without a provider fallback, or a tenancy split without a reverse/migration path is not bounded.

Step 7 — Derive the state from evidence. USE/PILOT require a present trigger plus owner/lifecycle evidence. NOT_NOW is reserved for a measured absent trigger. Unresolved decisive evidence remains typed uncertainty.

Worked example: the current web/provider/shared path still serves the need

Baseline synthetic fixture: the product has a responsive PWA; camera use is foreground-only; no background/offline or app-store distribution requirement is recorded. Standard monthly/annual subscriptions and the proposed pricing variation are supported by the current provider. Five business customers share one deployment; no contractual isolation/residency requirement or measured noisy-neighbor incident is present.

For Native, the evidence says the current PWA serves the measured workflow. A worked result may be NOT_NOW because the trigger is measured absent, not because native technology is bad. For Billing, no provider capability gap is present; owning a billing engine is therefore not justified by this evidence. For Tenancy, tenant existence does not create an isolation trigger; shared deployment remains the simpler alternative.

This worked example is not a lab oracle. In lab://AWR-005/AWR-005-LAB1, the learner enters the decision values and the checker validates only fixture binding and visible consistency rules. The canonical working table is asset://AWR-005/AWR-005-ASSET-TABLE; its 15 columns keep problem, measured trigger, gap, tenant/isolation requirement, alternative, owner, burden, migration, rollback, decision, review due, stop/pivot trigger, and evidence aligned.

Near negative example: add one camera feature while background/offline/distribution requirements remain absent. That mutation does not make Native USE valid; diagnose the invalid field/state instead.

Failure modes and minimal repair

1. “Every serious SaaS product eventually has native apps.” Prestige replaces a product gap. Repair: identify one workflow and one native-only/device/distribution/offline requirement.

1. “Billing matters, so we should own the stack.” Ownership preference replaces a provider gap. Repair: state one billing model or state/invoice requirement the current provider cannot support. If it is supported, the trigger is absent.

1. “We have enterprise customers, so every tenant needs separate infrastructure.” Customer label replaces isolation/residency evidence. Repair: provide a contractual requirement or measured isolation/noisy-neighbor risk.

1. The owner is removed while the decision remains USE. Capability without operational ownership is not a success state.

1. Migration cost or rollback is blank. The technology may be plausible but the decision is not bounded and reversible.

1. Decisive evidence is unknown but the row says NOT_NOW. NOT_NOW means measured absent trigger, not “we do not know.” Preserve UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, or DISPUTED until evidence closes.

The Repair Path reruns only the failed evidence dimension rather than rebuilding the whole matrix.

Experienced bridge: move from preference to decision economics

If you already know Android, billing platforms, or tenancy patterns, compress definitions and defend the trade-off. For Native: which workflow becomes materially more feasible/reliable through platform integration, and what is the cost of maintaining parity across web and native clients? For Billing: which state transition or commercial contract is outside the provider boundary, and who owns reconciliation, tax/invoice semantics, and incident response? For Tenancy: which isolation/residency/SLO requirement breaks in the shared model, and what operating burden buys the smaller blast radius?

The experienced route does not lower the evidence bar. evidence_ref, owner, support burden, migration/rollback, and review trigger remain visible even when fit feels obvious. A positive axis never drags the other axes upward. A regulated tenant can justify a tenancy PILOT while Native and Billing remain NOT_NOW. A Bluetooth background requirement can change Native without creating a billing or isolation gap.

Trade-offs: prefer the simplest option that covers the measured need

For Native, alternatives can include a responsive/installable PWA, existing Web APIs, or a thin native pilot. The question is not which option feels more product-like; it is which option closes the measured capability/distribution gap with the least duplicated release and support burden.

For Billing, alternatives include provider configuration, hosted subscription primitives, or constraining the business model to supported semantics. If the provider already covers the requirement, a custom engine adds state-correctness and reconciliation complexity without a measured gap.

For Tenancy, alternatives can include shared deployment with logical isolation, targeted data boundaries, noisy-neighbor controls, or stronger isolation only for regulated tenants. Azure guidance explicitly frames tenancy as a trade-off among sharing, cost, reliability, and customer requirements. [AZTENANCY]

PILOT is useful when the trigger is present but uncertainty can be bounded with a named owner, scope, stop trigger, and rollback. USE requires stronger evidence for sustained need and lifecycle ownership. NOT_NOW is correct when the trigger is measurably absent and the current alternative serves the core need.

Guided and independent practice

Guided case 1: open the camera-only fixture. Analyze only the Native row first. Has camera use become a background/offline/distribution requirement? If not, reject a success state and write a review trigger describing the measurable change that should reopen the decision. Recompute Billing and Tenancy from their own evidence rather than copying the Native result.

Guided case 2: a new pricing model is added, but the current billing provider supports it. Inspect provider_capability_gap. Custom Billing success must not pass while the gap is measured absent.

Guided case 3: one regulated tenant adds strong isolation and regional residency. Only the Tenancy row is reopened by that evidence. If owner, migration cost, or rollback is missing, the trigger may be present while the valid state remains OWNER_MISSING or REVIEW_REQUIRED rather than NOT_NOW.

Independent transfer: a second product gains Bluetooth/camera background work, usage-based contractual invoicing beyond current provider capability, and one regulated enterprise tenant requiring stronger isolation and regional residency. Rebuild all three rows from scratch. Do not copy the baseline.

Stable resource: lab://AWR-005/AWR-005-LAB1.

Verification: a reviewer must be able to reproduce every row

Minimum checks:

• evidence values exactly match the selected shipped fixture;
• each row’s authority_refs traces the axis FACT to its official source and the decision gate to this lesson’s DESIGN authority;
• all three axes remain independent;
• success requires a present trigger plus owner and lifecycle evidence;
• Native success without a native-only/device/distribution/offline gap is rejected;
• Custom Billing success without a provider capability gap is rejected;
• Tenancy success without isolation/residency/noisy-neighbor pressure is rejected;
• a missing owner blocks success;
• missing decisive evidence cannot become success or NOT_NOW;
• rationale, review_due, and stop_or_pivot_trigger are non-empty;
• migration and rollback are explicit for success states.

AI may organize the synthetic fixture and run deterministic checks, but it may not invent the trigger, owner, provider gap, tenant requirement, or production approval. Human accountability remains with the reviewer making the bounded decision.

Keep the evidence artifact as three complete records and reference it from the application assessment.

Assessment and transfer

AWR-005-F1: state the owned lesson boundary and one adjacent non-goal.

AWR-005-F2: diagnose the mutation “one camera feature with no background/offline/distribution requirement”; identify the invalid field/state and the smallest repair.

AWR-005-F3: recompute the transfer from changed evidence.

AWR-005-S1 — retrieval: explain why Native, Billing, and Tenancy are separate decisions and name one non-goal.

AWR-005-S2 — application: build Native/Billing/Tenancy Adoption Decision Matrix v1 from the baseline fixture.

AWR-005-S3 — diagnosis: analyze the camera-only mutation and state the consequence plus minimal repair.

AWR-005-S4 — transfer: the second product has Bluetooth/camera background work, usage-based contractual invoicing, and regulated isolation/residency. Recompute the three states independently and defend owner, alternative, migration/rollback, and review trigger for each.

S1 through S4 are blocking. No learner-facing answer key is shipped; the reviewer evaluates evidence quality and boundedness.

References, freshness, and claim boundaries

[ANDROIDARCH] Android Developers — Architecture recommendations. Used only for the fact that Android guidance describes architecture boundaries/recommendations that must be adapted to app needs; it does not prove that every web product should adopt native clients.

[STRIPEBILL] Stripe Documentation — Billing subscriptions overview. Used for subscription lifecycle and recurring billing primitives; it does not establish a need for Custom Billing.

[AZTENANCY] Microsoft Azure Architecture Center — Multitenant tenancy models. Used for tenancy/isolation patterns and trade-offs among sharing, cost, reliability, and customer requirements; it does not mandate one tenancy architecture.

All three sources were retrieved on 2026-09-03, with the next review planned for 2026-12-02. Use each source only for the FACT boundary stated above; recheck those facts earlier if the cited platform semantics materially change.

Synthetic fixtures do not prove production behavior, real cost, tax/legal treatment, or customer contracts. This lesson mutates no app, billing account, cloud tenant, or production data.