How a 5-Person Team Ships at 10×: AI-Native Engineering at eSimphony

eSimphony is built by a five-person engineering team. The product covers 150+ countries, ships native iOS and Android apps, runs a multi-region carrier integration stack, supports five languages end-to-end, and ships product changes weekly. We are not a thousand-person telco. We're a small team operating with deliberate leverage.

The leverage comes from a specific approach to engineering that we've internalized over the last 18 months. We call it AI-native development. This is what it actually looks like in practice.

The shape of the team

Five engineers. One product designer. One CEO who still writes some of the product specs. No formal product manager — specs come from CEO + Moza-assisted drafting + engineering judgment. No dedicated QA team — testing is part of the build loop. No separate DevOps — infrastructure is owned by whoever ships the feature.

This isn't a brag. It's a constraint. With this team size, the only way to ship a product at the scope of eSimphony is to multiply each engineer's output. AI is the multiplier we've leaned into.

The five-stage workflow

Every change at eSimphony — from a copy fix to a new carrier integration — moves through the same five stages. Each stage is AI-assisted; each stage has a human in the loop.

1. Discover (no tech barriers)

When a new requirement lands ("we need to integrate carrier X for Egypt coverage"), the engineer's first move isn't to assume what they don't know. It's to use AI to explore the unknown territory in 20 minutes instead of 2 days.

In practice: an engineer who's never integrated an Egyptian MVNO can prompt an AI assistant with the carrier's API docs, get a structured summary of the integration surface, ask follow-up questions about edge cases ("what's the typical eKYC flow for this market?"), and produce a one-page assessment of effort, risks, and unknowns before lunch.

What changes: the bottleneck is no longer "do we have an engineer who knows this domain?" It's "can the engineer we have, augmented by AI, become competent enough in this domain in a few hours?" Almost always, yes.

2. Spec (hours, not weeks)

Most product specs at most companies take 1–3 weeks: a PM drafts, stakeholders review, edge cases get added, acceptance criteria get refined, then engineering re-scopes. By the time a spec is "done," the original opportunity has shifted.

Our approach: the engineer (or CEO, depending on the feature) drafts a one-line product idea. AI expands it into a structured PRD — user flow, edge cases, success metrics, acceptance criteria, open questions. The team refines in a 45-minute working session. Spec is shipped to engineering the same day.

The trade-off: specs from this process are slightly rougher than a traditional 2-week PM-led spec. We accept that. The compression in time-to-first-implementation is worth the additional ambiguity, which gets resolved during build, not before.

3. Design (rapid feedback loop)

For features with significant UI, our designer works alongside the engineer in a "design-build-feedback" loop measured in minutes, not days. AI-generated mockups (Figma plugins + image generators) explore variants quickly. The engineer ships a prototype in a few hours. The designer reviews on real hardware. Iteration is measured in same-day cycles.

The result is that design and engineering aren't sequential — they're concurrent. By the time the design is "final," the implementation is already most of the way to production.

4. Build (AI writes the code; humans review every diff)

This is the most visible AI-native part. The engineering process at eSimphony today:

• AI generates ~90% of new code (Cursor, Claude, GitHub Copilot, often in combination)
• Engineers write the architectural decisions, the integration boundaries, the tricky business logic that requires deep system knowledge
• 100% of code is human-reviewed before merge. Every diff. Every PR. No exceptions.

This last point is critical and often misunderstood. "AI writes the code" doesn't mean "no humans look at the code." It means the engineer's role shifts from typing implementation to reviewing implementation. The cognitive work — does this match the spec, does this handle the edge cases, does this fit the architecture, does this scale — is still the engineer's. The mechanical work — translating intent into syntactically correct, idiomatic code — is delegated.

A typical PR at eSimphony has:

• 200–800 lines of code changed (vs traditional ~100–200 in 2024-era teams)
• 1 engineer reviewing in detail
• Often AI-generated unit tests with >80% coverage on new code
• Reviewer comments focused on architecture, not syntax

5. Ship (adapt in minutes)

Shipping is gradual: feature flags for risky changes, canary deployments for backend services, AI-monitored telemetry that surfaces anomalies within minutes of rollout. When a ship breaks something, the rollback is measured in minutes, not hours.

The "AI-monitored telemetry" piece is worth a sentence: post-deploy, an AI agent watches for anomalies in error rates, latency, user-reported issues, and conversion. When anomalies cross a threshold, the on-call engineer is paged with a summary of likely root causes. This compresses time-to-detection from "user reports a bug at 9am" to "alert fires at 09:03."

The numbers

Approximate metrics from the last 12 months:

• Sprint cycle: 1 week. New features ship weekly; small fixes ship daily.
• 5 engineers working full-time on product. One additional engineer contracting part-time.
• >90% of new code is AI-generated (Cursor + Claude primarily).
• 100% of merged code has been human-reviewed.
• Median time from feature spec to production: 5–10 days.
• Production incidents per quarter: 1–2. Below industry average for our scope.
• Customer support tickets escalated to engineering: ~5/week. Most are resolved within the same day.

These numbers aren't theoretical. They're the actual operating tempo of our team.

What this isn't

Worth being explicit about what AI-native development at eSimphony doesn't mean.

It isn't "vibe coding." Code is reviewed line by line. Architectural decisions are made by humans. AI accelerates the typing, not the thinking.

It isn't "no testing." AI-generated tests have specific weaknesses (they tend to test happy paths more thoroughly than edge cases), so engineers add hand-written tests for the edges. Test coverage is consistently above 80% on new code.

It isn't "no senior engineers needed." The opposite. AI dramatically raises the value of senior judgment, because senior engineers can review and refine AI output 5–10× faster than they could write it from scratch. Junior engineers using AI without senior review tend to produce code that compiles but is structurally fragile.

It isn't "no design or product thinking." AI is useless without clear specifications and well-thought-through user flows. The cognitive work of "what should we build, why, for whom" remains human.

What it requires

Three things, in order of importance.

1. Hard human review

Every line of AI-generated code passes through a senior engineer's review before merge. The temptation to skip review for "obviously correct" small changes is real and dangerous. We've held the line on 100% review.

2. Tight architectural guardrails

When AI generates code, it follows local conventions. Strong conventions = strong AI output. We've invested heavily in clear module boundaries, consistent naming, well-typed interfaces, and explicit documentation of "how we do things here" so the AI can pattern-match cleanly.

3. Cultural acceptance of AI as the default

The team has agreed, explicitly, that AI assistance is the default in every workflow. New engineers are onboarded into this default. Pushback ("but I prefer to write it myself") is heard and discussed, but the team norm is that AI handles the mechanical work unless there's a specific reason it shouldn't.

What we don't use AI for

• Reviewing AI-generated code (we want fresh human eyes)
• Deciding what to build (product strategy is human)
• Direct customer support escalations (humans handle the hard cases)
• Performance reviews and team feedback (human-only)
• Hiring decisions (humans-only, augmented by AI for sourcing and screening)

The pattern: AI augments execution; humans own decisions.

Why this matters for the product

The output of this workflow is visible in the product. We've shipped:

• Lifetime eSIM architecture (a multi-quarter project at most companies)
• Moza, the AI travel companion, in five languages
• AI Dynamic Plans across three regions
• AI Troubleshooting with auto-heal
• Native iOS and Android apps with weekly releases
• Multi-region backend with 99.9%+ uptime
• 5-language localization across the full product surface

This list normally requires 30–50 engineers and 3+ years. We've shipped it with 5 engineers in 18 months.

A note on recruiting

We're growing the team carefully. The engineers who do well here share three traits:

1. High judgment over high output. AI handles the typing; we want engineers who excel at reviewing, deciding, and shaping.
2. Comfortable with AI as a peer. Engineers who treat AI as a co-worker (delegate to it, review it, push back on it) rather than as either a magic oracle or a threat to their identity.
3. Care about the user. AI-native workflows are fast enough to produce a lot of code that compiles but doesn't matter. Engineers who can ground every PR in "does this help the user" produce the best work.

If that's you, we're hiring. Reach out via the careers page or message Trung directly.

What ships next

The same workflow that built the current product is shipping the roadmap:

• Multi-eSIM management (May 2026)
• Family plans (June 2026)
• Loyalty and rewards (August 2026)
• Worldwide direct-carrier coverage (2027)

Each of these is a multi-month project at a traditional telco. Our internal estimates have all four shipping on schedule, with the same five-person team.

That's the leverage. That's the bet. That's how a small team ships against an entire industry's worth of inertia.

See eSimphony in action, read about our positioning, or check our pitch deck from MVNO Nation Americas.