Chapter 3: Build and Share Your App

Many people think building an app means learning to code first. With an agent, it does not.

With an agent, you do not write the code. Your job is to decide what to build and to judge whether it works. Your agent's job is to do the building.

That does not make it effortless. A vague idea gets you a vague app. The skill in this chapter is the same one from the rest of the course: say clearly what you want and what done means, and check the result.

3.1 Start a side chat for this chapter

Open Muse and create a new side chat named "Chapter 3: Build an App". Do the examples and assignments in this chapter there, so they stay in one place and apart from your main chat. Your whole build, from brief to feedback, lives in this chat, so you can scroll back through every version.

3.2 Choose something small worth sharing

Your first app should be small enough to finish and useful enough that someone else would use it.

Good first apps do one thing for one group of people. A sign-up page for your club, a price calculator for your customers, a checklist for a recurring event, or a quiz for your class. If you can describe the app in one sentence, it is small enough. If you need three sentences and an "and also," split it and build the first part.

Answer these before you start:

• Who will use it?
• What is the one thing it does?
• How will they get to it? A link is enough.
• What does done look like?

3.3 Write the brief

Turn your answers into a brief, which is your instructions to your agent. A good brief for an app has three parts: the outcome, the audience, and what done means.

Build a one-page sign-up form for our community garden's volunteer days. The audience is neighbors who may be using a phone. Done means: someone can pick a date, enter their name and email, and see a confirmation, and I can see who signed up.

Before your agent starts a big job, have it say the brief back to you in its own words. If it got something wrong, you caught it before it built the wrong thing. You can make this a standing rule: before starting a big job, your agent restates the outcome and what done means so you can confirm it.

3.4 Build it with Muse

Do not ask for the whole app in one message and hope for the best. Build in steps.

1. Ask for a first version. Send your brief and let your agent build.
2. Look at it. Open what it made. Does it match the brief?
3. Correct one thing at a time. "Make the date buttons bigger" works better than "make it nicer."
4. Repeat until it matches what done means.

Keep control by asking your agent to show you a working version at each step and to ask before it publishes or shares anything. Save this as a standing preference so it applies to every build.

Simulator: Keep It Small and Build It. Give the agent instructions for a small app, watch the build steps, and test the result.

Now build yours. Get started before you read the next section if you can. Your app does not have to be perfect, but it should work.

3.5 Watch a real build

The best way to learn how a build goes is to watch one. This one is real. The practice phones in this course were built with Muse, in one long chat, by your instructor Eli. He wanted a simulator to use in place of videos, and he built it by talking to his agent the way you are about to talk to yours.

The phone below replays that chat in a shortened form. Eli's lines and Muse's replies are trimmed from the real conversation, so it reads quickly. Press Play and watch it go. Pause at any point and tap around if you like, since the phone is yours to use.

Simulator: How the simulator was built. Watch a real build, from the first request to the finished code.

Look at what Eli did and did not do. He never wrote code, and he never started with a long, perfect description. He worked in a loop.

Three habits from this real build are worth taking into your own:

1. Plan first, and say why. Start with the outcome and the reason, ask for a plan before a build, and decide on purpose what to leave out. A plan is cheap to change. Code is not.
2. Build in small steps. Get a first version early, then react to something real. Give small, specific feedback, and show your agent a screenshot or an example when words will not do.
3. Check the work and respect the limits. Ask your agent to test its own work and to confirm the finish. When it says it cannot do something, take that seriously, choose another way, and keep for yourself the steps only you can do.

Compare these habits with the build steps above. They are the same moves. The chat just shows them with real stakes and real mistakes, which is why the build took one long conversation and not one perfect message.

3.6 Test it and fix it

An app is not done when it exists. It is done when it does what the brief says.

Go back to your definition of done and test each part as a real user would. Use it on your phone and on a computer if you can. Try something unexpected, such as leaving a field blank.

When you find a problem, describe it clearly: what you did, what you expected, and what happened.

I picked a date and tapped Sign Up without entering my email. It showed a blank confirmation. It should ask me for my email first.

That is much easier for your agent to act on than "it's broken." Ask for the fix, then test again.

3.7 Publish it and share the link

Publishing means other people can use it. When your app matches the brief, ask Muse for a link you can share, and approve the step when it asks. Because this is publishing, take a moment to check what you are about to share. Make sure it has no private information in it, and make sure it says what it is.

Send the link to a few real people, such as a friend, a customer, or someone in the club. Ask them to try it and tell you what confused them. Their feedback is your next brief. Fix one or two things, approve version two, and share it again. Publishing is not a one-time event. It is a loop.

Simulator: Share It and Publish Again. Share the app link, read the feedback, and publish the one change it asked for.

You are done with this chapter's main assignment when you have a working link and have shared it with at least one other person. That link is the shared application you take away from the course.

3.8 Your Learner Profile

Your learner profile now includes building and publishing. It lists what you know: choosing a small app, building in steps and testing against the brief, and publishing and improving from feedback. It also gains two rules: show a working version at each step and ask before publishing, and restate the outcome and what done means before starting a big job.

Copy the updated profile from the learner profile panel and use it at the start of your next build in this side chat.

3.9 Summary

You chose a small app, wrote a brief, built it in steps, tested it, published it and shared the link. You did not need to learn to code. You needed to decide clearly and check carefully. In the last chapter, you use the same skills for the everyday work of a small business.