Writing a good request

You choose the product. DeplAI manages the implementation.

A strong request describes the business, not the stack. You should not need to name frameworks, databases, or authentication libraries.

What to include

Who Who will use the application?

Purpose What problem does it solve?

Core workflows What should people be able to do from start to finish?

Data What information does the application manage?

Roles Are there administrators, staff, members, or customers with different access?

Design direction What should it feel like? Clean, calm, dense, mobile-friendly, and similar direction is enough.

Example

> Build an appointment booking platform for a physiotherapy clinic. Patients should browse services, select a practitioner, choose an available time and book an appointment. Staff need an admin area for managing appointments and availability. Keep the design clean, calm and mobile-friendly.

That request names users, workflows, data, roles, and tone. DeplAI decides how to implement pages, persistence, and sign-in.

Another example

> Build me an online store for handmade furniture with collections, product pages, a cart and an admin area.

How to write change requests

After a Ready application exists, describe the change against the current product:

> Make the homepage darker and show four products per row.

DeplAI modifies the existing application rather than starting from scratch. See Request changes.

What to avoid

• Listing implementation technologies you want DeplAI to “use”
• Asking DeplAI to skip checks or ignore broken workflows
• Combining many unrelated products in one first request

If a first result is too broad, use Modify to add one capability at a time.

Related: Create your first application | How DeplAI builds applications