Taking a Vibe Coded US GLP-1 Prototype to Production

Industry

Geography

United States

Cooperation Period

18 weeks

About The Client

The Client is a US GLP-1 consumer health company founded by two operators based in Germany and Spain. The Client incorporated in Delaware to serve the US market and built a first web prototype inside Replit. The product supports people using GLP-1 therapies through injection scheduling, weight progress tracking, side effect logging, appetite signals, medication inventory, education content, and a companion mobile experience across iOS and Android.

Both founders vibe code. Each founder uses a different AI assistant. The Technical Founder works in Claude Code and drives production implementation. The Product and Design Founder works in Codex and drives design, user research, peer data analysis, and product direction, contributing UI and fixture code against agreed data contracts.

Alongside the founders, The Client worked with a US commercial partner on the US market entry. US commercial partner input raised expectations around launch readiness, disclosure language, platform behavior, and the handling of consumer health data. Those inputs shaped several product and architectural decisions documented below.

We want control, and the product is becoming too complex to manage alone.

The founding team, at first contact

Executive outcome

In 18 weeks, Clixlogix moved the founders from a shared Replit prototype to a founder owned delivery system where Claude Code and Codex worked through one repository, one verification command, and one human merge gate. The same operating model supported the web product and the native releases. The Client later reported a user community exceeding 100,000.

Challenge

The founders had shipped a working web prototype using Replit. Roughly 12 people were using the application, including a small internal group, invited peers, and one US commercial partner. That prototype validated the product idea. It also carried the fragility that founder built prototypes carry when AI assistants generate the working code and the founders operate as vibe coders.

The prototype ran only inside one environment

Replit held the source, the runtime, and the operational configuration. Moving the product to any other environment required significant extraction and replacement of platform assumptions.

Sensitive health data was handled as ordinary prototype data

The application had no separation between prototype and production. The founders were preparing to serve US users at the same time.

The data model encoded the first demo path only

The schema assumed one medication per user, one injection per week, no medication changes, no backdated entries, and inconsistent units across weight and dosage. Schema changes were performed by hand.

Core calculations were untested

Next injection date, dose history, and weight progress were derived from code that no test framework covered. Every AI assisted edit could shift the values a user saw without producing a failing test.

Reminders did not run reliably

Scheduled tasks stopped without warning, browser notification behavior differed across devices, and no monitoring existed for delivery failures.

Two founders could not safely work in parallel

A shared Replit workspace, no code review, AI generated edits landing on top of each other, and important decisions surviving only inside chat history produced a workflow the founders could not scale.

Portability risk rose with every new feature

Hardcoded service URLs, platform specific storage, and unclear external service ownership added migration cost to every week of prototype development.

Before and after

Fig 1 - The Guarded Delivery Shift

Before	After
Shared mutable `Replit` workspace	Founder owned repository under source control
Decisions trapped in AI chats	ADRs and a decision log inside the repository
Assistants editing over each other	One task, one owner, one branch, one PR
No standard completion test	One `scripts/verify` command run by founders and CI
Manual schema changes	Reviewed, reversible migrations under `migration-safety` control
AI output accepted directly	Human review at the merge gate plus deterministic CI
Platform bound deployment, where the founders owned their `Replit` project and the operational path depended on `Replit`	Client owned release path
Health data handled as prototype data	Minimum necessary posture enforced by the `health-data-boundary` control
Notification reliability unknown	Notification scheduling, rescheduling, provider acceptance, and user open telemetry where the platform exposed it, with reschedule rules on record

Table 1. What changed across the 18 weeks

Guarded Delivery is the operating model that produced the right column. Three phases, four controls, one merge gate, and a senior reviewer holding it. The sections below describe how each piece worked, what it caught, and what it let through.

Engagement Model

Clixlogix engaged as a fractional senior technology lead under a delivery method Clixlogix calls Guarded Delivery. The method has three phases.

Scope - Establish what the product does, what its invariants are, what must not change, and what can be reversed cheaply.
Generate - The founders generated web and product changes with Claude Code and Codex. Clixlogix specialist engineers generated native application changes under the same repository controls.
Harden - Every AI generated change passes through automated verification and a senior reviewer before the merge gate accepts it.

The engagement ran for 18 weeks with a cadence the founders could rely on. Clixlogix operated from India across the engagement, and the founders worked from Germany and Spain. All shared sessions anchored to CET so the founders held a single predictable schedule. Engineering progress continued across the broader day between sessions.

Fig 2 - Weekly Working Rhythm

A Monday planning session anchored to CET set the week's technical direction. The Clixlogix senior technology lead built the agenda from repository state, open PRs, CI failures, Jira priorities, delivery risk, and decisions left unresolved in Slack. Both founders attended. The founders set product and business priorities. Clixlogix translated those into an executable technical sequence.

Tuesday to Thursday held asynchronous implementation by the founders with continuous Slack coordination. A Friday retrospective reviewed what merged, what did not progress, what needed formal documentation, and what should change the following week.

Slack held conversation. Jira held delivery state. The repository held the enduring technical record.

Clixlogix owned the extraction from Replit, the shared repository conventions, the CI pipeline, the review rubric, and the native iOS and native Android builds. One senior technology lead remained dedicated to the engagement throughout the 18 weeks. Native iOS and Android were delivered as separate fixed cost specialist sprints that drew on platform specialists as needed. The Client did not fund separate full time iOS or Android positions. The founders retained ownership of product direction, feature scope, and the daily code output.

When the founders preferred different directions, Clixlogix documented the options, consequences, and reversibility. The founders made the product decision.

Net new product features paused for roughly one to two sprints while the engineering foundation stabilized. Three parallel tracks preserved momentum throughout the transition.

Technical Founder track - Worked with Claude Code to understand the exported Replit code, reproduce the application locally, and establish baseline tests.
Product and Design Founder track - Worked with Codex on peer data analysis, user research, and the mobile design direction that later development would consume.
Clixlogix track - Established the repository, the review rubric, and the initial CI pipeline.

Design work produced user flows, feature priorities, interface requirements, and acceptance criteria that landed as fuel for the first guarded slices.

The Clixlogix senior technology lead's time split as roughly 20 percent explicit vibe code coaching and knowledge transfer and roughly 80 percent delivery work. Vibe code coaching covered the following.

How to constrain an AI task
How to inspect generated changes
How to turn a repeated AI failure into a repository convention
How to review one another's PRs

Delivery work covered PR review at the merge gate, architectural judgment on escalations, implementation guidance on difficult changes, and direct build work on the specialist pieces Clixlogix owned.

The split shifted across the engagement. Early sprints carried more setup and close review. The middle carried the strongest delivery and architectural decisions. Later sprints saw the founders operating more independently while Clixlogix focused on difficult reviews, release confidence, and exceptional cases.

Architecture Decisions

Every consequential architectural decision landed as an Architecture Decision Record under docs/adr/. Four shaped the case study.

ADR 0001. Move off Replit into a founder controlled agentic environment

Clixlogix moved the application off Replit into a source controlled repository the founders own, with reproducible local development, testing, and release paths. AI assisted velocity continued from a base the founders could shape independently.

Staying on Replit with heavier custom scripting was examined and set aside. The platform tied source, secrets, and runtime into one vendor surface, and the roadmap required environments the founders could reshape without vendor consent.

ADR 0002. Two AI assistants, one repository authority

Clixlogix established the repository as the authority both assistants worked under. The working rule was one task, one human owner, one branch or worktree, one PR. AI assistants generate code. Humans and CI accept it.

AGENTS.md at the repository root held the canonical instructions for both assistants. Both Claude Code and Codex read AGENTS.md natively. CLAUDE.md was kept only when the repository needed Claude Code specific hooks or memory alongside the shared file. Both assistants received the same rules, the same task templates, and the same escalation triggers.

Standardizing both founders on one AI assistant was examined and set aside. Forcing one tool would have slowed one of the founders and eroded their ownership of the daily workflow.

ADR 0003. Medication schedule as a single canonical domain owner

The prototype calculated the next injection as the previous injection timestamp plus seven days. Multiple client surfaces could produce the same calculation with different behavior on late injections, backdated entries, daylight saving changes, and user time zone changes. Clixlogix moved schedule semantics into a single canonical domain owner used by web, iOS, Android, and notifications.

Time storage followed one rule across the model. Treatment intent stored local wall time, recurrence rules, and a selected IANA time zone. The schedule remained anchored to that time zone until the user explicitly changed it, while travel triggered a schedule review prompt. Completed injection events retained their UTC instant, captured local offset, and time zone context. This design preserved historical accuracy across daylight saving transitions and travel.

Keeping the calculation in each surface with shared unit tests was examined and set aside. Shared tests would still leave multiple implementations in place, and divergence risk would continue every time new AI assisted edits shifted a local implementation.

ADR 0004. Native iOS and native Android for the production mobile builds

The founders had built a small Flutter prototype for mobile. In weeks 3 to 4, Clixlogix guided the founders toward native Swift and native Kotlin for the production mobile builds. Six inputs converged on the decision.

Notification reliability concerns - The Replit web prototype's browser notifications stopped without warning, duplicated or missed events, and behaved differently across devices. The production mobile build had to deliver injection reminders at a reliability bar the web prototype had never had to meet.
Health permission behavior - Apple Health and Android Health Connect carry platform specific permission flows, revocation handling, and disclosure requirements. Each required platform native implementation regardless of the wrapper used.
Background execution - Synchronization, reminder rescheduling after dose or time zone changes, and offline log reconciliation all depended on operating system lifecycle behavior that an abstraction wrapper hides and complicates.
Founder preference - The Product and Design Founder wanted an experience that followed each platform's conventions, which raised the value of SwiftUI and Jetpack Compose over a cross platform runtime.
US commercial partner input - The US commercial partner raised expectations around launch readiness, disclosure language, platform behavior, and consumer health data handling. Those expectations raised the bar on platform level disclosure handling and reinforced the case for native.
Architecture session that closed the decision - A short capability spike ran against health permissions, reminder scheduling, offline shot logging, and authentication refresh. The capability spike supplied the decision evidence. The architecture session reviewed that evidence and closed the decision.

Fig 3 - Mobile Platform Decision

Native reduced integration and delivery risk for this team and this requirement set. Flutter can support health data, reminders, and background behavior with sufficient platform specific work. The founders and Clixlogix agreed that risk reduction sat higher than reuse for the mobile phase.

Four other routes were examined and set aside before the native decision landed.

A Progressive Web App
Extending the Flutter prototype
A Capacitor wrapper
Kotlin Multiplatform with native UI

Each either reduced control over the health APIs and reliable reminders, or added architectural surface the fixed cost delivery could not absorb.

Solution

The repository as the authority

Fig 4 - Guarded Delivery Gates

Clixlogix installed three levels of convention inside the repository. Written guidance covering what the team expected. Repository templates covering how work was submitted. Automated enforcement covering what could actually merge. The repository shape included AGENTS.md and CLAUDE.md at the root, engineering documentation under docs/engineering/, Architecture Decision Records under docs/adr/, agent task templates under docs/agent-tasks/, a CODEOWNERS file and a PR template under .github/, and a single scripts/verify command that both founders and CI ran identically.

Clixlogix codified four operating controls the founders could rely on across every AI generated change.

Schedule safety - Activated for injection, reminder, time zone, rescheduling, or missed dose changes. Required a scenario table and verified canonical schedule ownership.
Migration safety - Required expand, deploy, backfill, verify, contract thinking. Expand the schema, deploy compatible application code, backfill historical data, verify behavior and data, and remove the old structure in a later contract stage. Historical data fixtures, recovery instructions, and explicit handling of locks and defaults on populated tables accompany every migration.
Health data boundary - Reviewed logging, analytics, crash reporting, exports, and AI prompts for medication or health data leakage.
PR readiness - Checked Jira and ADR links, test evidence, migration notes, risk classification, and rollback instructions.

Secret protection sat outside the reasoning controls. Protected file hooks, a real secret scanner, CI, and environment separation held that gate deterministically.

The shared convention set

The repository held one convention set that both founders and both AI assistants read.

Coding style and formatter
Folder layout
Naming for files, functions, components, and database objects
Commit message format
PR description format
Test expectations before merge
Database migration rules
Secret and environment variable handling
Task decomposition rules for AI prompts

Each line was specific. The test convention line in AGENTS.md read, “New domain logic requires unit tests; bug fixes require a regression test; migration changes require historical data fixtures.” Both the founders and the AI assistants read that same line out of the repository. Specificity removed room for either assistant to invent its own interpretation.

The convention lines steered behavior. The machinery below enforced it. scripts/verify ran the deterministic checks, covering migration files paired with fixtures, domain changes paired with tests, and no secrets in prompts. CI ran the same checks before merge. The review rubric caught the cases where a change passed the deterministic checks and still missed the product rule. Together, the convention line steered the AI assistants, and the automation held the gate.

Folder rules named the directories where domain logic, API handlers, data access, UI components, and background jobs each belonged. A change that reached across those boundaries triggered a review question. Naming rules fixed the product vocabulary, covering injection event, treatment schedule, reminder occurrence, and dose unit, and the unit vocabulary, covering milligrams, kilograms, pounds, ISO 8601 timestamps, and IANA time zone identifiers. A new concept required an ADR before it could be introduced into code.

Commit messages followed a format that connected every change to its Jira task, risk class, affected contracts, and recovery note. PR descriptions carried the task template fields reproduced in order, covering user outcome, invariants, scope, acceptance, migration, and verification. CI rejected a PR with a missing field.

Migration handling followed one rule written into AGENTS.md. Every migration shipped with its forward step, its rollback plan, its historical data fixtures, and its verification query. No migration touched a populated table without the five stage expand, deploy, backfill, verify, contract plan recorded in the PR.

Secret rules kept credentials, API keys, and sensitive health data out of source files, logs, prompts, and fixtures. The secret scanner blocked matching signatures in CI. Health data in fixtures was synthetic.

AI task decomposition sat as its own section of AGENTS.md. A task was divided when it crossed more than one domain owner, combined a migration with interface work, or contained multiple outcomes that could be reviewed independently. Each subtask carried its own invariants and acceptance. The repository rejected a single prompt that produced a sweep of unrelated changes.

Clixlogix inside the repository

The Clixlogix senior technology lead and the specialist mobile engineers used Claude Code in the same repository, and worked under the same gate the founders did.

Clixlogix worked from separate worktrees or feature branches throughout the engagement.
Clixlogix engineers never edited an active founder branch.
Clixlogix implementation entered the codebase only through PRs.
Clixlogix engineers reviewed founder PRs against the shared rubric and had their own PRs reviewed by a second engineer against the same rubric.
CI configuration, branch protection, scripts/verify, the controls under .claude/skills/, and the ADR trail stayed under Clixlogix review. The founders could propose changes to the controls through the same ADR process the controls were created under.

The goal throughout was a progressive reduction in dependence on Clixlogix. The repository held the institutional knowledge, so founder independence increased across the engagement.

How the two assistants diverged in practice

Claude Code commonly proposed a broader refactor, additional abstraction, and richer defensive handling. Codex commonly produced a smaller change around the nearest repository precedent. The rubric below evaluated each change. The assistant's default never settled the decision.

The review rubric

Every PR passed through the same nine dimensions. The reviewer worked down the list and recorded a verdict against each one in the PR description.

Task scope and invariant compliance.
Domain ownership and reuse.
API and schema compatibility.
Error handling.
State lifetime and source of truth.
Test coverage.
Migration and recovery behavior.
Privacy and logging boundaries.
Release and rollback readiness.

Review Economics

Almost right is the expensive failure mode in AI assisted delivery. Stack Overflow's 2025 Developer Survey found that 66% of 31,476 respondents named AI output that is almost right as their main frustration, and 45.7% reported some distrust of AI accuracy against 32.7% reporting trust. Output at that quality passes its own unit test and still misses the product rule. A gate built only on automated checks clears exactly the changes that need a human, which is why this engagement treated senior review time as delivery capacity.

Fig 5 - Review Rubric Pipeline

Verification across test levels

Unit tests were the floor. Seven levels covered the product in total, and the PR gate and release gate ran different subsets.

Test Type 1, unit tests - Every PR. Cover domain functions, data selectors, and the behavior of one component in isolation. The floor every change had to pass before the gate opened to the richer levels below.
Test Type 2, API contract tests - Every PR. Enforce request and response shape between the backend, web client, and mobile clients.
Test Type 3, migration tests against populated fixtures - Every PR that touched a migration. Fixtures carried historical medication records, backdated entries, unit variations, and corrected events.
Test Type 4, schedule and time zone scenario tests - Every PR that touched the schedule domain, driven by a scenario table owned by the schedule-safety control. Scenarios covered late injections, backdated events, daylight saving, user travel, and schedule edits.
Test Type 5, subscription entitlement tests - Every PR that touched entitlement logic. Covered Apple, Google, and web purchase surfaces, renewals, grace periods, refunds, and restored purchases.
Test Type 6, mobile integration tests - Before every release. Run on simulators and a selected physical device matrix for iOS and Android.
Test Type 7, end to end tests for the core injection flow - Before every release. Signed in flow from logging an injection on the web, synchronizing to mobile, scheduling the next reminder, firing the local notification, and reconciling after a schedule edit.

The PR gate kept the fast levels close to the change. The release gate caught the integration behavior the fast levels cannot reach.

The reusable prompt library

AGENTS.md carried a compact set of standing instructions that both assistants read on every task. Six instructions did the work.

State the invariants first.
List what must remain unchanged.
Write the failing regression test first.
Deliver the migration and the recovery path together.
Identify affected contracts, covering API, schema, security, and data.
Stop for architecture review when the reversibility test fails.

Automation enforced deterministic behavior. Instructions supplied judgment, context, and escalation rules. Claude Code hooks ran the formatter after an edit, blocked edits to protected files, and ran scripts/verify in local mode before a PR could open. Codex workflow adapters performed the equivalent actions through its own skills integration. Both assistants also received the same reusable task templates under docs/agent-tasks/, covering feature task, bug fix, refactor, and database change. CI ran scripts/verify in CI mode as the authoritative gate behind both of them.

The escalation test

The operating test was written into AGENTS.md.

If a decision cannot be reversed cheaply in two months, it leaves the agent loop and enters architecture review.

The operating test, written into AGENTS.md

The line steered the author and both assistants. The task template and the PR template each carried a Reversibility field that the author had to classify before CI accepted the PR. Changes classified as hard to reverse required the Clixlogix senior technology lead as reviewer under CODEOWNERS and branch protection, and the Monday planning session was the architecture review venue. The convention set the direction. The forms, branch protection, and the Monday agenda enforced it.

The first successful guarded slice

Before the larger architecture examples, the workflow had to prove itself on a real change. The first guarded slice after the Replit extraction was a read only weekly progress insight card for the web dashboard. Clixlogix picked it deliberately. It carried real user value, it drew on existing weight and injection data, and it carried no destructive risk.

Clixlogix created two linked tasks with an agreed interface contract. Each task kept one owner, one branch, and one PR.

The interface contract came first. It named the input shape, the output shape, and the error behavior that connected the data module to the UI. Both tasks referenced the same contract.
Task 1 opened under docs/agent-tasks/ using the shared template. Owner, Technical Founder. Scope, the data selector and its regression tests covering representative histories. One branch, one PR. The Technical Founder used Claude Code.
Task 2 opened under docs/agent-tasks/ using the shared template. Owner, Product and Design Founder. Scope, the card UI built against the agreed interface and fixture data. One branch, one PR. The Product and Design Founder used Codex.
Each founder ran scripts/verify locally before opening the PR for their own task. Local mode returned ok across formatter, linter, type check, unit tests, migration check, health data boundary, schedule safety, task metadata, and ADR requirement. CI mode ran on each PR after it opened and checked PR description, Jira link, ADR link, reviewers, and merge requirements.
The Product and Design Founder reviewed the data PR against the rubric. The Technical Founder reviewed the UI PR against the rubric. The Clixlogix senior technology lead held the merge gate and approved each PR after confirming adherence to the task invariants.
The UI PR rebased after the data PR merged. The interface contract agreed up front governed integration between the two tasks.
The slice shipped behind a feature flag to the small beta group.

The sequence proved the operating model. Both founders could clone and run the repository. Claude Code and Codex followed the same conventions. Two tasks completed without overwriting each other's work. Each founder reviewed the other's contribution. CI enforced the required task metadata, verification results, review state, and merge conditions on both PRs. The merge gate accepted both PRs after each task passed founder review, automated verification, and Clixlogix approval. The operating model stood up on observed delivery.

Three moments where senior review saved the product

Three general failure modes repeat whenever founders vibe code at pace.

Failure Mode 1, local correctness and global drift - Each generated change solves the same problem a different way, so repository wide drift accumulates even when every change passes its own tests.
Failure Mode 2, tests confirm the implementation's own assumption - Tests repeat what the code does and miss the product rule, so a green test can confirm the wrong behavior.
Failure Mode 3, stateful changes treated as ordinary code edits - A migration or an auth change ships at the same cadence as a UI tweak when the escalation gate is absent.

The three moments below each sit in one of these failure modes.

The next injection date left the agent loop

Fig 6 - Separating the Event, the Schedule and the Reminder

A vibe coded implementation calculated the next injection as the previous timestamp plus seven days. The change passed its unit test. The Clixlogix senior technology lead escalated the change. The session surfaced late injections, backdated entries, daylight saving, user travel, and whether editing an old entry altered future reminders. The decision separated an injection event, immutable with corrections stored as a revision or superseding event, a treatment schedule holding user intent, and a reminder occurrence handling delivery. One canonical domain owner produced the next scheduled occurrence. ADR 0003 captured the model. A locally correct implementation did not become a system wide architectural constraint.

Rule Volatility

Scheduling logic looks stable while resting on data that changes without notice. The IANA time zone database, which records the history of local time and is updated as governments change offsets and daylight saving rules, shipped release 2026e on 29 September 2026 carrying a single line moving Manitoba to permanent minus five hours from 31 October 2026. Every surface computing its own next occurrence absorbs that change on its own timetable. One canonical owner was the cheaper position, because the correction lands in one place.

A migration that would have reinterpreted historical records

An AI generated migration dropped a medication_type column and added it back with a new default. The change passed on a fresh development database. Against production, it would have recast the meaning of every previously recorded entry, and rollback would have required restoring the prior column from backups. The migration-safety control required the full five stage sequence. Expand the schema, deploy compatible application code, backfill historical data with an explicit mapping function, verify counts and distributions, and remove the old structure in a later contract stage after every consumer had moved. An ADR recorded the mapping, and Jira captured the two cycle contract cleanup.

Health information nearly entering a third party telemetry surface

An AI generated crash reporting change added dose_mg and medication_name fields to a client side event to help diagnose an intermittent UI fault on the reminder screen. The change made bug diagnosis easier and passed every functional test. The health-data-boundary control flagged the third party crash reporter as a different data handling environment from the primary database. The change stripped identifying medication and dose from the client payload, logged an anonymized event class, and captured the diagnostic dose data only server side under the primary access controls. An ADR recorded the boundary rule.

CI answered whether the change violated a rule the team already knew how to express. The senior reviewer decided whether the change belonged in the system.

Decision closure in three linked records

A significant decision produced three linked records. An Architecture Decision Record captured context, options, selected approach, reasons, and consequences. The PR that implemented the decision linked the ADR. Jira captured the follow up work, migration steps, and deferred consequences.

Environment and deployment topology

Fig 7 - Five Stage Database Rollout

The challenge named one environment, one deployment path, and sensitive data sitting next to prototype data. Clixlogix closed that risk through an explicit topology.

Four environment tiers under separate credentials and separate data. Local on each founder machine, development inside the shared cloud account, staging as a production mirror, and production serving real users.
Secrets held outside the repository in a managed secret store, injected at runtime, rotated on a schedule, and never printed into logs or AI prompts.
CI controlled every deployment. No founder or Clixlogix engineer had direct write access to production hosts.
Database changes followed five stages. Expand the schema. Deploy compatible application code. Backfill historical data. Verify behavior and data. Remove the old structure in a later release after every consumer had moved to the new structure.
Feature flags gated user facing changes. New features shipped dark, enabled first for the small beta group, then for staged cohorts, then for all users.
Release recovery followed a documented rule. A merged change rolled forward with a fix when the change had no destructive effect. A destructive change required an explicit rollback plan recorded in the ADR and the PR before merge.
Mobile ran against one backend and one account identity. The server owned schedule semantics, entitlement, and medication history. The mobile client kept a local cache sufficient to log an injection offline, scheduled the local notification against the cached next occurrence, and reconciled on connectivity return. Each offline event carried a stable client generated identifier and entered an outbox. The backend accepted duplicate retries safely, preserved immutable injection history, and returned an explicit conflict when schedule intent changed on another surface. The web application, native iOS, and native Android all consumed the same backend contracts.

The founders moved from a single platform bound environment to a release path they operate themselves, with the operational risks named and controlled.

Delivery Tradeoff

Individual speed and system stability move in opposite directions under AI assistance. Google Cloud's Accelerate State of DevOps Report 2024 records that AI adoption significantly increases individual productivity, flow and job satisfaction while negatively affecting software delivery stability and throughput, and it points teams back to fundamentals such as small batch sizes and strong testing. That is the trade this engagement was built around. The founders kept the speed, and the controls held the delivery properties that speed erodes.

Native mobile engineering

Fig 8 - Server to Mobile Reconciliation

The mobile decision triggered the reversibility test. A short capability spike replaced model preference with evidence on health permissions, reminder scheduling, offline logging, and authentication refresh. Native delivery ran under the same repository conventions and the same review controls as the web product. Health permissions and notification reliability became acceptance criteria on every PR that touched them.

The Product and Design Founder stayed close to the mobile product experience. Figma held the flows and visual direction. Taste MCP produced small prototype screens and interactions on demand. Those assets became design inputs that Clixlogix converted into production native code under the shared repository conventions.

The server owns schedule semantics through the canonical domain decided in ADR 0003. The server returns versioned upcoming occurrences for the signed in user. Mobile clients cache the next occurrence, schedule the local notification, and reconcile the cache after a push, a foreground return, a time zone change, or a schedule edit. The result is one source of truth for schedule semantics and reliable local delivery on each operating system. Native technologies detail sits in the Technologies and Tools table below.

Health data direction

Apple Health and Android Health Connect carried weight only, and only what the user explicitly enabled.

Weight read permission was requested when the user turned sync on.
Weight write permission was a separate choice.
Sleep, activity, and heart rate were not requested, read, or written.
The product remained functional when the user declined any permission.
Imported records deduplicated through source metadata and timestamps so a weight written by a connected scale and read back through the health hub did not appear twice.

Subscription authority

The cross platform entitlement model carried one rule. Store transactions were validated by the backend. Apple notifications, Google subscription events, and Stripe webhooks updated one idempotent entitlement record used by every surface. The web, native iOS, and native Android apps all read entitlement from that record.

App Store release sequence

Fig 9 - App Store Release Sequence

iOS shipped first. The release ran through six ordered stages.

Stage #1 - Closed TestFlight covered the founders and a small invited group. Feedback cycles continued until the shortlisted journeys were stable.
Stage #2 - Health and privacy readiness aligned every HealthKit request with the required permission description. App Privacy declarations matched the weight data used by the product. The store copy framed the application as a tracking and education product.
Stage #3 - Subscription and entitlement readiness configured weekly, monthly, and annual auto renewing subscriptions, product identifiers, pricing, localized metadata, paywall mapping, restore purchase behavior, App Store Server Notifications, and the shared backend entitlement record.
Stage #4 - The review package combined a functioning reviewer account, seeded charts and reports, instructions for reaching optional weight sync, a working privacy policy, review notes, and accurate screenshots.
Stage #5 - App Review became an active iteration stage. Questions and requested changes returned to the release package, responses were recorded, and the approved native foundation moved into the App Store release.
Stage #6 - Follow on releases added the Apple Watch companion and HealthKit write back of manually entered weight. Android followed as its own fixed cost specialist workstream through Google Play once iOS was in review. Wear OS remained a separately scoped form factor outside the initial Android release.

The Flutter prototype

The Flutter prototype supplied navigation and interaction learning. Its design lessons carried into the production native applications.

Repository artifacts from The Client's delivery workflow

Three artifacts carried the conventions. A task template every AI task was written against, the output of the single verification command in both of its modes, and a review comment from the control that blocked a PR.

Task template excerpt

docs/agent-tasks/feature-task.mdmarkdown

# Task
## User outcome
What must be true for the user when this ships.

## Invariants
What must not change.

## Files or systems allowed to change
Explicit list. Anything outside requires a new task.

## Acceptance and negative cases
At least one negative or historical data scenario.

## Data migration and recovery plan
Expand, deploy compatible code, backfill, verify, contract.
Recovery path documented.

## Observability impact
New events, new logs, new metrics.

## Verification
Run scripts/verify. Report what was tested and what remains unverified.

The verification command in both modes

scripts/verify runs in two modes. Local mode runs on the founder's machine before a PR exists and checks the change itself. CI mode runs after a PR is opened and checks the PR context.

scripts/verifyterminal

$ scripts/verify
mode ..................... local
formatter ................ ok
linter ................... ok
type check ............... ok
unit tests ............... 342 passed
migration check .......... ok (0 destructive, 2 reversible)
health-data boundary ..... ok (0 findings)
schedule safety .......... ok (17 scenarios covered)
task metadata ............ ok (invariants listed, verification plan present)
adr requirement .......... ok (change not flagged for new ADR)
verify OK. safe to open PR.

scripts/verify --mode=citerminal

$ scripts/verify --mode=ci
mode ..................... ci
pr description ........... ok
jira link ................ ok (CLX-412)
adr link ................. n/a (change not flagged for new ADR)
reviewers ................ ok (2 approvals, Clixlogix merge-gate reviewer approved)
merge requirements ....... ok (branch protection satisfied)
verify OK. safe to merge.

Blocked PR comment excerpt

health-data-boundary review commentmarkdown

health-data-boundary blocked this PR.

Field `medication_name` was added to a `client_crash_event`
payload. `client_crash_event` routes to the third party crash
reporter. Medication identity cannot cross that boundary.

Options:
- Strip `medication_name` from `client_crash_event` and log an
  anonymized event class instead.
- Capture the diagnostic value server side under the primary
  access controls, referenced from the crash event by opaque id.

Please pick one, update the PR, and link an ADR under
docs/adr/ if this becomes a repeating case.

Where It Struggled

Area	What surfaced	How Clixlogix handled it
Prototype extraction	`Replit` hid runtime and configuration inside a single vendor surface	Clixlogix rebuilt a founder controlled repository with reproducible local development before any feature work continued
Two AI assistants on one repository	`Claude Code` and `Codex` produced code with different implementation defaults for the same problem	Shared `AGENTS.md`, one PR rubric, one `scripts/verify` command, and ADRs decided whose default carried in each case
Founder velocity against architectural risk	The founders wanted to keep shipping while decisions with long term consequences arrived every week	Weekly Monday planning session, the escalation rule written into `AGENTS.md`, and a senior reviewer at the merge gate
Cross platform prototype for a health product	`Flutter` covered visual parity and carried higher integration and delivery risk on notifications, background behavior, and health data for this team	A short spike supplied the decision evidence, and the mobile roadmap moved to native `Swift` and native `Kotlin`
App Store submission	The first submission required aligning `HealthKit` disclosures, permission language, and subscription configuration around sensitive weight data and cross platform premium access	Clixlogix iterated the disclosures, reviewer instructions, and backend entitlement model before release. The first release scoped the native foundation, and Apple Watch and `HealthKit` write back shipped later in the engagement
Cross platform subscription entitlement	One account operates across web, iOS, and Android with three purchase surfaces, covering Apple, Google, and Stripe on the web. Local store receipts could not be treated as the entire account state	One backend entitlement model reconciled all three purchase surfaces including renewals, refunds, grace periods, cancellations, expiration, and restored purchases

Table 2. What surfaced during delivery and how it was handled

Results

Clixlogix installed Guarded Delivery inside The Client's engineering workflow and delivered the native iOS and native Android builds under the same operating model. The Client kept vibe coding, and the merge gate held every AI generated change to a production standard.

A user community above 100,000

The community size The Client reported in its public communications after launch.

Over 1,500 public rating and review events

Aggregate rating and review events across the US App Store, Google Play, and Trustpilot.

4.7 of 5 on the US App Store

The rating on The Client's US App Store listing for the native iOS application.

4.9 of 5 on the Google Play listing

The rating on The Client's Google Play listing for the native Android application.

94 percent five star share on Trustpilot

The share of five star reviews on The Client's public Trustpilot page at this time.

Over 10,000 Google Play downloads

The download count displayed on The Client's Google Play listing for Android.

100 percent of production merges reviewed

Every production merge passed human review and a CI run, enforced by branch protection.

Community voice

The quantitative tokens above sit alongside recurring qualitative themes in public reviews across the US App Store, Google Play, and Trustpilot.

Clarity of the medication level visualization and the weekly progress report.
Reliability of Apple Health and Health Connect weight synchronization.
Usefulness of peer and clinical trial comparisons for people new to GLP-1 therapy.
Visibility of medication supply, including vials and pens, concentration, remaining supply, and refill timing.
Ease of daily logging across injections, side effects, hunger, cravings, mood, energy, sleep, and bowel movements.
Continuity between the browser experience and the native mobile apps on one shared account.

These themes come from public reviews. The themes are the signal the product reached its intended users and worked for them. They do not reflect Clixlogix's own quality assessment.

Economics

The founders deferred an early engineering team hire during the phase in which The Client's own engineering culture was still forming.

Traditional route - Three to five conventional engineers over the 18 week engagement represents roughly $141,000 to $235,000 in base salary at the current US software developer median, or roughly $184,000 to $306,000 with a 30 percent employment load. Excludes recruitment, management, onboarding, and equipment. The median wage reference is the US Bureau of Labor Statistics Occupational Outlook Handbook for software developers, which states $135,980 as of May 2025.
Guarded Delivery route - Fractional senior oversight from Clixlogix plus fixed cost specialist sprints for native mobile, priced as commercial contract line items. A fraction of the loaded cost of the traditional route during the same period.
What The Client kept - Product ownership, daily code output, direction of the mobile experience, and the ability to reallocate the deferred payroll into product, growth, and clinical education work.

The engagement converted an early fixed headcount commitment into fractional senior judgment, agentic founder execution, and specialist delivery purchased only where the product needed it.

What The Client Does Differently Now

The Client owns its development environments and its release path. Vibe coding continues, and AI assistance runs under repository level conventions that both Claude Code and Codex follow. The merge gate holds the production standard.

Architecture decisions arrive through the Monday planning session with a senior reviewer, and the Friday retrospective closes them. The founders keep shipping while the choices that carry long term risk get examined against alternatives and recorded as ADRs.

Mobile roadmap decisions run through the native iOS and native Android surfaces. Notifications, health data integrations, background behavior, and accessibility get engineered against each operating system directly.

Technologies and Tools

Area	Technology
Prototype origin	`Replit` (extracted in the first phase)
Repository authority	`AGENTS.md`, `CLAUDE.md`, `docs/adr/`, `docs/agent-tasks/`, `CODEOWNERS`, `scripts/verify`
AI coding assistants	`Claude Code`, `Codex`
Web application	Founder controlled repository, agentic development environments
iOS	`Swift`, `SwiftUI`, `URLSession`, Keychain, `UNUserNotificationCenter`, `HealthKit`, `StoreKit 2`, App Store Server Notifications, TestFlight, App Store
Android	`Kotlin`, `Jetpack Compose`, `Room`, Android Keystore, `Health Connect`, `WorkManager`, `AlarmManager`, `Firebase Cloud Messaging`, `Google Play Billing`, Play Store
Health data	`Apple Health`, `Android Health Connect`
Design inputs	Figma for flows and visual direction, `Taste MCP` for small prototype screens and interactions
Delivery model	Guarded Delivery (Scope, Generate, Harden)
Governance	Monday planning session anchored to CET, Friday retrospective, ADRs under `docs/adr/`, Jira for delivery state, Slack for coordination
Retired	`Flutter` prototype (design lessons carried into native builds)

Table 3. Technologies and tools across the engagement

Services Delivered

Vibe Coding Development, Vibe Coding Cleanup, iOS App Development, Android App Development, DevOps, IT Consulting, Architecture Decision Records, Code Review Rubric, Database Migration Safety, App Store Release Management

Team Composition

Senior Technology Lead, iOS Engineer, Android Engineer, Backend Engineer, DevOps Engineer, QA Engineer

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

Zoho CRM and multimodal AI stack for a New York independent home insurance agency

Zoho CRM Workflow and Multimodal AI Stack for a New York Independent Home Insurance Agency

Digital Engineering Zoho Generative AI & ML Consulting Service Enterprise Software

IoT farm management platform for a MENA AgriTech operator

Building an IoT Integrated Farm Management Platform for a MENA AgriTech Operator

Digital Engineering Emerging Technologies IoT Agriculture & AgriTech Enterprise Software

View All Vibe Coding Development Case Studies