Managing your app with AI

They are already in your app. Nothing to install, nothing to switch on before you start: you just need to know where to look.

The feature builder, the MCP server and the palette work the same way on content apps and on e-commerce apps. The writing assistant shows up wherever there is a rich text editor: articles, events, locations.

This is the most recent of the four, and the most surprising to watch work. Its entrance isn't where you would look for it: it sits in the section type picker.

Go to My App › Structure, click Add, and look at the first tile in the list, before articles and photos: the one that builds a section with AI. Instead of picking an existing section type, you describe the one that doesn't exist.

The screen opens in two columns. A conversation on the left. A preview of what has been built on the right. You describe what you want, in whichever language you want, in as much detail as you want. The assistant builds it, tells you in one sentence what it did, and the preview fills in.

You keep the conversation going to adjust. Every exchange produces a version, and the history keeps them all, each one labeled with the request that produced it. Going back is always possible, which is what makes it safe to experiment.

A second tab gives you the generated code, with the extension's files. You don't have to go there, and the vast majority of users never will. It's there for people who can read it, or for a developer you call in for help.

When the result suits you, one button publishes it to your app, where it becomes a section like any other, in your menu.

This is the habit that changes the quality of what you get more than anything else. Say what the feature has to do, not how it should go about it. "A button to remember where I parked my car, and another one to walk me back to it" is enough: the assistant will find the platform's own tools by itself, the location permission your app already has, the phone's map app, the device's memory.

Name a specific technique or an outside service, and you push it out of that frame. You'll then have to explicitly authorize access to that service, and what worked as a built-in feature becomes a feature wired to the outside.

The studio holds three discreet panels that change the nature of what you can ask for.

The first one takes your files: images, in just about every format, and data tables in CSV, TSV or JSON. Dropped there, they are hosted by GoodBarber and get a stable address, so the feature can use them without depending on an outside service. To point to one in your request, type the at sign followed by the start of its name.

This is the panel that turns a file into a section: a directory, a rate card, a price grid become browsable in the app without going through the CMS. With one limit worth knowing today: the assistant reads your tables at their address, it doesn't analyze them column by column. Displaying them, yes; cross-referencing them in detail, not yet.

The second one stores access keys to outside services, for when the feature you describe has to query a service of your own.

The third one connects a shared database. Without it, whatever your users enter into the feature stays on their device, and nobody else sees it. With it, the data is stored server-side and shared by everyone. That's the difference between a personal calorie counter and a leaderboard shared by your whole community: same feature, two different products.

You don't have to work this out on your own: when what you describe needs a common memory, the studio offers to connect one itself. One button, a connection to your Supabase account, and the tables and access rules are created for you. Later features reuse the same connection in one click.

What you get is a feature built on demand, not a building block of the product. It is built with what's at hand: no outside library, no copyrighted image, everything on screen is original. And it stays a section inside your app, not a piece of software of its own: the studio builds a mini-game, it isn't a game engine.

The right way to place it: when what you want already exists as a section type or as an extension in the store, take the native block, it will always be better integrated and better maintained. When what you want exists nowhere and a developer's quote would kill the project, describe it. That's where it does something nothing else was doing.

And test it the way you would test a contractor's work: on a real phone, with real content, before you publish it.

The blog goes through each point in this chapter and shows what it produces for real, prompt included.

• Describing the result rather than the method: seven words are enough to get a complete geolocation feature, taken apart step by step in Prompt teardown: GPS memory and Maps from a single sentence.
• Your files: what the assistant can do with them, format by format, in AI Extension Builder: upload your own files.
• The shared database: what the studio creates for you, tables and access rules included, in AI Extension Builder: add a Supabase database to your app.
• And the limit, properly tested: a playable game with its shared leaderboard, which is still a section of your app, in Can a no-code app builder make Flappy Bird? I tried.

The other three tools live in the back office. This one does the opposite: it opens your app to the AI tools you already use elsewhere, Claude, ChatGPT, Cursor or another.

The mechanism is called an MCP server, for Model Context Protocol. The one-sentence version: it's a standard socket that lets an AI act on your app, instead of only talking about it. You ask which ten products sold best this month, and it actually goes and gets the answer from your shop. You ask it to schedule a notification for six in the evening, and the notification is scheduled.

The screen is deliberately short.

It holds two things. Your server address, with its copy button, which identifies your app and no other. And your API keys, which you create in sets from this page, each set revocable without touching the others.

The connection itself doesn't happen here. It starts from the other end: it's in Claude or in ChatGPT that you add GoodBarber, the way you would add any other tool, and the key created on this page is what identifies you there. Keep that direction in mind, it explains why the screen is so short: GoodBarber opens the socket, your AI comes and plugs into it.

The procedure is published tool by tool: connect Claude, connect ChatGPT and Codex, and the full MCP overview.

An open socket doesn't tell you what to ask for. That's the job of the 44 skills GoodBarber publishes openly on GitHub, reachable from the link on that same screen. Each one is a written recipe that teaches your AI to carry a common task from start to finish.

They are open and redistributable, which matters most to resellers: they can be renamed and republished under their own brand.

What it changes: repetitive gestures and monitoring questions. Getting your Monday morning picture without opening four screens, fixing twenty product pages in one go, preparing a campaign by dictating it. These are tasks where the back office asks for a lot of clicks and very few decisions.

What it doesn't change: the responsibility stays yours. The platform is ready for agents, it is not on autopilot. An AI connected to your app acts in your name, on real data, and it doesn't have your judgment about what should be published. Start with requests that read before requests that write, check what has been done, and keep your hand on whatever goes out to your users.

An icon opens the editor toolbar, to the left of the formatting buttons. You'll find it in the same place in an article, in an event and in a location. It drops down five commands, and the difference between them is worth understanding before you click.

Four of them work on the text you have selected: complete it, summarize it, translate it, change its tone. Never on the whole page, always on the highlighted passage, which lets you rework one paragraph without touching the others. Translation covers seven languages: Dutch, English, French, German, Italian, Portuguese and Spanish. Tone comes in five registers, from educational to casual, by way of professional, empathetic and neutral.

The fifth one, in the middle of the menu, is a free-form assistant, and it's the only one that starts from nothing: you describe what you want to get.

Hence the logic of the tool, worth understanding before you click: the assistant reworks a text, it doesn't fill a blank page, unless you tell it precisely what to put there. The habit that follows is simple, and it saves you wondering why nothing is happening: select first, ask second.

The gain shows on volume, not on the one-off piece. A shop putting forty products online has forty descriptions to write, all built the same way, all tedious to produce and yet decisive for SEO as well as for sales. A publisher working in three languages does the same translation job three times. Those repetitions are what the assistant absorbs.

It also absorbs mismatches in register. A text written by an engineer, run through the educational tone, becomes readable by a customer without anyone having to negotiate with its author.

The assistant writes correctly, it doesn't write like you. It produces clean, average prose with no rough edges, and rough edges are precisely what sets your app apart from the thirty others in your field. Use it for the thankless material, keep your voice for what your readers come to you for, and read everything that goes out under your name.

One simple rule, kept by the teams who use it well: AI writes the first draft, never the last.

The tool is called Genius Palette in the Extensions Store, and it lives in My App › App style › Colors.

Click again and you get a completely different suggestion: you regenerate until you land on a scheme that speaks to you. A button puts the original colors back, and above all nothing is applied to your app until you confirm, the footer leaving you free to cancel right to the end. So you can try fifteen of them without risking anything.

What the palette doesn't do: it knows nothing about your logo, your brand guidelines, or the field you're competing in. It's excellent for getting off a blank page, or for showing three directions to someone who can't decide. It doesn't replace a brand identity when you have one.

A useful habit: once you've applied a palette, open two or three real screens in the preview, a list, an article, a form. A scheme that looks appealing on four swatches can turn out to be unreadable on a dense list.

GoodBarber opens the door, it doesn't sell what comes through the door. The four tools are within reach from your back office, but the MCP server assumes you already have Claude, ChatGPT or an equivalent tool on your side, with the subscription that goes with it.

AI works well on what is already in order. That's true of all four tools, and it's the least obvious thing they have in common. An AI reworking a confused text produces a confused text that reads well. A palette laid over an app whose structure is unreadable doesn't make it readable. Tidy up first, accelerate second.

Start with one. These four tools touch four very different moments of your work, and nothing says you have to adopt them together. Take the one that matches your most painful week: the feature builder if a project is stuck for want of a developer, the MCP server if you spend more time consulting your app than running it, the writing assistant if you publish a lot, the palette if you're just starting out.