Sprint Zero at SEM Nexus: How We De-Risk Your Build in the First Two Weeks

Most mobile-app builds quietly go wrong in sprint zero. The team spends two weeks setting up infrastructure, configuring CI, arguing about folder structure, and producing nothing the founder can touch. By the end of sprint zero, the team's velocity looks fine on paper, but no actual product risk has been retired. The hard parts of the project — audio engineering, real-time location, payment integration, App Store review for medical content — are still ahead, still unaddressed, still potential 4-week slips.

SEM Nexus treats sprint zero as the highest-leverage sprint in the build. We retire the highest technical risk first. We get a runnable artifact onto a real device by the end of sprint 1. We prove the stack choice in production-like conditions before the rest of the build commits to it. This post is what sprint zero looks like at SEM Nexus, and why most agency-built apps would benefit from copying the discipline.

What sprint zero is and isn't

Sprint zero is not "setup." Setup is configuring the toolchain, creating the repo, wiring up the CI pipeline, scaffolding the project. That work happens, but it isn't the goal — it's overhead. If your agency's sprint zero deliverable is "the project is set up," you've paid for two weeks of nothing.

Sprint zero is risk retirement. The goal of sprint zero is to identify the one or two things in your project that could cause it to slip by 4+ weeks, and prove they're solvable inside the planned timeline. That happens by getting something working, on a real device, against the production-like environment, before any of the easier work is committed.

The distinction sounds semantic. It isn't. It's the difference between a build that ships on time and a build that slips by months.

The SEM Nexus sprint-zero pattern

Week 1: setup + the highest-risk prototype

In the first week:

Repo scaffolded with the chosen stack (Flutter, React Native, Angular + Ionic, or native)
CI pipeline running tests on every push
Crash reporter wired (Sentry or equivalent)
Basic auth flow stubbed
A 50–200-line prototype of the highest-risk feature, running on a real device by end of week 1

That last bullet is what makes sprint zero risk-retiring instead of setup. The prototype isn't the production version — it's the "does this approach actually work" version.

For Cerebyte, the highest-risk prototype was an audio engine playing back a real EEG-derived composition on a real iPhone, end of sprint 1. Latency target met. The Flutter + Dart FFI architecture was validated before the rest of the build committed to it.

For My Home Delivery, the highest-risk prototype was a Stripe Connect multi-party payment with a customer account, a driver connected account, and a platform take, running through a sandbox transaction by end of sprint 2. The model was proven before downstream sprints assumed it.

For 360 Medical Consulting, the "prototype" was the HIPAA-compliance audit of every third-party vendor and a written BAA inventory. The compliance was the highest risk, not the engineering — so the risk was retired in the compliance plane.

If your project has a hard part — and almost every project does — SEM Nexus's discovery names it in writing and the sprint-zero prototype retires it in week 2. The downstream sprints can then assume the hard part is solved.

Week 2: the spine

In week 2:

Authentication end-to-end (real users can log in)
The primary screens with placeholder content
The core flow demonstrated end-to-end on a real device
A first-pass design system implemented
The CI pipeline running on every commit, with at least basic test coverage

By the end of sprint zero, the founder can hold a phone in their hand and walk through the central flow of the app. It's ugly. It's incomplete. It's running on a real device, with real auth, against the real (or near-real) back-end. Stakeholders can react to the product, not the deck.

This is what most agency builds skip because it's harder than it sounds. Connecting the spine first — instead of polishing screens before they connect — requires discipline that comes from senior engineers who've seen the failure mode before.

What "the spine" means in practice

The spine is the central narrative of the app. For different apps it looks different:

B2B SaaS companion: log in, see your dashboard, take the most-used action
Marketplace: customer browses, books, pays; provider sees the booking, accepts, completes
Wellness/content: log in, browse the catalog, play one piece of content, complete the session
Healthcare patient portal: log in, view appointments, message provider, view records

If a stakeholder can walk through this 60–90 second narrative on a real device at end of sprint zero, the project's product risk is materially reduced. They can see the flow. They can react to it. They can object to it. All the objections happen in week 2, not week 14.

Why this matters: the slip math

If a major architectural problem surfaces in week 2, fixing it costs 1–2 sprints. The total build still ships on time.

If the same problem surfaces in week 8, fixing it costs 4–6 sprints because downstream work has been built against the broken assumption. The total build slips by 2 months.

If the same problem surfaces in week 14, fixing it requires a rewrite. The total build slips by 3+ months or doesn't ship at all.

The cost of finding architectural problems is roughly exponential in how late they're found. Sprint zero is the only sprint where finding a problem doesn't blow the timeline. SEM Nexus optimizes sprint zero ruthlessly to find every problem we can find.

Three problems sprint zero catches that other sprints miss

Wrong stack for the hard part. If the prototype reveals the stack fights the hard part (e.g., RN's audio libraries can't handle the latency target), we switch stacks in week 2 instead of week 10. We've done this — switched Flutter to native, switched RN to Flutter — when the prototype made the answer obvious.

Integration shows are not what the docs promised. Vendor APIs have a way of being subtly different from documented behavior. A sprint-zero integration prototype against the real vendor sandbox catches this. A "we'll integrate later" build doesn't.

The founder's mental model of the product doesn't survive a real device. Sometimes the founder's vision works in Figma and doesn't work on the phone. Sprint zero produces a real-device version specifically so the founder can react to it before the rest of the build commits to the vision.

What sprint zero costs (and what skipping it costs)

Sprint zero costs about 10% of the total build budget. For a $100k build, sprint zero is roughly $10k of engineering effort.

Skipping sprint zero — running a "let's just start building features" sprint pattern — costs about 30% of the total build budget on average. The 30% is the rework caused by problems found late. You pay either way; the question is whether you spend $10k upfront or $30k late.

We always spend it upfront. Every SEM Nexus build has a sprint zero. Every one.

What this looks like for your project

Three things you should expect:

By end of week 2, you can hold the app on a real device and walk through the central flow. Not a Figma prototype, not a TestFlight stub — a real running app.
The highest technical risk of the project is named in writing, with a prototype that demonstrates it's solvable. If we couldn't demonstrate it, we'd be honest about that in the week-2 review.
The architectural decisions made in discovery are validated or revised based on what sprint zero surfaced. No build-on-broken-assumptions.

If your prior builds slipped, or if you've never shipped a mobile app and you'd like the build to ship on time, the sprint-zero discipline above is the single highest-leverage practice in mobile development.

If you'd like sprint zero applied to your project, SEM Nexus's two-week discovery is the prerequisite — and the build sprint zero starts the day discovery ends. Most agency builds don't run sprint zero this way. The ones that do ship on time.