Skip to content
Ryan ViajedorMobile Team Lead
Process

How I build production mobile systems

From product goals through architecture, testing and automation to a release that can be repeated.

Six steps, end to end
  1. Understand

    Product goals, users, requirements, constraints.

    Before any architecture decision, get clear on what the product has to do and what it has to survive — the devices it runs on, the networks it runs over, and the constraints that won't move. Most expensive mobile rewrites trace back to a constraint nobody named early.

    • Product goals and success criteria
    • User flows and platform expectations
    • Technical and delivery constraints
  2. Architect

    Architecture, APIs, state management, scalability.

    Decide the shape of the codebase while it's still cheap to change. Module boundaries, how state moves, and what the API contract guarantees — chosen so the second year of feature work costs about what the first did.

    • Module boundaries and layering
    • State management and data flow
    • API contracts and error handling
  3. Build

    Flutter and native Android/iOS where appropriate.

    Write the product, reaching for native where the platform genuinely differs and sharing code where it doesn't. Cross-platform is a default, not a rule — some things belong in Kotlin or Swift, and pretending otherwise costs more than the shared code saves.

    • Flutter for shared product surface
    • Native where the platform demands it
    • Reviewed in small, releasable increments
  4. Validate

    Testing, performance, reliability, crash monitoring.

    Prove it holds up before users do. Automated tests around the logic that matters, performance checked on real devices rather than the newest one, and crash reporting wired in from the first build so production tells you the truth.

    • Unit and widget test coverage
    • Performance on representative devices
    • Crash and error monitoring in place
  5. Automate

    CI/CD, Fastlane, automated builds and releases.

    Take the humans out of the release path. Builds, signing, and store uploads run the same way every time, so a release is a pipeline run rather than an afternoon — and the person who knows the incantation stops being a dependency.

    • CI on every change
    • Fastlane for signing and upload
    • Repeatable beta and production tracks
  6. Ship

    Production release, monitoring and continuous improvement.

    Release, then watch. Staged rollouts so a bad build reaches few people, monitoring that surfaces problems before reviews do, and a feedback loop that turns what production teaches into the next iteration.

    • Staged rollout and release monitoring
    • Store feedback and crash triage
    • Iterate on what production reveals
Philosophy

Build for production, not just for demo day.

A mobile product isn't finished when the code compiles. It has to be tested, automated, released, monitored and maintained. The work I care about is the whole lifecycle — from the first product requirement to what production teaches you afterwards.