Before You Build

1. Plan before you prompt

The most common reason a first build misses is that the thinking happened inside Mayson instead of before it. Take five minutes to answer four questions:

• What is this app and what does it actually do?
• Who are the users, and do they have different roles?
• What is the one core action the app exists to enable?
• What should it look and feel like?

You’re not writing a spec. You’re setting direction. Use notes, voice memos, a napkin sketch, anything that forces you to articulate the idea before the Agent tries to interpret it.

Good first prompt:

Build a freelance marketplace where designers can list services and clients can book them.

Roles: designers and clients. Designers create a profile with name, hourly rate, portfolio images, and skill tags. Clients browse, filter by skill, and send a booking request with a project description and date range.

Design: clean and minimal, white background, subtle card shadows, professional tone.

Include: auth for both roles, a booking request flow, and a dashboard per role showing active requests.

Underprepared prompt:

Build a marketplace for designers.

Both will produce an app. Only one will produce the right app.

---

2. Read the PRD before you evaluate the build

Before Mayson writes a single line of code, it generates a Product Requirements Document from your prompt. This PRD covers the app’s purpose, user roles, features, data entities, screen list, routes, and UI direction, all interpreted from what you wrote.

This document is the Agent’s understanding of your brief made visible. Read it.

The PRD tells you exactly what the Agent thinks you’re building. If it lists two roles and you only described one, that’s the Agent filling in a gap. If the feature list includes something you didn’t ask for, or omits something you did, you’ll see it here before the build runs.

What to check in the PRD:

• Does the app description match what you actually want to build?
• Are the user roles correct, and are their permissions described accurately?
• Is the feature list complete? Is anything missing or added that you didn’t ask for?
• Do the listed screens cover the full experience you described?
• Does the data model (entities and relationships) reflect your intent?
• Does the UI direction match your design brief?

If something in the PRD is off, the build will reflect that misunderstanding. Use the Agent chat after the build to correct it precisely. The PRD also gives you the language to do that clearly: “The PRD listed X but I meant Y” is a much more effective correction than describing the problem from scratch.

For developers: The PRD includes the generated database schema (tables, columns, relationships) and the API surface before any code runs. This is the fastest way to verify that the data model is structurally correct. If you catch a missing field or a wrong relationship in the PRD, flag it in your first post-build correction and the Agent will update the schema and regenerate the affected routes.

---

3. Understand what you’re generating

Most tools build one thing. Mayson builds everything at once. When you submit your first prompt, the Agent generates:

Layer	What gets created
Frontend	All screens, components, navigation, and layout
Backend	API routes, business logic, data processing
Database	Tables, relationships, indexes, based on your described entities
Middleware	Auth guards, validation, request handling
Infrastructure	Hosting, deployment, environment config

You never need to specify how any of this is built. You only need to describe what the app should do. The Agent handles implementation. Your job is intent.

For developers: You’re giving the Agent a product brief, not a technical spec. Avoid specifying frameworks, schemas, or endpoint naming conventions in your initial prompt. The generated backend is Python-based. Once the app is generated, the Manual Builder gives you block-level access to the full backend if you need to make precise changes to any route, middleware rule, or code block.

---

4. Define your users and roles upfront

Roles are one of the most structurally significant things in any application. They determine what each user can see, do, and access, and they shape the entire information architecture.

If your app has more than one user type, define both in your first prompt. Don’t add a second role mid-build if you can avoid it. It’s much harder to restructure around roles than to generate with them from the start.

Prompt with roles:

Two user types: admins and members.

Admins can create projects, invite members, assign tasks, and view all activity. Members can only see projects they've been added to and update the status of tasks assigned to them.

What to specify per role:

• What they can see
• What they can do
• What they cannot access
• Whether they have a distinct dashboard or view

---

5. The anatomy of a strong first prompt

A well-structured first prompt has five parts. You don’t need headers or bullet points, you just need to cover all five.

Part	What it covers	Example
App identity	What it is and what it does in one sentence	”A task manager for small teams”
User roles	Who uses it and what each role can do	”Managers assign tasks, team members complete them”
Core features	The key things the app must do	”Task creation, assignment, due dates, status updates”
Data entities	The things your app tracks	”Tasks, users, projects, comments”
Visual direction	How it looks and feels	”Clean, minimal, card-based, blue accent”

You don’t need to write an essay. A prompt that covers all five in a short paragraph will outperform a vague two-sentence prompt every time.