PRODUCT · OPERATING LAYER FOR FLUTTER

Ship Flutter changes between releases. Every change. One signed chain.

Ejenix is the operator surface for everything that used to wait on App Store and Play Store review — Dart code patches, feature flags, remote config, server-driven UI, asset bundles — with staged rollouts, auto-rollback, and a cryptographic audit chain underneath every change.

WAIT, REALLY?

What you can change without a re-release.

Your Dart code. Your images. Your copy. Your layouts. Your flags. Your config. Your assets. All of it — everything below — used to mean waiting on Apple's queue, Google's queue, or both. None of it does anymore.

DESIGN · PRODUCT
The visual layer
  • Images · icons · photos
  • Full screen layouts
  • Microcopy · headlines · errors
  • Localized strings for a new market
ENGINEERING
The code layer
  • Dart code — bug fixes, hotfixes
  • Performance tweaks
  • Network retry · timeout policy
  • API endpoint config
GROWTH · MARKETING
The campaign layer
  • Promo banners · discount cards
  • A/B test variants
  • Headlines · CTAs
  • Event-day · launch-day swaps
OPERATIONS
The control layer
  • Feature toggles · kill switches
  • Cohort · segment routing
  • Auto-rollback rules
  • Permissions · RBAC
MEANWHILE…
What everyone else can do
  • Basic Dart code patches
  • × Images · layouts · styling
  • × Flags · remote config (separate vendor)
  • × Auto-rollback · audit chain

Everything else? Re-release. Or a separate vendor. Often both.

THE OLD MENTAL MODEL

“If we want to change anything in the app, we have to ship a release.” — you, until you adopted Ejenix.

See the capability matrix ↓
CAPABILITY MATRIX

Three blocks. One operator surface.

What you push. The dispatch architecture underneath it. What you operate it through. Every capability here is sold as a separate product elsewhere — Ejenix unifies them with one audit chain and one bill.

BLOCK A · WHAT YOU PUSH

Four shipping surfaces.

Every change you used to wait on a release for. Code, layouts, config, assets — each surface has its own contract.

A1
DART CODE PATCHES

Ship Dart changes without resubmission.

Fixes, hotfixes, small features to live users in minutes. Routed through the dispatch architecture (Block B). Example: a keyboard race breaking checkout — patched on 100% of fleet before the next review cycle would have opened.

A2
SERVER-DRIVEN UI

Push layout changes to live screens.

Within reviewer-safe policy. Swap a marketing banner, restructure an onboarding flow, A/B a checkout layout — no rebuild, no resubmission, no two-week wait.

A3
FEATURE FLAGS & REMOTE CONFIG

Toggle behavior without a deploy.

Boolean flags, multivariate flags, typed config values. Cohort-aware, audit-logged, two-person review when you want it. Replaces your LaunchDarkly / Firebase Remote Config bill.

A4
ASSET & BUNDLE DELIVERY

Ship images, fonts, JSON bundles without a release.

Versioned, signed, delta-shipped to the device. Same audit chain, same cohort targeting, same auto-rollback — the asset layer plays by the same rules as code.

BLOCK B · THE DISPATCH MOAT · PATENTED

Multi-mode dispatch. Four internal modes. Picked automatically.

For a Dart code change, the system classifies the shape and routes through one of four runtime paths. The patent covers the orchestration that picks — not any single path. Competitors can build one mode; not the system that picks between four.

MODE 1
Literal change.

A constant, a string, a number. The fastest path.

MODE 2
Function-body change.

Replace the body of an existing function.

MODE 3 · MOAT
Add a new function into the running app.

First system in the category to do this.

MODE 4
Structural change.

Code-shape rewrites the lighter modes can't carry.

BLOCK C · HOW YOU OPERATE

Four operational systems.

Every surface from Block A ships through these. Cohorted, gated, reversible, signed.

C1
STAGED ROLLOUTS

1% → 100% with gates that hold or auto-rollback.

Crash-free, P95 latency, error-class — any signal you declare. Holds at a step if breached; reverses to last-known-good if bad. ~90 seconds end-to-end. Deep dive ↓

C2
COHORT TARGETING

Reach exactly the users you mean to.

Cohort by region, OS, device tier, app build, install age, user attribute, custom predicate. First-class objects — compose, version, reuse. Deep dive ↓

C3
APPROVAL WORKFLOWS · RBAC

Two-person review. Role-based access. Co-signed promotion.

Owners, Admins, Approvers, Operators, Read-only. Promote staging → production with co-signed approval. Every decision recorded in the audit chain.

C4
AUDIT CHAIN

Every operation signed. Locally verifiable.

Ed25519 at the source, hash-chained, append-only. Your auditor downloads the range, verifies it on their laptop with an open-source tool. No vendor trust required. SOC 2 evidence in minutes.

WHY THIS MATRIX MATTERS

Code-push. Flags. Remote config. SDUI. Asset CDN. Approval workflows. Cohort engine. Audit log. Eight products elsewhere. One operator surface here — with one audit chain, one compliance posture, and one bill.

THE OPERATOR SURFACE

One console. Every change. Every environment.

The Command Center is the room your release engineer, your SRE, and your product owner are all in during a rollout. Real fleet health, real in-flight rollouts, real approval queue — all on one screen.

Ejenix Command Center — fleet health, in-flight rollouts, approval queue
DECISION BAR

What needs a human right now. Rollouts holding their gate, approvals waiting, auto-rollback recommendations.

SIX KPIs · FLEET-WIDE

Devices live, crash-free 24h, patches today, median apply time, approvals open, chain integrity.

LIVE ROLLOUTS

Every patch in flight, its cohort, its progress, its gate state. Promote or roll back from the row.

APPROVAL QUEUE

What's waiting on a co-sign. Approve or decline without leaving the screen. Logged to the chain.

END-TO-END FLOW

How a change moves through Ejenix.

Six phases from your IDE to 100% of fleet. Each phase is auditable, reversible, and visible in the console in real time.

01 · WRITE
In your IDE

A patch is just a Dart change on a patch branch.

02 · PUBLISH
One command

Policy gates run; co-signs collected; record sealed.

03 · ROLL OUT
Cohorts, paced

1% → 100%, by region, device, build, custom tags.

04 · OBSERVE
Live signal

Crash-free, latency, error class, adoption — second-level.

05 · PROVE
Signed record

Every step appended to a signed, locally-verifiable chain.

06 · ROLL BACK
~90 seconds

Single click. Atomic. Audit chain records every byte.

ROLLOUT CONTROLS

Rollouts that police themselves.

Every promotion is gated on the signal you tell it to watch. Every gate is overridable by a co-signed human. Every override is recorded.

rolloutpolicycohorts
patch · #4471
1%
00:15 ✓
5%
00:42 ✓
25%
01:38 ✓
50%
↑ live
100%
pending
AUTO-PROMOTE GATE · GATE-PERF-02
Crash-free ≥ 99.90% over 90s window
holding

Pace, never bypass.

A rollout is a contract between you and the signal. You declare the cohorts, the steps, and the gates. Ejenix runs the loop and records every decision.

01
Cohort steps
1% / 5% / 25% / 50% / 100%, or any custom ladder.
02
Auto-promote gates
Crash-free, latency P95, error class, custom metric.
03
Auto-rollback triggers
Same shape. When breached, the fleet returns to last-known-good in ~90s.
04
Human override · co-signed
Promote, hold, or unroll manually. Two signatures, always recorded.
TARGETING

Reach exactly the users you mean to.

Cohorts are first-class objects. Compose them from any device-side attribute, any server-side tag, or any custom predicate you publish.

COHORT · onboarding-eu-android-canary
active
match:
  region:      [DE, FR, NL, BE]
  platform:    android
  build:       ≥ 2026.05.03
  device.tier: [mid, high]
  user.flag:   onboarding_v3
  rollout.pct: 5%
exclude:
  user.role:   [internal, qa]
estimated_reach: 412,810 devices

Predicate, not popup.

Cohorts compose. They version. They live in the audit chain. The same cohort that received a beta last week can receive the hotfix today — with one identifier, not a copy-and-paste.

  • Region · country · locale
  • Platform · OS version · device class
  • App build · channel · install age
  • User attribute · feature flag · custom tag
  • Statistical sample · stable hash · randomized
WHAT BECOMES POSSIBLE

Operating shifts your release schedule never allowed.

Speed without trust is not enough; trust without speed is what you have now. The combination is the unlock.

RELEASE DECOUPLING

Big shipped doesn't mean big released.

Ship the change. Hide it behind a cohort. Reveal it on a date you choose, not the date the queue allows.

RISK BUDGETING

Allocate risk to 1% before 100%.

Every patch has a blast radius. Choose it explicitly. Expand it on evidence. Contract it on signal.

REGULATORY MATCH

Different rules, different markets.

Comply locally without forking the codebase. Cohort by region. Sign the regional record separately.

LOOKING FOR THE COMPLIANCE STORY?

Audit chain, reviewer packet, posture mapping, the things your auditor actually opens — that's all on the Trust page.

See the trust page →

Bring the whole post-release loop into one room.

Eight capabilities. One operator surface. One audit chain. One bill.

Talk to us See pricing