waynele.
Let’s talk
← All work

Clevah / Mobile learning

A better start to learning.

Onboarding, learning setup, and subscriptions for a mobile learning product.

Clevah official app store screenshot 1Clevah official app store screenshot 2Clevah official app store screenshot 3

Official Clevah store screenshots show the team product. My contribution focused on onboarding, account access, learning setup, and subscriptions.

View the public app
My roleFlutter & backend contribution
When2026
FocusMobile learning
Stack
  • Flutter
  • Dart
  • Python
  • Cloudflare Workers

Results & scope

Warm dev CPU p50 · 10k questions
≈220 ms
Recorded experiment
10 June 2026 · historical development edge optimizer · 10,000 seeded questions across five topics · warm isolate, KV cache hit. CPU time, not response latency.
Method & conditions

Recorded in an archived engineering report with supporting seeder and CPU-monitor code. Raw telemetry responses and sample counts were not recovered; this result was not rerun. It does not establish current production performance.

Cold dev CPU p99 · 10k questions
≈655 ms
Recorded experiment
10 June 2026 · historical development edge optimizer · 10,000 seeded questions across five topics · cold execution, KV cache miss. CPU time, not response latency.
Method & conditions

Recorded in the same development report. Cold p99 and warm p50 describe different execution conditions and percentiles, not a before-and-after optimization. Raw telemetry samples and counts were not recovered; this result was not rerun.

How I approached the work

Engineering decisions.

Separate compute from storage and response time

Problem
Growing question pools change both optimizer CPU work and storage reads. A single response-time number does not identify the source of cost.
Decision
Seeded a 10,000-question development workload and monitored CPU percentiles, wall time, request errors and subrequests under warm and cold cache conditions.
Result
The historical report recorded warm CPU p50 near 220 ms and cold CPU p99 near 655 ms, while identifying pool traversal and storage reads as separate optimization targets.

Connect onboarding to account access

Problem
Mobile learners need to move from guest or social sign-in into learning setup and subscription access.
Decision
Worked across validation, guest access, social sign-in, learning preferences, and subscription purchase and settings flows.
Result
My contribution connected first-session setup with access management in the Flutter product, supported by mobile backend work.

The work.

I contributed to the Flutter mobile-learning product now branded Clevah. My work focused on helping learners get started, configure their learning, and manage access. This is a distinct product from the earlier Growtrics Academy platform.

My contribution

A smoother first session

Signup validation, guest access, and Google and Apple sign-in.

Learning setup

Topic selection, quota presentation, and per-subject exam dates.

Subscription experience

In-app purchases and subscription management, with supporting mobile backend delivery.

Selected engineering contributions

What I built.
How I approached it.

7 documented contributions to Clevah. Start with these examples, or explore the full product index.

All 7 contributions
01
Built · integrated source

Google, Apple and guest sign-in with validated onboarding

Implemented mobile-learning authentication that supports guest entry, Google/Apple sign-in and account onboarding.

Flutter · Dart · Firebase Auth · Google Sign-In · Apple Sign-In · Bloc/Cubit · Firestore

What I changed

  • Implemented anonymous Firebase sessions and account-linking paths.
  • Added Google Sign-In and the Firebase Apple provider.
  • Added live signup-form validation and verification refresh.
  • Centralized onboarding navigation and captured per-subject exam dates.

The decision

Keep account linking and onboarding progression separate so guest users can acquire credentials without silently losing their learning identity.

The result

The mobile client offers multiple credential paths through one repository/auth data source and keeps onboarding state in typed Cubits.

Implementation is verified. Production usage and business impact were not independently measured.

02
Built · integrated source

In-app subscription purchase, verification and restore

Added the mobile pro-subscription purchase flow, account binding and subscription-management paths.

Flutter · Dart · StoreKit · Bloc/Cubit · Firestore · Dio

What I changed

  • Loaded monthly store offers and routed purchase-stream updates.
  • Bound purchase verification to the learner account.
  • Added purchase restoration and pending-purchase handling.
  • Added an iOS StoreKit development configuration and subscription-management URI tests.

The decision

Verify store purchases against the account-bound backend entitlement before presenting subscribed access.

The result

The client exposes purchase and restoration flows with backend entitlement verification, rather than unlocking pro access only from a local purchase event.

Implementation and a StoreKit development configuration were inspected. Public store approval, real purchase revenue and subscriber counts were not verified.

03
Integrated + historical work

Dedicated mobile API and worker deployment boundary

Established mobile backend deployment assets and an explicit API root, with later workload-isolation revisions recorded separately.

Python · FastAPI · GitHub Actions · Helm · Kubernetes · Celery

What I changed

  • Integrated: mobile backend deployment assets and environment release callers.
  • Integrated: Cloud Build image configuration.
  • Integrated: the mobile FastAPI root-path boundary.
  • Historical source: a per-service deployment application and isolated mobile worker Helm resources.

The decision

Give the mobile workload explicit deployment ownership instead of depending on the shared backend process.

The result

The mobile backend has integrated deployment assets and a defined API prefix. Later per-service and worker-resource isolation remains recorded historical work, without deployment proof here.

Deployment assets, build configuration and the API prefix were integrated. Later service and worker isolation remained historical development work without verified integration or production rollout.

04
Integrated + historical work

Authenticated Python optimizer on Cloudflare Workers

Implemented an authenticated mobile optimization endpoint on Cloudflare Workers, with later shared-core and production-route extensions recorded separately.

Python · Cloudflare Workers · Firebase Auth · Firestore · Fetch API

What I changed

  • Integrated: Python Worker request handling and environment route bindings.
  • Integrated: Firebase token verification with cached certificates and WebCrypto.
  • Integrated: Firestore REST and GCP OAuth handling for the edge runtime, without a Celery request hop or Firebase Admin SDK.
  • Historical source: a dependency-free optimizer core and production-environment route extension.

The decision

Adapt request transport, authentication, and storage to the edge runtime. Later work extracts shared recommendation logic rather than duplicating the algorithm.

The result

An integrated edge-compatible request, authentication, and storage path exists. The shared-core extraction and production-environment extension are historical authored work without independently established deployment here.

The edge request handler and environment routing were integrated. Integration of later shared-core and production-environment changes was not verified. No request-volume or latency gain is claimed.

05
Historical implementation

Pinned optimizer releases as the mobile backend moved to the edge

Coordinated mobile-backend pins for edge-optimizer routing, production environment support and consolidated-state changes.

Git submodules · Python · Cloudflare Workers · Firestore

What I changed

  • Pinned optimizer source for develop edge deployment.
  • Advanced the mobile route configuration and production environment source.
  • Updated exact optimizer revisions for shared-core, recycled-state and sharding changes.

The decision

Coordinate consumer integration through exact dependency revisions while keeping the edge implementation in its owning service.

The result

The mobile orchestration repository records which optimizer revision is consumed for each integration change.

Historical dependency-integration work. Integration into the main product and successful production deployment were not verified. The optimizer implementation is covered separately.

06
Historical implementation

Sharded optimizer state with append/roll persistence

Reworked optimizer persistence to consolidate state and support sharded append/roll updates without storing every recommendation in one growing document.

Python · Firestore · Fetch API · Cloudflare Workers

What I changed

  • Consolidated optimizer-state loading and recycling behavior.
  • Added shard-document generation for state records.
  • Loaded state shards through batch Firestore REST reads.
  • Committed stack/recommendation updates through the edge storage adapter.

The decision

Separate logical optimizer state from its physical document layout so record growth can be handled without duplicating the optimizer algorithm.

The result

The adapter represents optimizer state as shard documents and exposes batch-load/commit paths for continued recommendation growth.

Historical persistence-design work. Integration into production, supported load and CPU or cost improvements were not verified.

Explore the full Clevah contribution index
Next projectGrowtrics Academy