Shipping to Production Is Not the Same as Owning the Product

“It is in production” often sounds like the final line of a project.

It is only a transition. Code left the repository and became something a user can touch. Product ownership starts there.

Deploy and ownership answer different questions

Deployment asks: did the new version ship?

Ownership asks:

• Is the correct version live?
• Do critical flows work in the real environment?
• Is user data safe?
• Are domain behaviours consistent across platforms?
• How will we detect regressions?
• What can we roll back?
• Are caches or stale artifacts hiding the real release?
• Can the next release safely read the current state?

A green CI result cannot answer all of that.

Release is an acceptance chain

I treat production work as a sequence of gates:

Preflight → Root cause → Implement → Build → Render → Interaction → Responsive → Accessibility → Deploy → Live verify.

Each gate closes a different class of risk. Build success does not prove interaction correctness. A successful deployment does not prove that the custom domain serves the new artifact. Desktop correctness does not prove 390px behaviour.

The live URL is the final reality

Repository state matters. CI matters. Hosting dashboards matter.

The user sees none of them. They see the production URL.

That is why the final evidence is the live surface. A Cloudflare deployment can be green while a custom domain still points at an older deployment, a service worker serves stale assets or the production branch is not the branch you assumed.

Ownership includes discovering that difference.

Multi-platform ownership is harder

Ordovia exists on web, Android and Windows. That means a release is not merely a web deploy.

Shared domain behaviour must remain coherent. Native back behaviour must respect hierarchy. Session lifecycle must survive platform differences. Notifications, deep links and entitlement logic need platform-specific verification.

A shared codebase creates leverage, but only if platform differences are explicit rather than accidental forks.

Data ownership travels through releases

UI is not the only thing that changes during a release. Schema, RLS, RPCs, cache formats, migrations, local durable storage and feature flags can all change.

Old clients may coexist with a new backend. A store release does not mean every user upgrades immediately. Backward compatibility and rollout risk are part of operational ownership.

OPERATE is not passive maintenance

Maintenance is often framed as “fix bugs when they appear.” I use a more active definition:

• release discipline,
• monitoring,
• dependency and infrastructure risk,
• security and data ownership,
• performance regression,
• integration health,
• platform parity,
• operational decision records.

The goal is not to freeze the product. It is to let it keep changing without losing control.

Shipping code is delivery. Knowing what the live product is carrying — and being able to prove it — is ownership.