Skip to content
Primio Docs

Building a Complete App

Most successful Primio apps follow a four-phase process: build the foundation, add features one at a time, polish the details, then publish. Trying to skip phases or combine them leads to wasted tokens and frustrating results.

Phase 1 — Foundation

Section titled “Phase 1 — Foundation”

Recommended model: Auto or Opus

Your first prompt should describe the skeleton of your app: screens, navigation, data model, and visual style. Don’t request features yet. Get the structure right first.

A good first prompt looks like this:

Create a recipe app with 4 screens: Home (recipe grid with images), Recipe Detail (ingredients, steps, cook time), Add Recipe (form with image upload), and Favorites. Use bottom navigation. Dark theme with orange accents and rounded cards.

This gives the AI enough to build a complete, navigable app in one shot. Review the live preview and check:

  • Can you navigate between all screens?
  • Does the layout match what you had in mind?
  • Is the visual style right (colors, typography, spacing)?

If the foundation is wrong, roll back and rephrase. It’s much cheaper to fix the foundation now than to course-correct later with features already built on top.

Phase 2 — Features

Section titled “Phase 2 — Features”

Recommended model: Auto or Sonnet

Add features one at a time, verifying each before moving on. This gives you granular rollback checkpoints and lets the AI focus on getting each feature right.

Example feature sequence for the recipe app:

  1. “Add a search bar on the Home screen that filters recipes by name”
  2. “Add a category filter below the search bar — Breakfast, Lunch, Dinner, Dessert”
  3. “Add a favorites system — heart icon on each recipe card that saves to a favorites list”
  4. “Add a user profile screen accessible from the top-right avatar icon, showing saved recipes and preferences”
  5. “Add a settings screen with options for dietary preferences and measurement units”

Each message should describe one feature completely. Include visual details, placement, and behavior — not just functionality.

Use @file: references to direct changes to specific files when you know where the code lives. For example:

In @file:lib/screens/home_screen.dart, add a floating action button in the bottom-right corner that navigates to the Add Recipe screen.

See Attaching Context for more on file references.

Phase 3 — Polish

Section titled “Phase 3 — Polish”

Recommended model: Sonnet

With all features working, focus on refinement. This is where your app goes from functional to polished.

Design polish:

  • Adjust spacing, padding, and alignment
  • Refine colors and typography
  • Add smooth transitions and animations
  • Ensure consistent styling across all screens

Edge cases:

  • Empty states (what does the favorites screen show when nothing is saved?)
  • Loading indicators (what does the user see while data loads?)
  • Error messages (what happens when something fails?)
  • Long text handling (does the UI break with a very long recipe name?)

Code cleanup:

Open the Prompt Library and use “Review & Simplify Code” after major changes. This asks the AI to clean up the codebase without changing functionality.

Device testing:

This is critical. The web preview is not a device emulator. Build an APK (20K tokens) or use Web Hosting (free) and test on a real device. You’ll catch issues with scroll behavior, touch targets, animations, and platform-specific rendering that don’t show up in the preview.

Phase 4 — Publish

Section titled “Phase 4 — Publish”

Once your app is tested and polished, prepare for release.

  1. Set a custom app icon

    Go to Workspace → App Icon and upload your own icon. Don’t publish with the default template icon — stores may reject it, and users won’t take it seriously. See App Icon.

  2. Build and test on device

    Build an APK (Android) or IPA (iOS) and install it on a real device. Test every screen, every feature, every edge case. This is your final check before real users see it.

  3. Prepare your store listing

    Take screenshots on a real device. Write a clear app description. Choose relevant keywords. Create a feature graphic for Google Play. Write a privacy policy — both stores require one.

  4. Submit to app stores

    Follow the Google Play Submission Guide or App Store Submission Guide for step-by-step instructions.

Tips for the whole process

Section titled “Tips for the whole process”

Rollback early. If the AI goes in the wrong direction, don’t try to steer it back over five messages — that wastes tokens. Roll back to the last good state and rephrase. See Rollback.

Keep prompts focused. One feature per message. Verify before moving on. This gives you more rollback checkpoints and better results from the AI.

Match the model to the task. Opus for the foundation and complex features. Sonnet for general feature work, quick text changes, color tweaks, and small fixes. See Model Selection.

Test on a real device periodically. Not just at the end. Every few iterations. The web preview is a Flutter web build, not device emulation.

Common pitfalls

Section titled “Common pitfalls”
PitfallWhy it’s a problemWhat to do instead
Describing the entire app in one messageThe AI loses focus, misses details, produces a messy resultUse a phased approach — foundation first, then one feature at a time
Not testing on a real device until the endDevice-specific issues pile up and are expensive to fix retroactivelyTest after the foundation phase and periodically during feature development
Watching the AI loop on errors without interveningError-fixing loops consume tokens rapidly with diminishing returnsRoll back when you see repeated similar fixes — the AI is stuck
Skipping the custom app iconStores may reject apps with template icons; users won’t trust a generic-looking appSet a custom icon in Workspace → App Icon before building
Asking for too many changes at onceHarder to identify which change broke something; coarser rollback pointsOne feature per message, always

Next steps

Section titled “Next steps”