How to build an app

Start with a tool your team can try this week: an on-call rota, a trial tracker or a retro board. Describe the job in Apps. WeMachines builds and hosts a first version, and you ask for changes in the same thread.

Follow the steps below or copy a prompt from one of the six examples. The screens illustrate the idea; use the app’s thread to shape your version with the team.

Writing your own prompt

Start with the job, who will use the app, and where its data comes from. Point to the relevant tasks, docs or connected repository. Explain any rules the data does not capture, such as who can approve a request or what counts as overdue.

• Start with what it is for. “A rota that shows who is on call this week” works better than a list of screens and buttons.
• Say where the data comes from. “From our tasks”, “off our repo”, “from Stripe”. If it should start empty and the team fills it in, say that instead.
• Say who it is for. For example, a view for the person on call or a list for everyone. This helps shape the screen; it does not make the app private.
• Ask for one job. Get a first version working, then add to it in the thread.

Build your first app

Building an app uses your team’s AI credits, and a first build is one of the heavier things a workspace does. On the Mac desktop app you can switch the build to Local, which runs it on your own Claude Code instead. Spend credits well covers the two settings an admin can use to cap it.

1. Open Apps in the dock. At the foot of the page, under “Build an app for your team”, is a box that says “Build a…”.
2. Type what you want in one sentence, or paste a prompt from this page, and press Enter. The row under the box shows, at its left, which model will build it and how the build is paid for. Templates, at its right, has ready-made apps to copy.
3. Watch it build. You land on the app’s own page, where the machine says what it is doing in plain English and posts screenshots as it goes. A first version usually takes a few minutes. Anyone on the team can press Stop, and the app goes back to the version it was on.
4. Ask for changes in the same thread: “group by team instead”, “sort by the newest first”, “make the header smaller”. Every change saves a version, so you can always go back to one that worked.
5. Open it any time from Apps. Every app is an icon there, A to Z by name, and a click opens it in a window of its own, beside any others you have open.

Tools the team opens every day

Try a standup board, an on-call rota or a retro. These examples save the team’s entries and use workspace accounts to identify each person.

Standup

Everyone gets a row: what they did yesterday, what they are on today, and anything in their way. The first column is drafted from each person’s own tasks and commits, so people only write the part the app cannot see.

The commits come from your connected repo. Without one, it drafts from tasks alone.

S Standup

Thursday, 4 September

4 of 6 in · 1 blocked

Yesterday Today Blocked

Nadia Closed T-131, the invite copydrafted Week-two launch update –

Tomas 4 commits on the retry fixdrafted Reviewing Leo’s PR #212 –

Leo Opened PR #212drafted Search ranking Waiting on the staging key

Priya Shipped the X threaddrafted Case study draft –

Nobody has written Mara or Sam in yet. Their rows open at 9:00.

On call

Who is on call this week, when the handover happens, and the weeks ahead. Swapping a shift is a button instead of a thread.

The app reports the current name back to the workspace, so when you ask a machine to “check with whoever is on call”, it knows who that is.

O On call

Week 36 · 2 - 8 September

Handover Mondays, 10:00 CET

Priya Until Monday 10:00 · 2 days, 4 hours Since Monday Swap

Leo Sep 8 - 14

Nadia Sep 15 - 21 Swap requested

Mara Sep 22 - 28

Tomas Sep 29 - Oct 5

The workspace knows who this is, so “ask whoever is on call” resolves to a person.

Retro

Three columns - keep, drop and try - that people add cards to during the week, while they still remember what happened. Cards stay anonymous until Friday. Past retros are kept, so the next one can start from last sprint’s Try column.

Apps that read your repo, your docs and other services

Use tasks, docs, chat or your connected repo as the source for an app. For another service, an admin can add the credentials it needs in the app’s settings.

Ship log

Pull requests merged each day, and this week’s changes with the task each one closed. It reads the connected repo every time someone opens it, so nobody maintains it.

To have the list posted in a channel every Friday, add a routine that reads the app. An app cannot post, and it has no clock of its own.

Docs check

It compares your Docs with the repo and lists the pages that describe something that has since changed - a renamed workflow, a tool you stopped paying for. Each page comes with the reason and the person who owns it.

Trial watch

Every trial with the days it has left, how many seats are really in use, and a line on what that team has done so far. The row nearest the end is the call to make today.

It needs a Stripe key and a PostHog key. An admin adds them in the app’s settings, where they are kept as secrets that nobody can read back.

More prompts to try

Eight more ideas to try. Copy one, review the first version, and ask for the changes your team needs.

What an app can and cannot do

• An app reads your workspace. It does not write to it. It can show your board, but it cannot create a task or post a message.
• Use a routine for scheduled work. Anything that should happen “every Monday” is a routine that reads the app and does the posting.
• Some apps run on a server of their own. Anything that stores or shares your team’s data gets a database, and you do not have to ask for it. These apps take a few seconds to wake up when nobody has opened them for a while.
• Keys stay out of the thread. When an app needs a key for another service, an admin adds it in the app’s settings, where nobody can read it back. The thread is visible to your whole team, so never paste a key into a prompt. While an app holds keys, only admins can ask for changes to it.
• Apps are for your team. An app opens only for people logged in to your workspace. Publishing apps to the internet is switched off for now, and an app is not the place for anything your customers depend on.
• Your plan decides how many apps you can keep. Start-up has room for twenty and Grow for fifty, and every workspace spends its first month free on Start-up. The current numbers are with the plans on the homepage.
• Apps are in early access. They work on every plan, and they are also the newest part of WeMachines and the part that changes fastest.