Product operations
Honest product status by design
Why Gummy UI separates specified, implemented, tested, deployed, and production-verified status across components, Pro, commerce, support, and legal pages.
By Gummy UI · Published
Use verbs with evidence
A product can exist in a manifest before its source exists, and source can exist before a clean consumer can install it. Tests can pass locally before a deployment has monitoring, support, backups, or a verified rollback. Gummy UI’s master specification uses separate states so each claim can point to the evidence it requires.
This vocabulary prevents “launch-ready” from becoming a substitute for unfinished operational work. A component count comes from the public catalogue. Pro counts and statuses come from its boundary-safe manifest: the current deliverables are implemented, but they remain below verified and release-ready. Production URLs, customer journeys, and service levels cannot be claimed while the required systems remain unselected or inactive.
Keep commercial facts behind approval
The founder has now approved Individual, Team and Organization monthly, yearly and lifetime prices, named-seat rules, subscription and lifetime update access, commercial rights, a 14-day unopened-file goodwill refund, a two-business-day support target, Stripe Managed Payments and the selling entity. The pricing and terms pages record those facts, while checkout and entitlement routes remain closed until the real provider-backed system passes.
The same discipline applies to social proof. Sample names and rows used in component demonstrations are fictional interface content, not customers or testimonials. Editorial material should explain implemented design and engineering choices without manufacturing adoption, time savings, performance scores, or compatibility claims.
Publish privacy and security as current state
The privacy notice now names KREYD LABS LTD, the approved providers, purposes, lawful bases, retention periods, rights and the founder-controlled contact address. It still says that provider use must be rechecked against the real production configuration before publication.
The security page similarly distinguishes tested local, provider-neutral contracts from active production controls and now routes private reports to the confirmed monitored address. Production controls and test evidence must exist before the implementation status can change.
Make remaining work visible
An honest status page is not an excuse to stop. It turns missing work into a concrete gate: package-manager fixtures, full browser accessibility, localisation, performance budgets, dependency and artifact scans, monitoring, backup and restore evidence, commerce journeys, and protected Pro delivery.
When those gates close, the documentation should be updated with the implementation rather than after launch. Public claims, manifests, tests, deployment evidence, and operating procedures need to describe the same product. Until then, precise pre-launch language is a feature of the system’s trust model.