Frequently asked questions

Do I need to know how to code?

No. Describe the user, outcome, workflow, and constraints in plain language. Code and Terminal remain available for people who want deeper inspection.

Start with the business words your users already understand. Mango9 can decide how to structure the application and can explain technical choices in Ask when you are curious. You remain responsible for approving the product result, not for writing its implementation.

Example: “Help warehouse staff receive stock and see low inventory” is enough to begin; you do not need to name a database table or framework.

What can Mango9 build?

Responsive web products such as websites, portals, dashboards, CRMs, booking tools, internal apps, directories, and marketplaces. Mango9 can also build a dedicated mobile interface with independent mobile versions and selected device capabilities. From Native build, Mango9 can compile an installable Android test package and create a signed iOS package after the customer connects Apple Developer.

The strongest results begin with a clear audience and core workflow. A project can grow from a simple first release into a larger product through focused builds. A phone-sized web preview alone is not a native package: use Mobile Studio for the app interface and Native build for the platform artifact. External services, persistent production data, store accounts, policies, and device testing still need their own connections and review.

Example: Build the field-service dashboard for dispatchers on the web, then create a dedicated technician app in Mobile Studio. Build an Android test package directly, or connect Apple Developer and build the signed iOS package from the approved mobile version.

Should my first prompt include the whole product roadmap?

Describe the overall product, but choose a focused first usable release. Broad future ideas can remain context; build and verify the core workflow before expanding it.

Separating “must work now” from “useful later” helps Mango9 build a coherent foundation without pretending the entire roadmap is finished. The first release should still complete one real task end to end.

Example: Start a marketplace with listings, search, inquiry, and seller management. Leave auctions, loyalty rewards, and international tax for later releases.

Should I use one large prompt or many tiny prompts?

Use one coherent feature slice at a time. A prompt should be large enough to produce an end-to-end useful outcome, but not combine unrelated redesign, billing, integration, and workflow changes.

Related pages and server behavior can belong in one slice when one user action needs them all. Split work when the pieces have different reasons, acceptance checks, or risks. This makes verification and recovery much clearer.

Example: Build lead intake, saved lead detail, and assignment together. Build a new brand style in a separate turn.

What is the difference between Ask and Build?

Ask discusses without intentionally changing the app. Build creates or changes the project. Ordinary conversation in Build can be answered without forcing a mutation, but Ask is the clearest choice for planning.

Choose based on the outcome you expect. If you want knowledge or a decision, use Ask. If you expect a changed Preview or saved project state, use Build. You can move an agreed Ask direction into Build later.

Example: Ask, “What should the owner dashboard prioritize?” Build, “Add the agreed overdue jobs and daily revenue cards.”

Can I build from a screenshot?

Yes. Attach it and say exactly what to borrow—layout, hierarchy, spacing, tone, or a specific defect. State what must remain from your existing app and make sure you have the right to use supplied assets.

A screenshot is evidence or inspiration, not an automatic instruction to copy everything visible. Crop to the important area when possible and identify the route and device for defects. Keep another company's branding and protected content out of your result.

Example: “Use this screenshot for compact card spacing only. Keep our colors, wording, navigation, and images.”

Can I edit the code?

You can inspect project code and use prompts to request focused changes. Direct code capabilities depend on the controls and permissions available in your project workspace.

Most users should prefer a Build prompt because Mango9 can inspect surrounding behavior and verify the result. Direct editing is appropriate when an advanced user intends to maintain that change and understands the consequences. Code access never makes secrets safe to place in source.

Example: Ask Build to add an order filter and preserve existing permissions; use Code view afterward to inspect which files changed.

How do I know what changed?

Review the build summary, Preview, visual proof, version badge, and View changes/System version history. Provider narration alone is not proof that a mutation happened.

Each source answers a different question: the summary explains the outcome, Preview proves behavior, visual proof captures relevant rendered surfaces, and the version/change list proves durable scope. Use them together for important work.

Example: Chat says Leads was added; App Map and Preview should show the route, navigation should reach it, and View changes should identify the saved version.

Can I undo a change?

Use project version recovery for development changes. Use Production Cloud rollback for an earlier live deployment. They are separate actions.

Inspect an older development version before restoring it, because restore changes the current project state. A production rollback affects what customers use but does not automatically rewind an external database.

Example: Restore development v6 to continue from an approved layout. Roll back production only when a newly published release is harming customers.

Why is the first project build asking questions?

The brief questions settle product decisions that a short prompt may leave ambiguous: users, essential records, workflow, access, and first-release scope.

They are product questions, not a technical examination. Select all genuinely necessary choices when the question permits multiple answers, use the recommended option when it fits, and provide a custom answer when an important detail is missing.

Example: A CRM may serve both sales reps and managers, with lead capture and deal closing required in the first release.

Why does my app need a database?

If real users create shared records, accounts, bookings, orders, or other persistent information, production needs a durable Postgres database. A static content site usually does not.

The development preview can demonstrate data-driven screens with sample data, but the live app needs a reliable place for real records across restarts and deployments. The external database provider remains responsible for backup and recovery controls.

Example: A restaurant menu can be static. A waitlist shared by several hosts needs Postgres.

Can I publish without a database?

Yes when the classified release does not store persistent server data. If Mango9 detects data-dependent behavior, it requires a reachable Postgres connection before publishing.

This check prevents an app from appearing live while silently losing records. It is based on project behavior, not on whether the site looks simple or complex. Connect the database through the protected product controls when required.

Example: Publish a portfolio without Postgres; connect Postgres before publishing a customer portal with accounts and saved documents.

Is Preview already live for customers?

No. Preview is the development environment. Publish creates or updates the production release and live address.

Preview can sleep, show work in progress, and use development context. Production remains on the last approved deployment until an authorized person publishes a newer version.

Example: A completed homepage redesign can be visible in Studio Preview while customers still see the previous homepage at the custom domain.

Can I buy a domain before my app is published?

Yes. Buy it and keep it parked. Domain assignment and connection are limited to a published project.

Parking protects the name without pointing it at an unfinished app. Registration and renewal continue independently of project status, so review the current price and account ownership before purchase.

Example: Buy northstarcrm.com now, park it during development, and assign it after the CRM is live.

What happens to my domain if I delete a project?

The domain survives independently and becomes available to park or reassign. Project deletion is not domain cancellation.

Open Domains afterward and choose the intended next state. A parked domain can continue renewing even with no connected app, while cancellation is a separate domain operation.

Example: Delete last year's event project but park summerexpo.com for next year's replacement.

Does publishing use AI credits?

Use the Publish control rather than a builder prompt. Publishing and production infrastructure follow the plan/hosting billing shown in Mango9; AI wallet credits cover metered builder work.

The protected Publish workflow classifies the app, prepares required infrastructure, and records the deployment. Asking the builder to “publish” can create unnecessary AI work without replacing those account controls.

Example: Finish the build, inspect Preview, then press Publish and review the production plan shown there.

Why did a focused change use more credits than expected?

The model may need to read surrounding project context, use tools, and verify several surfaces. Larger projects, broad prompts, more capable tiers, images, and repair work can increase usage. Keep each prompt specific and review before continuing.

The visible size of the final answer is not the full amount of work. Use the transaction details and build usage summary to understand the selected mode, project, and charge. Avoid overlapping requests that ask the model to reread the same large project unnecessarily.

Example: A one-line shared-menu fix may still inspect routes, permissions, desktop layout, and mobile layout before safely changing two files.

What is production compute?

Dynamic apps need a server while awake. Production usage can include compute, service, and egress items per project. Static edge-hosted apps have a different cost profile.

Choose production compute for measured behavior, not merely for the number of pages. A small dashboard with active users and server work can need more compute than a large static site.

Example: A static documentation site serves many pages from the edge; a live order system uses dynamic compute to authenticate users and process records.

Where should I put API keys?

Environment Variables or the appropriate Integration. Never put a secret in chat, public browser variables, source content, screenshots, or documents.

Refer to the variable or integration by name in the Build prompt. If a value is exposed, revoke it with the provider and create a replacement; deleting the visible message is not enough.

Example: “Use the existing RESEND_API_KEY server-side” is safe. Pasting the key itself is not.

Can teammates work on the same account?

Yes. Invite them under Team and assign the least-privileged role that fits their work. Do not share one owner login.

Each member should use their own email and can be limited by role and project. This preserves attribution and lets the owner remove one person's access without disrupting everyone else.

Example: Give a designer Builder access to one project and give finance Billing access without source or production controls.

Why can’t my teammate publish or view billing?

Those are separately permissioned operations. An account owner/admin can review the role.

Also confirm that the teammate belongs to the intended account and has access to the selected project. Seeing one control does not imply authority for every operation, and a server-side Forbidden response may be the correct enforcement.

Example: A teammate can edit the CRM but cannot publish until the owner grants publishing permission.

What should I do if a build seems stuck?

Do not send duplicates. Let the active operation reach progress or an actionable result, Stop only when appropriate, and record the project/time/phase if support is needed.

Some tools and providers are quiet for longer than ordinary narration. A useful stall report distinguishes elapsed time from durable activity, status changes, or a final result. Stop ends the turn; it is not a pause button.

Example: Record “Project 345, 12 minutes on Thinking about it, no new version or Preview change” instead of submitting the same prompt again.

Will Mango9 keep making changes after I publish?

Development can continue, but production changes only when an authorized user publishes a new version.

This lets you experiment safely after launch. A new development version can be reviewed, restored, or discarded without moving the customer-facing deployment.

Example: Build a new reports page in Studio for a week while the current production CRM remains unchanged.

Can Mango9 connect external services?

Yes when the service and required credentials are supported by the project. Use scoped credentials, test errors as well as success, and keep secrets server-side.

Save the credential in Integrations or Environment Variables, link it to the correct project, and build one end-to-end workflow. Test provider failure and duplicate webhook delivery when those states matter.

Example: Connect a scoped email credential, send one booking confirmation, and verify the booking remains saved if email delivery fails.

How do I get the best results?

State the outcome and constraints, build in coherent slices, provide relevant evidence, test the result, use product controls for operational actions, and recover from versions instead of asking the model to guess an old state.

Treat Mango9 like a capable teammate who works best with a real finish line. Review each result before expanding the scope, and preserve what is already correct in follow-up prompts. Clear decisions improve both speed and confidence.

Example: “Add CSV export to the filtered customer list. Export only visible columns, preserve the current filters, and keep mobile layout unchanged.”