Documentation
Everything Desifex does, written down
Written for the person using it, not for the person who built it. No page here assumes you can read code, and the few that do say so at the top.
Build your first applicationTwenty minutes, start to finish, with nothing to install.Put something in front of peopleVersions, test and live, and what each one means.Take an application overFor the developer who has just been handed one.
Start here
What Desifex is, and how to get an application of your own running.
- What Desifex isAn application factory where conversation is the interface — and the handful of things it deliberately will not do.
- Your first applicationFrom a sentence to something running, in about twenty minutes, with nothing to install.
- The workbenchA tour of the screen you will spend your time on — the conversation, the six tabs, and the menu.
- What to expectHow long things take, what a good working rhythm looks like, and the parts that genuinely go wrong.
Building
Getting what you actually wanted out of the conversation.
- Describing what you needHow to phrase a request so that what comes back is what you meant.
- Watching a buildWhat the steps mean, what is happening underneath, and why you are not shown a log.
- Changing your mindInterrupting a build, correcting a misunderstanding, and undoing something you asked for.
- When a build failsWhat a failure actually means, what to try, and when to ask us.
- Showing it a fileAttaching a screenshot, a spreadsheet or a document to the conversation — often faster than describing it.
- Choosing a design systemWhat a design system decides, how to pick one, and what changing it later does.
- Asking for settingsThe conversation reaches the whole platform — addresses, icons, redirects, users, integrations and shipping. If you do not know where a setting is, ask.
- When it asks youSome decisions arrive as a screen rather than a message — a table to correct, a list to choose from — and the build waits for your answer.
- Starting from what you haveA spreadsheet, a document, a picture or a page of your own site — attached, read, and built from.
Shipping
Getting what you built in front of people, and getting back to an earlier version.
- VersionsEvery build is kept, named after what was asked for, and can be compared and restored.
- EnvironmentsPreview, test and live — what each one is, who can reach it, and why their data is separate.
- DeployingPutting a version into test or live, what happens while it deploys, and what happens if it fails.
- Going backRestoring an earlier version when a change turned out to be wrong.
Running it
Everything in Settings — addresses, access, people, files, integrations and what crawlers are told.
- Addresses and domainsThe address an application gets, and how to put it on a domain you own.
- Who can reach itOpen, behind one shared password, or accounts — and why the choice is enforced in front of the application.
- People who sign inThe workspace's user directory — adding the people who use your applications, which ones each may open, what you can keep about them, and two-step sign-in.
- Published filesDocuments your application hands to its users — a price list, a brochure, a form — with a stable address and no build to change them.
- IntegrationsEmail, SMS and Google — connected once, used by the application without it ever holding a credential.
- AppearanceThe browser tab, the icon, what a link looks like when somebody pastes it, and adding it to a phone's home screen.
- Redirects and search enginesOld addresses that still get visited, and what crawlers are told about each environment.
- Configuration valuesNamed values the application needs but must not contain — API keys, account numbers, thresholds.
- Your dataThe Data tab — reading, correcting, adding to and clearing out what your application has stored, one environment at a time.
- VisitorsWho is using the application, counted without identifying anybody and with nothing to set up.
Your workspace
What every application in it shares — the domain, the design systems, the people, the user directory and, if you want it, one set of records — and how to be in more than one.
- People and rolesThree roles, what each can do, how they apply to the builder as well as to the buttons, and why they belong to a workspace rather than to an account.
- More than one workspaceBelonging to several, switching between them, the role you hold in each, and why nothing crosses over.
- Organising applicationsFolders on the dashboard, and how to keep a growing list navigable.
- Your own design systemsAuthoring a design system for your brand, or a client's, by importing guidelines, a website or a Figma library.
- Your profileYour name, your password, your picture, and the theme.
- Where records liveOne store per environment, one across an application's environments, or one the whole workspace shares — what each costs you, and how to change it.
For developers
What is actually generated, and what to do when you inherit one.
Reference
Terms, limits, and what to do when something specific has gone wrong.
Something here is wrong or missing?
Tell us and we will fix the page. Documentation that is quietly out of date is worse than documentation that does not exist.