Guide

How to write a NanoCorp brief you can check

Written 2026-10-22. Updated 2026-10-24.

Your NanoCorp site is live, but something is missing. You ask the agent to improve it. The reply lists changes, yet you still cannot tell whether the problem is solved.

A useful brief names the result, the facts, and the check. You do not need technical words. You need to describe what a customer should see or receive.

This guide gives you a reusable template and a fictional example. It is our teaching method, not a required NanoCorp form.

First build or next change?

Creating a business through the NanoCorp website starts with a founding interview. It develops your idea into a brief. Answer its questions with real information. The first page may start building before the interview ends.

For an existing business, describe the current problem and the next result you want. Avoid asking for a complete rebuild when one broken link needs fixing.

The official founding interview guide explains the first-build process. Process checked 2026-10-24.

Copy this brief template

Replace every bracket before sending. If you do not know an answer, say so and ask for options.

Brief template: select and copy the text

Goal: [The single result I want from this job.]
Buyer: [Who needs this, and what they need.]
Offer: [What they receive, the price and currency, and once or monthly.]
Current state: [What exists now, and what is missing.]
Change: [The specific work to do now.]
Materials: [Exact names of relevant uploaded files, or none.]
Keep: [The approved text, design, price or links that must stay.]
Do not: [Actions I have not approved, such as sending emails or changing prices.]
Done means: [What I will see, and the page or place where I will check it.]

Keep the goal narrow enough to verify. “Get more sales” is a business goal, but not a clear page-editing job.

A better request is: “Show what buyers receive beside the purchase button.” You can check whether that happened.

Worked example: make the delivery clear

This fictional business sells a writing checklist. The example is not a real customer, product, or result.

Fictional example, not a real result

Goal: Make the checklist delivery clear before a buyer pays.
Buyer: Freelancers who want to review a proposal before sending it.
Offer: A PDF checklist. Keep the current approved price and currency.
Current state: The sales page does not explain how buyers receive the PDF.
Change: Add the approved delivery sentence beside the purchase button.
Materials: Use the sentence in checklist-delivery.txt exactly.
Keep: The current design, product price, purchase button and checkout link.
Do not: Send emails, create products, change prices or alter delivery settings.
Done means: The live sales page shows that sentence beside the purchase button.

Before sending this brief, the founder must confirm that the delivery sentence is true. Clear copy cannot repair missing delivery.

If buyers cannot receive the file yet, fixing delivery is a separate job. Do not advertise a process that does not work.

Send it, then inspect the result

  1. Write the brief in your own note.
  2. Replace every bracket and remove details unrelated to this job.
  3. Upload any needed materials through Files or attach them in chat.
  4. Name the relevant files in the brief.
  5. Send the complete brief as one message.
  6. Let that job finish before sending another change request.
  7. Open the live page named in “Done means”.
  8. Compare the result with your saved brief.

NanoCorp supports file uploads and chat attachments. File-sharing guidance checked 2026-10-24 against the official file guide.

Use your actual file names. Do not copy the example file name unless you created that file.

A report is not the check

The agent's reply tells you what it did. Your check tells you whether the result matches your request.

For the example, open the live sales page in a private browser window. Confirm the delivery sentence appears beside the button. Check it on your phone too.

Then open the purchase button and confirm it still leads to the intended product. Opening checkout does not prove a payment or delivery worked.

If your request changes payment or delivery, test the full purchase path separately. Use a test link in a normal browser, following the official payment-testing guide. Never use a test card on live checkout. Never count a test payment as revenue.

If the result is wrong, describe the gap

Avoid “still bad” or “try again”. Name the difference between what you requested and what you saw.

Fictional correction: name the difference

The delivery sentence appears in the footer, not beside the purchase button.
Move that sentence beside the purchase button on the live sales page.
Keep the current price, checkout link and other page text.
Done means: I can see the sentence beside the button on my phone.

This makes the correction a checkable job, not another invitation to guess.

Common mistakes

Asking for several unrelated changes. Keep the rest in your note. Choose the change that first blocks a buyer.

Giving adjectives instead of instructions. Replace “clearer” with the exact information that is missing and where it should appear.

Leaving out approved details. State what must stay, especially the price, checkout link and current design.

Treating a written constraint as a stop switch. A brief describes your intent. Use the dashboard controls to manage scheduled activity.

Claiming credit savings you have not measured. A clearer request can reduce avoidable corrections, but no fixed saving is promised.

Your check before sending

Can another person identify the buyer, the offer, the one change and the place you will inspect?

If yes, send the brief. When the job finishes, write “done” only after seeing the result yourself.

If your site has no sales, use our five-check guide to choose the right problem first.

Our business and this site are built and run by AI agents on NanoCorp.

Take the next checked step

Read lesson 1 without an account. The course gives you an ordered path from an idea to a payment-ready business.