Apps

An App is a project you build inside MotherFluxer — a folder of files, like a project in a code editor. It can hold any mix of files: HTML, CSS and JavaScript pages, framework code, Markdown notes, Mermaid diagrams, charts, data files, and a server in any language. Generate one from chat, then open the App editor to refine it with AI, edit the code by hand, preview it live, and publish it.

Apps live under the Productivity filter group in Artifacts. Before you make your first one, the empty state reads "No apps yet".

Generate an App

Just ask in chat. Describe what you want and MotherFluxer builds it as an App artifact.

• "Build a landing page for a coffee shop with a hero and a signup form."
• "Make a flowchart of a user signup process as a Mermaid diagram."
• "Create a bar chart of monthly revenue from this data."
• "Give me a small JavaScript app that converts currencies."

Charts and diagrams are Apps too — there is no separate artifact type for them. When you generate one, it appears in your Artifacts under Productivity, ready to open and edit.

An App in chat shows a picture of itself. Click or tap its card and the App starts right there in the card, at the card's own size — it arranges itself the way it would in a window that size, and you use it in place: press its buttons, type into it, scroll it. That first click is enough to start its private Draft; a framework App is compiled on your device first. While it starts, the card says so. On a computer, resting the pointer on some Apps shows a preview first, which takes no presses until you click. To change the App, choose Open in editor from the card's menu — it opens full size in the App editor. An App with nothing to show in a window — only code, or only a server — says This App doesn’t run here and points you to the editor.

Open the App editor

Open any App to launch the App editor. The bar across the top holds:

• Smart Edit first — describe a change in plain language and let AI revise the App for you.
• The App's three tabs — Develop, Manage and Equip. Take the wheel yourself.
• File, after the three tabs — every point you can go back to, newest first.
• On the right, undo and redo, and close.

With every tab closed, your running App fills the editor.

Smart Edit an App

Use Smart Edit when you want AI to do the work. Tell it what to change — "make the header sticky", "switch to a dark theme", "add a contact section" — and it rewrites the App. It sees every file your App is made of and can change several of them in one go, so a change that belongs in your stylesheet lands there rather than being crammed into the main page.

Each Smart Edit produces a new version, so your previous one is preserved and you can compare or roll back from the File tab.

The edits Smart Edit can run on an App, each with what it does:

• Describe change — Tell the AI what to change in plain language
• Add feature — Describe a new feature to build into the app
• Fix bug — Describe a bug for the AI to find and fix
• Refactor — Restructure or clean up the code without changing behavior
• Add comments — Add explanatory comments and documentation

Your changes are saved as you work

Your App is saved a moment after you stop typing, so you don't have to close the editor to keep a change — and its private Draft, the version only you and your collaborators can see, stays current with what you have written. Making those changes public is still a deliberate step: press Publish in Manage › Publish.

One kind of save is refused: a key's value — a password, a secret key — typed or pasted into any of your App's files. The notice names the file and the variable the value should become, and for the App's owner Declare and vault it opens the window that keeps it as a key instead.

Undo and Redo

Undo and Redo on the right of the top bar step through one history for the whole App, on every screen. The keyboard's undo and redo shortcuts take the same steps, whether or not you are typing in the code editor. They cover what you change by hand in the editor:

• Code you type, in any file — typing undoes in natural chunks, and switching files keeps the history.
• Files you add, rename, remove or duplicate, and the files you add, rename or remove in its Assets.
• Changes you make by clicking your running App (a reworded heading, a colour pointed at a different token).
• The settings you author: the design system on Develop › Format, the brief on Develop › About, page access on Manage › Pages, groups and their prices, email templates and automations, the install and search text, and the dashboards' layouts.
• A version restored Code only from the File tab — one step, so you can take it back.

Each step remembers where it was made: undoing a colour you set on Format takes you back to Format with the colour as it was, and undoing a line of code opens that file with the cursor where you were. The running App shows an undone click-to-edit at once.

Some things are outside Undo because they act the moment you change them, and each keeps its own confirmation: turning sign-in on or off, storage, the payments mode, the AI connection, reference documents, alerts, your data lists and their rows, the people in your App, and publishing. A change the AI makes, a restore that brought back data, a Discard and a feature you install or remove each start a fresh history — the earlier point is a version on the File tab, not a step back.

Going back to an earlier point

The File tab is one list, newest first, of everything you can return to:

• Versions you saved. Choose Save, give the version a name — or leave the name empty and it is named by its date — and choose Save draft for a private checkpoint. Publishing from Manage › Publish records a version too. Each one records both your code and your data at that moment, so Restore can bring back your code only (Code only), or your code and your rows together (Code + data). Pressing a version's card shows it in the editor without restoring anything, and Make Live match, under Restore and the owner's alone, publishes that version.
• Backups taken for you. Before every publish, before any restore, and before any change to the shape of one of your tables, your App's data is backed up automatically. Each backup has a card of its own and can be restored on its own.
• Changes to your tables. Every change to a table's shape is recorded, and you can put the old shape back without touching your rows — or, when a change replaced data, put the rows back too.

One thing worth knowing: Undo in the editor brings back your code and settings, and it can take back a Code only restore. It does not bring back rows you deleted, and a restore that brought data back cannot be undone — the confirmation says so. Restoring from this list is the only way to get your data back.

The App editor's three tabs

Everything you do to an App by hand sits in three tabs, each holding four containers, with a second row of four on Manage:

• Develop — making the App: About (the brief for the AI that builds it), Format (its design system), Data (its records, lists and storage) and Code (its files).
• Manage — publishing it, who gets in and how it is paid: Publish, Pages, Users and Payments. Its second row is what happened: Traffic, Alerts, Money and Health.
• Equip — the features it offers: AI, Messages, Connect and Automations.

Payments and Money are the owner's alone, so a collaborator's menu doesn't show them.

Press a tab and its containers appear as one row of tiles. Each tile shows its name and one status — a count, such as "3 pages", or one word, such as On, Off or Synced; AI reads Needed when your App's code calls the assistant while it is off, and the Equip tab carries a mark until you turn it on. Press a tile to open that container. The menu has only these two levels.

A container shows what it holds: each thing with its value, one status and its icons. Anything more — a form, a list of settings, a confirmation — opens as a window from the thing's Settings icon (the gear), and closes back to the container.

Where each feature is set

Every setting has one home in the editor:

• Equip › AI — the assistant your visitors talk to, the documents it answers from, the chat widget, and AI that runs on the visitor's device.
• Equip › Messages — email, push, texts and Slack, the emails your App sends, the rules that send them automatically, and a log of what was sent.
• Equip › Connect — outside Services such as Sheets, Calendar, Files, Maps, GitHub, Zapier / Make and Bank accounts, Custom connections, and Variables: every value your App's code reads, each declared once here — a plain setting, or a key kept in your account's Connections & Keys that never reaches the page. A key your App needs and doesn't have yet reads Setup needed, and while a required one is missing, opening the App takes its owner straight here.
• Equip › Automations — your App's actions — code it runs when called, in the background, from a webhook or on the visitor's device — their schedules, and the history of every run.
• Manage › Users — sign-in, the groups your App's people belong to, and the people who have signed up. Someone can sign in without joining any group, so they are all users rather than members.
• Manage › Pages — who may open each page, and what it costs them.
• Manage › Payments — how your App takes money, and its prices.
• Manage › Publish — your Draft, your Live App, Search (how your App appears when someone finds it), and in the Live window its address, domain, sharing, Background power (running your App as a server) and Home screen install.
• Develop › Data — records and lists, and in its Storage window whether your App saves data and its Private database.
• Develop › Format — brand, colors, text, shape and motion, and editing your App by clicking it.
• Manage › Traffic — your visitors. Manage › Health — its activity log and errors. Traffic, Money and Health are dashboards: each has an Arrange icon that opens the window where you pick a layout, order its blocks, and add a number or chart of your own.

When a container doesn't apply yet

Every App you build shows all three tabs and every container in them, whatever files it holds — adding a Markdown note or a data file never hides one. What your App can do comes from the whole project, not from the file you open first. The one exception is an App the community holds — one you posted to Slop, or a co-op's: it opens on a single tab, Manage, holding Data, Money and Health to read, because nothing in it is built or published from the editor.

A container your App can't use yet stays in the menu and says in one line what is missing:

• No web page · add a page — Format styles web pages, so it needs one.
• Nothing to publish · add a page, a backend or an action — Data, Publish, Users, Payments, the Equip containers and Manage's second row need something that can go live.

Some containers work on the published App — Data, Users, Payments, AI, Messages and Connect. Until your first publish their lists are empty, and their add, connect and turn-on controls open Publish first, which names what is waiting and offers Go to Publish (a collaborator sees See Publish). Connect's Variables list is the exception: it works from the start. Automations works on your Draft before you publish; only its schedules wait for Live.

Features your App can turn on

Your App can do more than static pages. When you ask AI to build something that needs a capability — saving data, letting your users sign in, running server-side actions, sending email, taking payments, or pushing live updates — MotherFluxer already knows which of these your App has turned on. It builds against the features that are on, and when your request needs one that's off, it tells you exactly which feature to enable and where, so you can turn it on and try again.

Some features are free to switch on; others cost money — a private database, running your App as a server, direct SQL — and ask for a payment method first. A paid step shows what you get and what it costs at the moment you press it.

Your App can also connect to other services, send notifications, run AI on your visitor's device, show maps, take payments, and more. Ask the building assistant for what you want in plain language and it drops in a ready-made starter, built against the features you have on. See the related guides for each capability.

A feature is a setting of its own — the pieces it adds to your App's sections and its files — that can be kept and installed in another App:

Star · Post · Copy

Tell the building assistant about your App

Develop › About is the brief the AI that builds your App reads before every change it makes. A reel of ready-made briefs runs across the top — Online store, Informative, Customer service, Portfolio, Booking and Community. Picking one stamps its summary, audience, glossary, features, rules and examples; your documents, AI notes, locks and installed features are kept, and a brief that already says something asks first (Replace the brief). The lit card is the brief you started from and counts what you have changed since; it reads Custom when yours matches none. A brief stays with its App, so it can't be starred or shared; the search on the reel finds one by name, and Ask AI there designs one from what you type. Each list says in one line what it is for, and the lists sit in four groups:

• Your app — Summary (what the App is, in a sentence or two), Audience (who it is for) and Glossary (words with a special meaning in your App, and what each means).
• What to build — Features, and what you are Not building. Each feature shows whether it is Planned, Installed, In draft or Built, worked out from the pages and lists it names and from whether an install put it there. The list's + opens Add a feature: Plan your own (a line the AI builds from), or install a ready-made one from its one reel, which lists Our features, your starred features and the community's — the window names what it adds and what must be turned on first, and Install adds its pieces in one step. A feature your kind of App suggests follows the list as a Suggested row that opens its install. An installed feature's trash removes it, naming every list that goes with it, and the star on an installed or built feature's row lists it among your starred features in Add a feature. The AI will not add anything you have ruled out.
• Rules for the AI — what it should Always do and Never do, and its AI notes: what it kept when you told it something to remember. Asked to break a rule, it stops and tells you which one. You can edit or delete any note. A new App starts with the lines you keep in Settings under New apps start with.
• Reference — Examples to borrow from (a site or a picture, and what to take from each), and Documents for it to read, such as a spec or a price list.

The About tile shows how many groups have something in them, such as "3 of 4". How the assistant your visitors talk to behaves is set in Equip › AI, not here.

Add, rename and delete your App's files

Develop › Code lists your App's files as a tree beside the code. The icons at the top of the list add a file or a folder: New file asks for its name, and a name with / in it goes inside a folder. A new folder starts with a first file, because a folder is made of the files in it.

Each file's ⋯ offers Rename, Duplicate and Delete file; double-clicking a file's name renames it too. A name the editor can't use is refused with its reason, at the centre of the screen, and nothing is renamed:

• Already exists — another file already has that name.
• Name needed — the name was left empty.
• No “..” or “\” in a file name.
• MotherFluxer folder is reserved and read-only.

Press Enter on a refused name to keep it open and fix it; click away to give the rename up. Deleting a file asks first: the File goes, your Draft is Changed, and Live follows On publish.

Add pictures, video and other files to your App's Assets

Your App's code is text. Its pictures, video, sound, 3D models, documents and caption files sit beside the code in its Assets, each at a path of its own: assets/ and the file's name, such as assets/logo.png. In Develop › Code, the last row of the file list reads Assets and how many it holds, such as Assets · 3 — press it to open the Assets window, where each file shows its path and its size, and a picture shows a small copy of itself.

• Upload adds a file from your device.
• From my artifacts lists your Images, Videos, Audio, 3D models and Documents. Pick one and it is added as the file its own export makes: an Image as its finished picture, a Video as the copy that plays, an Audio as its mix, a 3D model as its model file with any material and movement baked in, and a Document as the file it downloads as — a PDF for one written in the editor.
• Each file's ⋯ offers Copy path, Rename and Remove. Removing asks first: the file goes, the pages that use its path stop showing it, and Live follows when you publish. Renaming changes the path, so change the pages that use it too.

A page uses a file by its path — <img src="assets/logo.png"> — whether your App is pages alone or runs a server of its own. A name is letters, digits, dots, dashes and underscores, with no folders; a file added under a name already in use gets a number, such as logo-2.png. A file in the code and a file in Assets never share a path. The files reach your Live App when you publish, and a copy of your App — one someone saves from the community, say — carries them with it. Each kind of file has its own size limit; a video can be up to 150 MB.

A file can come from another editor too: every editor's Export offers Add to an App… beside Download, and puts the file it makes into the App you pick.

Edit your App by clicking it

In Develop › Format, your running App sits beside its design system. Choose Select to click anything in the App and see every design value that styles it. Change a value and everything using it changes with it; choose Change only this to give just that one part of the App a different value. Choose Navigate to use the App normally, following its links and buttons. Words are changed by double-clicking them in the App.

Your App stays in view

Close the menu and your running App fills the editor. Open a tab and its container fits into the space under the menu instead of sitting over it. The containers that show your App — the Draft card in Publish, Format and Code — all show the same running App, so it never reloads as you move between them. This is particular to Apps — in the other editors an open menu sits over the artwork.

Preview your App

Your App runs live as you work, using its private Draft — your visitors keep seeing the published version until you publish again. The Console, docked under the code editor in Develop › Code, shows logs and errors from your running App, so you can spot problems without leaving the editor.

To check other screen sizes, open Manage › Publish and press the Draft card's status to open the Draft window. Under Preview, choose a Size — Full, Desktop, Tablet or Phone. The size applies to every preview of your App and stays chosen.

Framework apps are compiled before they preview or publish, so what you see in the preview reflects the built result. If your App can't start — a build that failed, or its details couldn't be loaded — the preview says why and offers Retry, rather than waiting on a screen that isn't coming.

When the preview can't show your App

The preview appears as soon as your App draws its first content, with a ring in the middle until then. When you change something, your App stays up with the ring over it while the change is saved and built, and the new page takes its place the moment it has drawn; you can keep using the old page meanwhile. When the preview can't show your App, a message in the middle of the screen says why and offers Try again, and any page already up stays behind it:

• An App with its own server may be asleep and wakes on the first visit, so its first ring can last up to a minute.

• Your app didn’t load, with the reason beneath it:

  • your App's server is still being set up — the preview keeps asking, and comes up by itself;
  • your App's server is paused — it reached today's limit on starts, or its account is paused;
  • your App's server didn't answer in time — check Health in Manage, then try again;
  • your draft's page is missing — save a change to rebuild it, then try again;
  • your App has no front page — visitors land on the page named index.html, so add one, or open another page in Manage › Pages;
  • your App has no web page to show — an App made of a server shows the server's own page once it is turned on in Manage › Publish;
  • your App's server answered with something other than a web page — choose Open in a new tab to see what it sent;
  • App hosting isn't available right now;
  • or nothing arrived that the preview could show.

• Build failed — a build could not finish, with what it said. The page already up stays, and Manage carries a mark until the build works.

• Your latest change hasn’t reached your draft. — the change was saved but the draft did not update; Try again asks again. Two things are not failures, so they stand in the preview's own place:

• This browser won’t show your draft here — the browser blocks the sign-in the preview needs inside the editor. Safari versions before 26.2 do this. Choose Open in a new tab to use your draft in its own tab, or switch to a current version of Safari, Chrome or Firefox.

• Your app is unpublished — the App has been unpublished, so its Draft is stopped too. The owner sees Publish to bring it back, here and at its address; a collaborator is told the owner can publish it again.

The Draft window's Preview line says the same in one word — Running, Opening, or why it stopped — with a retry and a way to open your Draft in its own tab.

Signing out of MotherFluxer also ends your private draft's access in every browser you opened it in. Sign back in and the preview opens again.

How a framework App is compiled

An App written with a framework has to be compiled before it can run. That compiling happens on the device you have the App open on — your own computer or phone — not on our machines.

• It starts on its own. Opening an App that owes a compile begins one; so does saving a change. There is no queue to wait behind, and the Draft window's Build line lets you rebuild by hand when you want to.
• The first one takes a moment; the rest are quick. The first compile of an App fetches the libraries it needs and the compiler itself. After that both are cached, and a compile following an edit finishes in well under a second.
• It works the same on a phone. A phone compiles the App just as a laptop does, so you can write, compile, and publish a framework App entirely from your phone.
• An App someone else wrote compiles when you open it. An App the AI wrote for you, one brought in from GitHub, or one you took from the community compiles the first time it is opened, rather than before anyone has looked at it.
• If it can't compile, it tells you. A compile that fails reports the problem in the editor and names what to fix. Your last working version keeps running in the meantime.

If you only have permission to view an App rather than change it, opening it never starts a compile and never reports an error against the owner's App.

Libraries your App can use

Your App can use libraries from the public npm registry. List them in your App's package.json the ordinary way — a package name and a version number such as ^3.5.0, 19.2.0, or latest.

• Version numbers only. A dependency that points somewhere other than the public registry — a git repository, a GitHub shorthand, a downloadable archive, a local path, or another package under a different name — is refused, and the build tells you which line to fix.
• Vue and Svelte are built for you. MotherFluxer compiles .vue files with Vue 3 and .svelte files with Svelte 5, so your App should list a matching version of vue or svelte. If it lists an older major version, the build says so and names the version to use.
• The first compile writes a lock file. After a successful compile your App gains a motherfluxer-lock.json file recording the exact version of every library that went in, so later compiles use the same ones and your App does not change underneath you when a library publishes an update. Change the versions in your package.json and the next compile updates the lock to match.

The licence on your App's starter code and libraries

Some of your App's files start out written by MotherFluxer: the template your App was created from, the files of a feature you add from the catalog, and the extra files a GitHub backup adds so your App can run without MotherFluxer. That starter code is licensed to you under the MIT No Attribution licence: use it, change it, share it and sell it, with or without crediting MotherFluxer. Each such file that can hold a comment says so in its first lines, beginning SPDX-License-Identifier: MIT-0 — apart from the backup's Dockerfile and its EJECT.md, which states the licence in full. The licence covers only the code MotherFluxer wrote; it claims nothing over the code you or the building assistant write.

The libraries your App uses keep their own licences. When a compile bundles libraries into your App, it adds a THIRD_PARTY_NOTICES.txt file listing each library with its licence, and publishing puts that file online beside your pages. Keep it with your App wherever you run it — most open-source licences ask that their notice travels with the code.

Export your App

Export, in the File tab, downloads your App as a zip of every file in its code and every file in its Assets, each at its own path, so you can open or run it elsewhere and its pages still find their pictures. If the Assets can't be fetched into it, nothing downloads — a message at the centre of the screen says so, and you can try again — so you never get a zip missing its pictures.

Share by publishing

Previewing and editing happen inside MotherFluxer. To let anyone else open your App, you Publish it — that's the only way to share an artifact. Publishing lives in Manage › Publish. While your App is live, the Manage tab carries a mark when changes are waiting to be published or when Live has a problem.

Publishing needs something that can go live: a web page (an HTML file, or a framework App that compiles to one), a server, or an action. Publishing then puts the whole project online — every page at its own address and every other file beside it. A project of only notes, a Mermaid diagram or a JSON file runs in the editor and in chat but has nothing to put on the web yet — ask the building assistant to add a page first.

The MotherFluxer folder

Your App's files include a special MotherFluxer folder that MotherFluxer manages for you. You can see what's in it, but you can't edit, rename, or delete it — it's read-only. It holds things MotherFluxer keeps on your App's behalf:

• Your App's configuration — the declaration of its pages, design system, variables, Assets, and the features it has turned on. A variable that reads a key says only what kind of key it needs; the key itself is kept in your account, never here.
• A reference file describing every built-in feature your App's code can call, kept up to date automatically. It doubles as autocomplete when you edit the code yourself.
• A guide folder of how-to guides the building assistant reads when it works on a feature your App uses.
• Any reference documents you add for your App's assistant to answer from.

It never contains secrets, and it's never part of the public files your published App serves.