How to build an app

An app is a small tool your team keeps meaning to build: the on-call rota, the trial tracker, the board for Friday’s retro. In WeMachines you describe it in a sentence, and the AI builds it, hosts it and gives it a page in your workspace. After that, you change it by asking again.

This page shows how to do that, step by step, and then walks through six example apps. Each one comes with a picture of what you get and the prompt that makes it. Copy a prompt, paste it into Apps, and shape the result to your team.

Build your first app

1. Open Apps in the sidebar. The page asks “What does your team need?” above 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 line under the box shows which model will build it and how the build is paid for.
3. Watch it build. You land on the app’s own page, where the AI 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. Pin it. The pin is next to the app on the Apps page and in the app’s own header, and it puts the app in everyone’s sidebar.

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.

Tools the team opens every day

These three replace a ritual your team already has. Each keeps its own data, so what people type is still there tomorrow, and each knows who is using it, so nobody has to type their own name.

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 the AI 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

An app can read what is already in your workspace - tasks, docs, members, chat and the connected repo - so there is nothing to keep up to date by hand. It can also talk to another service, once an admin gives it a key.

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 that teams ask for. Each is a starting point: paste it, look at what comes back, and ask for what is missing.

Writing your own prompt

The prompts on this page are one sentence, and yours can be too. The AI that builds the app can see your workspace - your tasks, docs, members, chat and the connected repo - so you do not have to describe your data, only say which part of it to use.

• 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 will use it. The whole team, one role, or only you. It decides what the first screen shows: everyone’s rows, or yours.
• Ask for one job. Get a first version working, then add to it in the thread.

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.
• An app has no clock. 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.
• Some apps can be made public. An admin can publish an app from its settings, which gives it a web address anyone can open without an account. That suits a report or a simple static page. Everything in a published app is public, including the data it loads. Apps are made for your own team first, so we do not recommend running anything customer-facing on one yet.
• Your plan decides how many apps you can keep. Start-up has room for twenty and Max for fifty, and the 14-day trial every workspace starts on is Start-up. The current numbers are on the pricing page.
• 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.