Prompting Fundamentals

The quality of your prompts directly affects the quality of your app. These principles are based on patterns we see from users who consistently get great results.

Be specific and detailed

Vague prompts produce vague results. The more specific you are about what you want, the closer the first output will be to what you had in mind.

Vague:

Make a fitness app

Specific:

Create a workout tracker app that stores all data locally on the device. Include a home screen with today’s workout plan, an exercise library with muscle group categories, a timer for rest periods between sets, and a history tab showing past workouts in a calendar view. Use a dark theme with green accents and rounded card layouts.

You don’t need to write a novel — but include the details that matter to you. If you care about the color, say so. If you want a specific layout, describe it.

Tip

Primio generates standalone apps that run entirely on the device. For the best results, design features that work offline — local storage, on-device data, and self-contained logic. If your app needs a backend (user accounts, cloud databases, real-time sync), you’ll need to set up that infrastructure separately and tell the AI how to connect to it. See Integrations for backend setup guides.

Name your data sources and APIs

When you have a specific technical approach in mind — an API, a database, a library — say it explicitly. The AI won’t guess what you’re thinking. If you leave it open, it will pick whatever approach seems most likely, and that’s often not what you’d expect.

Without a named API:

Create an Apple-like weather app with realtime updates and location search

Result: The AI hardcoded a list of 1,000 cities. The app worked, but search was limited to those cities and the data wasn’t real.

With a named API:

Create an Apple-like weather app with realtime updates and location search, using Open-Meteo and the Geolocation API

Result: The AI integrated real API calls — live weather data and a proper location search that works for any place in the world.

Same app idea, very different outcomes. The only difference was naming the technical approach.

This applies broadly:

• “Store user data” → might use local variables, a JSON file, or a proper database. Say "Store user data in SQLite" for local storage. External services like Supabase or Firebase require separate setup — see Integrations for how to connect them.
• “Add a map” → could be a static image, Google Maps, or OpenStreetMap. Name the one you want.
• “Add authentication” → could be a mock login screen or a real Firebase Auth flow. Specify it.

Note

Why this happens: AI models generate the most probable next token, not necessarily the most practical solution. Tutorials and example code — which dominate training data — often use hardcoded data and mock implementations. Without an explicit pointer to a real API or service, that’s what the AI defaults to.

One feature per message

Breaking complex requests into individual messages gives better results than cramming everything into one. The AI can focus on a single task and get it right before moving on.

Instead of this single message:

Add a settings page, push notifications, and a sharing feature

Send three separate messages:

1. “Add a settings page with sections for notification preferences, theme selection, and account management. Use a list-style layout with toggle switches.”

2. “Add push notification support with an in-app notification bell icon in the top-right corner that shows a badge count.”

3. “Add a share button on each post that opens the native system share sheet with the post content and image.”

Each message builds on the previous result. You can verify each feature works before adding the next one.

Describe visual outcomes

Don’t just describe functionality — describe what it should look like. The AI makes design decisions for you when you don’t specify, and those decisions might not match what you had in mind.

Functionality only:

Add a navigation bar

With visual details:

Add a bottom navigation bar with 4 tabs: Home, Search, Create, and Profile. Each tab should have an outlined icon above the label. The active tab should be highlighted in blue with a filled icon. Use a subtle top border to separate the bar from the content.

Reference real apps

Mentioning existing apps gives the AI strong context for design patterns, UX flows, and visual style. Most popular apps have recognizable design patterns that the AI understands.

Build a task manager similar to Todoist — with projects in a left sidebar, tasks in the center panel, and task details in a slide-over panel on the right.

Make the onboarding flow feel like Duolingo — playful, step-by-step, with progress indicators and encouraging messages.

Design the profile page like Instagram — circular avatar at the top, stats row (posts, followers, following), then a grid of photos below.

Attach context

Plain text is good. Text combined with visual context is better.

• Attach a mockup image showing the layout or design you want
• Use @file: references to point the AI at specific code files to modify or use as reference
• Crop a screenshot of your preview to highlight a specific area
• Mention constraints explicitly: “This needs to work offline” or “Keep the existing header”

See Attaching Context for all the ways to add context to your prompts.

State constraints explicitly

The AI doesn’t know what you consider important unless you tell it. If something should NOT change, say so.

Add a search bar to the home screen. Don’t change the existing header layout or bottom navigation.

Redesign the profile card with a new color scheme. Keep the existing data fields and their order — only change the visual style.

Without these constraints, the AI might reorganize things to fit the new feature in a way that makes sense technically but isn’t what you wanted.

Iterate, don’t restart

When the result isn’t quite right, refine with a follow-up message rather than starting over. The AI knows the full conversation history and can make targeted adjustments.

The settings page looks great. Move the logout button to the bottom of the page and make it red with a confirmation dialog.

The card layout is good but add more padding inside each card and make the title text slightly larger.

Building on previous work is more efficient and preserves the parts you already like.

Be specific about bugs

Instead of asking the AI to “find and fix all bugs,” describe exactly what’s broken and when it happens.

Vague:

Fix all the issues in my app

Specific:

The login button doesn’t navigate to the home screen after authentication succeeds. It stays on the login page even after the success callback fires.

Even better (with file reference):

The login button in @file:lib/screens/login.dart doesn’t navigate to the home screen after auth succeeds. The signIn() method completes but the Navigator.push call on line 47 doesn’t seem to execute.

Caution

Vague prompts like “fix everything” or “make it better” can cause the AI to enter loops — making changes, finding new things to adjust, and consuming tokens without meaningful progress. Always be specific about what needs to change.

Quick reference

Principle	Do	Don’t
Specificity	”Add a blue bottom nav with 4 tabs"	"Add navigation”
Data sources	”Fetch weather from Open-Meteo API"	"Add weather data”
Scope	One feature per message	Everything at once
Visuals	Describe the look and layout	Only describe functionality
References	”Like Spotify’s playlist page"	"Make it look good”
Constraints	”Don’t change the header”	Assume the AI will preserve things
Debugging	”Login button doesn’t navigate after auth"	"Fix all bugs”
Iteration	”Move the button to the bottom”	Start from scratch

Next steps

Prompting for design

Learn design-specific prompting to get better visual results.

Advanced prompting

Go deeper with multi-step workflows and complex app architectures.