Documentation Index
Fetch the complete documentation index at: https://mayson.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
The mental model
Before anything else, understand what happens when you hit send.
When you submit a prompt, Mayson doesn’t just build a frontend. It generates a complete, deployed application: every screen, every API route, every database table, every middleware rule, and the infrastructure to run it all. Your prompt is the only brief it has.
This is why vague prompts produce vague apps, and specific prompts produce apps that feel designed. You’re not just describing a UI. You’re describing an entire product to a team of engineers and designers who will build it immediately, exactly as they understood it.
One prompt. Every layer. Done. The better your brief, the better the build.
Section 4: Iterating Effectively
22. Change one thing at a time
After the first build, each follow-up prompt should target one change. When you stack multiple changes, the Agent has to make tradeoffs and some changes land partially or get misinterpreted.
Focused prompt:
Change the navigation to a left sidebar. Keep the top bar for user settings only.
Change the navigation to a sidebar, redesign the dashboard cards, add a search bar, and switch to dark mode.
23. Be precise when correcting
When something doesn’t look right, describe exactly what to change and what to keep. Vague correction prompts often produce overcorrection.
Vague:
The cards don't look right.
The task cards feel too tight. Increase the vertical padding inside each card and add more spacing between cards in the list. Keep the card background, border, and typography exactly as they are.
replace, update, adjust, remove, increase, move, keep. Avoid: fix, improve, make it better. These give the Agent too much discretion.
24. Target the right layer
Every app has three layers you can iterate on independently. Knowing which one you want to change helps you write a more precise prompt.
| Layer | What it covers | When to iterate here |
|---|
| Design | Colors, typography, layout, spacing, components | Visual changes that don’t affect behavior |
| Logic | User flows, feature behavior, data operations | Changing what the app does, not how it looks |
| Data | Entities, relationships, fields, storage | Adding new data types or changing data structure |
Design change only, don't touch functionality. Make the sidebar narrower, switch the background to #0F0F14, and increase the font size on nav labels by 2px.
Logic change only, don't change any design. After a user submits a booking request, send them back to the dashboard with a success toast. Currently the page just reloads.
For developers: Layer isolation is even more precise in the Manual Builder. If you want to change a calculation in a specific API route without the Agent touching any other layer, open that route directly in the Manual Builder and edit the code block. Agent chat for broad changes, Manual Builder for surgical ones.
25. Agent chat vs Manual Builder: which to reach for
The Mayson Agent and the Manual Builder serve different purposes. Knowing which to use saves time and prevents unintended changes.
Use the Agent chat when:
- You want to add or change a feature
- You’re making design or layout changes
- You’re modifying how the app behaves end to end
- You want to add a new user role or flow
Use the Manual Builder when:
- You need to edit a specific API route’s logic without changing anything else
- You want to add a custom code block (string manipulation, hashing, conditionals, date logic)
- You need to adjust middleware rules or add request validation
- You’re modifying WebSocket behavior, queue workers, or async jobs
- You want to inspect the generated backend line by line
The Agent changes things broadly and fast. The Manual Builder changes things precisely. Use both, they’re designed to complement each other.
For developers: The Manual Builder is a block-based visual IDE with direct access to your generated Python backend. Every API route is broken into discrete code blocks: input parsing, validation, business logic, database operations, and response formatting. You can open any block, edit the code, add middleware, and redeploy without running the Agent again. The generated code is yours and there is no lock-in. You can export the full codebase at any time.
26. When to rebuild vs refine
Sometimes a project has drifted far enough from your original intent that iterating forward costs more time than starting fresh. This is normal, it’s not a failure of the tool or the prompting.
Think in milestones as you build: layout locked, core flows working, edge cases handled, data model confirmed. When you know where you are, you make better decisions about whether to push forward or reset.
Signals that refinement is the right call:
- The core structure is right but specific parts need adjustment
- You’ve made 3 to 5 focused changes and things are converging
- The overall flow and data model are intact
Signals that a rebuild is the right call:
- The first build misunderstood the app’s core purpose
- You’ve tried to correct the same thing more than twice and it keeps regressing
- You’re spending more time explaining what to undo than what to do next
- A new role or entity needs to be added that should have been there from the start
If rebuilding: take what you learned from the first attempt and write a stronger first prompt. The second build is almost always significantly better.
Section 5: Anti-Patterns
The clearest sign of a vague prompt is a vague app.
These are the most common prompting mistakes and how to correct them.
Anti-pattern 1: The vague prompt
What it looks like:
Build a social media app.
Anti-pattern 2: The implementation brief
What it looks like:
Create a Node.js backend with Express, a PostgreSQL database using Prisma ORM, and a Next.js frontend. Add a users table with email, password_hash, and created_at columns. Build a POST /auth/register endpoint.
Anti-pattern 3: The stacked request
What it looks like:
Add a search bar to the header, change the sidebar to dark mode, fix the card spacing on the dashboard, add email notifications for new bookings, and move the settings page to a modal instead of a separate route.
Anti-pattern 4: The missing visual direction
What it looks like:
A prompt with detailed feature requirements but no design guidance whatsoever.
Why it fails: The Agent will make reasonable default choices, but “reasonable” is not the same as “what you had in mind.” Changing design direction late in a build is expensive. It can affect dozens of components.
Fix: Add at least one sentence of visual direction to every first prompt. Even something as short as “dark mode, minimal, purple accent” meaningfully narrows the design space. For a more distinctive result, follow the guidance in section 8.
Anti-pattern 5: Asking Mayson to guess your business logic
What it looks like:
Add a subscription system.
Add a two-tier subscription system. Free users can create up to 3 projects. Pro users ($12/month) can create unlimited projects and access the export feature. Use Stripe for billing. Show an upgrade prompt when free users hit the project limit.
Anti-pattern 6: Correcting without context
What it looks like:
That's not right, make it better.
Section 6: App-Type Prompt Starters
These are starting points, not rigid templates. Copy them, fill in the brackets, and adapt them to your idea. Save your versions as you ship more apps. Over time you’ll build a personal prompt library that reflects how you think and what you build.
Each starter covers all five parts of the prompt anatomy.
Marketplace
App name: [Name]. A marketplace where [sellers: describe who they are] can list [what they're selling] and [buyers: describe who they are] can browse and purchase.
Seller side: create a listing with [fields: e.g. title, description, price, images, category], manage their listings, view incoming orders, track earnings.
Buyer side: browse all listings, filter by [attributes: e.g. category, price range, location], view a listing detail page, complete a purchase, leave a review after the order is complete.
Shared features: auth for both roles, messaging between buyer and seller, order status tracking.
Design: [visual direction].
App name: [Name]. A [category: e.g. project management / analytics / CRM] tool for [target user: e.g. solo freelancers / small teams / content creators].
The core job: [one sentence on the primary action the app enables].
Dashboard: shows [key metrics or summary] and [recent activity or quick actions].
Core workflow: [describe the primary feature step by step, what the user does, what the app does, what they see].
Settings: users can update [what, e.g. profile, notification preferences, connected accounts].
Design: [visual direction].
App name: [Name]. An internal tool for [team or company type] to [manage what, e.g. track support tickets / manage inventory / review applicants].
Not customer-facing. All routes require login.
Roles:
- [Role A]: can [specific actions].
- [Role B]: can [specific actions].
Core workflow: [describe the end-to-end process this tool manages].
Data tracked: [list the main entities, e.g. tickets, agents, users, products].
Design: functional and dense, optimized for frequent use. [Light/dark] background, [color accent], data tables where relevant.
Landing page + waitlist
Marketing landing page for [App name], [one-sentence description of what the product does and who it's for].
Sections (in order):
1. Hero: headline "[your headline]", subheading "[your subheading]", CTA button "[button text]"
2. Feature grid: three columns, [feature 1 name + one sentence], [feature 2], [feature 3]
3. How it works: three steps, [step 1], [step 2], [step 3]
4. Social proof: [testimonials / logos / stat callouts, or leave this out]
5. Waitlist signup: email input + submit button. On submit: save the email, show a success message inline. No redirect.
Design: [visual direction].
No backend dashboard needed. Just capture waitlist signups.
Browser game
App name: [Name]. A [game type: e.g. puzzle / arcade / strategy] game.
Core mechanic: [one sentence, what the player does and what makes it a game].
Rules:
- Win condition: [what triggers a win]
- Lose condition: [what ends the game]
- Scoring: [how points are earned]
Controls: [keyboard arrows / WASD / mouse clicks / touch, specify what]
Screens:
- Start screen: game title, high score, Start button
- Game screen: [describe the play area and key UI elements like score and lives]
- Game over screen: final score, Play Again button
Design: [visual direction, e.g. retro pixel art, dark neon, clean minimal].
E-commerce store
App name: [Name]. An online store where customers can browse [product category] and complete a purchase.
Product catalog: each product has a name, price, description, [number] images, category tags, and stock status. Products can be filtered by [attributes: e.g. category, price range, size, color].
Customer flow: browse catalog, view product detail, add to cart, checkout with shipping details and payment, receive order confirmation.
Account: customers can create an account to track orders and save their shipping address. Guest checkout also supported.
[Optional admin panel: manage products (add, edit, archive), view and update order status, track inventory.]
Design: [visual direction, e.g. clean and editorial, product-photography-forward, white background with strong typographic hierarchy].
App name: [Name]. A community platform where [describe who] can [core action: post, share, discuss, connect].
User profiles: display name, avatar, bio, [optional: location, expertise tags, join date]. Users can follow each other.
Content: users can create [content type: posts, questions, reviews, builds]. Each [post/item] has [fields]. Other users can [interact: like, comment, reply, bookmark, share].
Feed: the main feed shows [what: recent posts / posts from followed users / trending]. Users can filter or sort by [attributes].
Notifications: users are notified when someone [triggers: likes, comments, follows, mentions them].
Design: [visual direction].
App name: [Name]. An AI-powered [assistant / advisor / tool] for [target user] that helps with [specific job to be done].
Chat interface: users type a message and receive a response. Conversation history is preserved in the current session. Users can start a new conversation or continue a previous one from a sidebar list.
Context (if needed): [describe any context the AI should use, e.g. the user's uploaded documents, their stored preferences, previously saved data].
Output format: responses should appear as [plain text / formatted with markdown / structured steps / a card-based layout].
Saved outputs: users can [save, export, copy] individual responses to [where: their library, clipboard, a file].
Conversation sidebar: lists past sessions with auto-generated titles from the first message. Users can rename or delete sessions.
Design: [visual direction, e.g. clean minimal dark mode, terminal-inspired with monospace type, or warm and approachable with a centered chat layout].
Mobile app
App name: [Name]. A mobile app for [target user] to [core job in one sentence].
Navigation: [bottom tab bar with [number] tabs: [Tab 1 name], [Tab 2 name], [Tab 3 name]] OR [side drawer] OR [top tab bar with swipe between screens].
Core screen: [name and describe the screen users spend the most time on, what they see and what they can do].
Secondary screens: [list key screens and their purpose, e.g. "Profile: edit name, avatar, notification settings"].
Mobile interactions: [specify any touch-native behaviors, e.g. pull-to-refresh on the feed, swipe to dismiss notifications, long-press to open a context menu on list items].
Auth: [describe login method, e.g. phone number + OTP, email + password, or Sign in with Google].
Design: [visual direction suited for mobile, e.g. native-feeling with system typography and bottom-anchored CTAs, or branded with custom type and a defined color system. Specify light, dark, or auto mode].
