APK hardening plans and pricing

Each submitted hardening job consumes the applicable credit. The public package snapshot provides decision information, while the signed-in credit center handles actual purchasing, wallet balance, and transaction history. A material change to plan name, amount, price, or audience requires an explicit snapshot and page-date update.

Usage-based access aligns cost with release candidates, but one release may require several jobs: a minimum-profile validation, a configuration adjustment, and a final candidate should remain separate artifacts. Do not overwrite evidence simply to make a release appear to use fewer iterations.

Count the number of production releases per month and multiply it by the planned candidate validations per release. Treat separate applications, channel artifacts, and materially different ABI variants independently. Reserve some capacity for dependency upgrades, signing migration, and emergency remediation without enabling protection that has no threat-model justification.

An individual project can begin with a smaller allocation while proving artifact signing and device regression. A team should assign responsibility for job creation, configuration retention, output signing, testing, and release approval. An enterprise workflow should attribute usage by application and release line so billing records remain connected to technical evidence.

These are capacity-planning guidelines, not feature or outcome promises. Every plan follows the same release-validation responsibilities.

This page and the home page prerender a versioned public package snapshot and do not require a browser connection to the package database. Visitors and crawlers can still read prices, credits, and intended audiences during an authentication, Supabase, or credit-center incident.

The snapshot is not payment confirmation. The signed-in credit center loads purchasable configuration before an order begins. If that configuration differs from the public snapshot, stop and contact support. Update snapshot version, visible date, and sitemap lastmod only when content changes materially rather than refreshing them mechanically every day.

Hardening changes the APK and the delivered artifact is unsigned. The application owner must sign it and validate installation, upgrade, startup, authentication, networking, payments, push, background work, and native behavior on target devices and channels.

Detection rules, Android versions, SDKs, and application code evolve. A plan supplies usage capacity; it does not guarantee identical results for every future release, device, store, or security product. Validate a small candidate first, then scale a stable process.