Desifex

Your first application

From a sentence to something running, in about twenty minutes, with nothing to install.

Nothing to install and nothing to configure first. If you can sign in, you can do this.

Create it#

Press New application on the dashboard. You are asked eight questions, one screen at a time. Press Enter to move on.

  1. What should we call it? The name your team will know it by — Proposals, Supplier portal, Site surveys. It becomes the address as well, so keep it short. You can change it later.
  2. What should it do? The important one. Describe it as you would to a colleague: who uses it, what they need to get done, and what it should keep track of. A paragraph is better than a sentence. There is a worked example below.
  3. How is the information shaped? Two choices, in plain language. Flexible records suits notes, documents and forms that change shape — it is the usual answer and the one to keep if you are unsure. Strict tables suits uniform records with firm relationships: invoices, inventory, anything financial. This can be changed later by asking.
  4. Is there something to start from? Optional, and the one people skip and then wish they had not. A spreadsheet you have been running this out of, a document describing it, a picture of what it should look like, a page of your own site. See Starting from what you have.
  5. What should it be able to do? Send email, send a text, reach Google Workspace. Nothing is connected at this point and you are not asked for a key — ticking one means the application is built to use it, ready for the day somebody adds the account. Tick nothing if you are unsure; asking later is a sentence in the conversation. See Integrations.
  6. Should it share its information? Keep its own is the usual answer and the first one: nothing this application stores is visible to any other. The alternatives are a store the workspace already keeps, for when two applications are about the same customers — or, if you are an owner, A new shared store, for when this is the first of the two and the store does not exist yet. Making it here rather than afterwards saves creating the application, moving it, and losing whatever it wrote in between. See Where records live.
    Not asked at all when there is no store to choose and you could not make one — a question with one possible answer is not worth a screen.
  7. Who should be able to reach it? The door, in front of the application itself. Anyone with the address, One shared password, People sign in, or Decide later.
    It is asked now rather than left to Settings because it changes what gets built: an application people sign in to needs sign-in screens and knows who is looking, and one behind a shared password needs neither. Finding that out after the screens exist means building them twice.
    Decide later is the honest answer if you do not know yet, and it is the one selected. The builder raises it once while it works, when it can say what each answer would mean for your application. See Who can reach it.
  8. How should it look? A design system. Each is a different way of building — how dense the screens are, whether records live in tables or cards, how much ornament there is — not just a palette. Pick one that feels like the software your team already uses.
    None of them right? Describe it yourself, the last tile, and write what it should be like in your own words. A system still supplies the colours and the type; your words decide the rest and win where the two disagree. All of it is changeable later.

Press the last one and the build starts.

A brief worth writing#

The second question is where the quality of the result is decided. Compare:

A tool to track proposals.

with:

Somewhere for our four salespeople to track proposals. Each proposal has a client, a value, an owner and a stage — draft, sent, in review, won, lost. They need to see their own open proposals first, filter by stage, and see what the team has won this quarter. Anna needs to export the won ones to a spreadsheet at month end.

The second gets you something close on the first attempt. The first gets you something generic that then takes four rounds of correction.

Three things to include, in whatever order they come out:

  • Who uses it, and whether they see different things.
  • What it keeps track of — the records, and the fields that matter.
  • What people actually do with it — the two or three actions that are the point of the whole thing.

You do not need to be exhaustive. Anything you leave out you can ask for later, and asking later costs nothing.

Watch it build#

You land in the workbench: the conversation on the left, the application on the right. Steps appear as they happen — Setting up the database, Building the proposals list, Checking it builds — in plain language rather than as commands.

Early on it stops and shows you a table. These are the records it has worked out your application needs, from your brief: one row per kind of thing, what it holds, and the fields that matter. It is filled in already, so the usual answer is to read it, correct a row and press the button.

It is worth the minute. A screen is an afternoon to change afterwards and a table is not, so this is the one question where being wrong is expensive — and you know things about your own business that were never going to be in a paragraph. See When it asks you.

A first build takes somewhere between five and twenty minutes depending on how much you asked for. You can leave the page and come back; it keeps going.

Try it#

When the build finishes, the Preview tab shows the application running. It is live software, not a picture: type into it, press things, add a record.

Check it on a phone while you are there — the size buttons above the preview render at true phone width rather than squeezing a desktop layout narrow.

Ask for the first change#

Something will be wrong. That is the normal case, not a failure — you are specifying by reaction, which is faster than specifying by imagination.

Say what you want changed, in ordinary words:

The list should show the newest proposals first, and I want the client name before the value.

Add a note field to each proposal. Long text, optional.

The stage filter should remember what I picked last time.

Each of those is one message. It works, it saves a version, and the preview updates.

Put it in front of someone#

When it is worth showing:

  1. Open the Versions tab.
  2. Press Put the latest on Test.
  3. Wait for it to build — a minute or two — and the address appears.

That address is real and works for anyone you send it to. Before you send it, decide who should be able to open it: Settings › Access turns on one shared password, or accounts. See Who can reach it.

Then#