For teams of 50 to 1,000
Describe the application your team needs.
Desifex builds it, runs it and keeps it up to date — a real application on a real address, not a mock-up. And the parts a real business needs are already in it: people signing in, email and SMS, documents to download, your own domain.
Not open to the public. We set each customer up ourselves, so a workspace arrives with the right design system, the right people and somebody who knows your name.
Somewhere to track proposals — who owns each one, what stage it is at, and what we have won this quarter.
- Reading what you asked for
- Setting up the database
- Building the proposals list
- Adding the stage filter
- Checking it builds
Proposals
Q3Open
18
Won
7
Value
£412k
- A real application
- Nuxt source, its own database, its own storage, in its own container. It builds for production or it does not go out.
- Isolated per environment
- Every application — and every environment of it — has its own network, database, cache and bucket. Nothing crosses between them.
- Nothing ships by itself
- A build changes what only you can see. Test and live are decisions a named person takes, recorded with the reason they gave.
- Yours to take away
- An ordinary repository with ordinary history. Download the source and a developer you hire tomorrow will recognise all of it.
How it works
01
Describe what your team needs
In a sentence or a page, in your own words. Show it a spreadsheet or a screenshot if that is faster. No ticket, no specification, no meeting to turn one into the other.
02
It gets built while you watch
A real application is scaffolded, given its own database and container, and worked on — code written, run, read back and fixed — narrated in plain language as it happens. Interrupt it and change your mind at any point.
03
You decide when anyone else sees it
Try it privately. Put it in front of colleagues on a real address. Put it live when it is right. Every build is saved as a version you can name, compare and go back to.
What you get
We cover what a real business needs
Anything can generate a screen. What decides whether your business can actually run on the result is the unglamorous half — who is allowed in, how it emails somebody, where the PDF lives, what happens to the old address, what a link to it looks like in Slack.
All of that is already here, built once and kept working. You do not specify it, nobody builds it for you, and it does not get dropped because the deadline moved.
Who is allowed in?
- Everyone — it is public
- Anyone with the address. The right answer for a form or a public page.
- One shared password
- Everyone types the same password once. Nothing to set up per person.
- Accounts, per application
- One account per person, with two-step sign-in by email code or authenticator.
- One account across every application
- Turn it on and your people sign in to all of them with one account — nobody re-registers.
All four are enforced in front of the application, so they hold while a build is broken or a deployment is mid-flight — and a later build cannot switch them off by accident. In detail
Can it reach people, and hold their documents?
- Postmark, Mailjet, Mailgun, Resend, SendGrid, or your own SMTP server.
- SMS
- Telnyx or Twilio.
- Google Drive, Docs and Calendar
- Connected per application by consent, so revoking one leaves the others working.
- Files people can download
- Upload a price list or a brochure and it gets a permanent address on your own domain. Replace it and the link keeps working.
Your application never holds a credential for any of these. It asks the platform, which means changing provider is a settings change rather than a rebuild — and an application that is compromised cannot walk off with your email account. In detail
Does it look and behave like real software?
- Your own domain
- One per environment, with the certificate issued before the first visitor arrives.
- Link previews and icons
- The browser tab, the icon, and what a link looks like pasted into Slack — set once, applied on every deployment.
- Redirects
- Old addresses that still get visited, answered in front of the application so they work even when it does not.
- Search engines
- Per environment. Test is closed by default; live is open.
- Installable on a phone
- Add it to a home screen and it behaves like an application.
- Visitor figures
- Who is using it, per environment — no cookie, no stored identifier, nothing to put a banner up about.
Every one of these is a setting rather than code, so a later build cannot undo it and nobody has to remember to ask. In detail
No settings hunt
If you do not know where a setting is, ask
The conversation is not only for building screens. It reaches the whole of the platform — the address, the icon, the redirects, the integrations, who can sign in, what search engines are told, and shipping a version to test or live.
So nobody has to learn where anything lives. Ask for the outcome and it is configured, in the same conversation you were already having.
It acts as you, not as itself. Your permissions are resolved and enforced in exactly the code the buttons go through, so somebody who could not deploy by pressing the button cannot deploy by asking nicely. It will not ship anything you did not ask it to ship — an ambiguous request gets finished and asked about. And it is never given your secrets: it can create a configuration value by name, and it will tell you to paste the key in yourself.
Things people actually type
- Put this on proposals.acme.com and check the DNS.
- Use the logo I uploaded as the icon, and set the tab title to Proposals.
- Send /old-pricing to /pricing permanently.
- Turn on the shared password and give it to me.
- Add anna@client.com as a user and email her the password.
- Connect Postmark and send a test.
- Call this one “First release” and put it on test.
Design systems
One brand. Everything you build wears it.
Set your brand up once — from your guidelines, your website or your Figma library — and every application in the workspace is built in it. Not a palette: the colours and type and a brief the builder designs from, so the fifth application looks like it came from the same company as the first.
Working for clients? A design system per client, in a workspace per client — and one account belongs to as many of them as you need. Everything you hand over matches their brand rather than ours, and nothing of one client's is visible from another's.
Thirteen ship with the platform, to start from
Real screens, drawn by the builder in each one. Start from whichever is closest to how your team's software should feel, and change what you need.
Nothing goes live because a build finished
A build changes the preview, which only your team can reach. Moving a version to test, and a tested version to live, are separate decisions — taken by a named person, recorded with the reason they gave, and refused outright if the version does not build.
Each environment keeps its own database. A version being tested cannot write to what the business is running on.
Security
Built to survive your security review
An application gets its own network, database, cache and storage bucket, per environment. It holds no credential for any third-party service — email, SMS and Google are the platform's, called through a token that asks for a capability rather than carrying a key.
How it is put togetherEverything it does is written down
The documentation is public and complete — how to build your first application, how versions and environments work, what every setting does, how people sign in, and what a developer taking one over needs to know. Read it before you talk to us if you would rather.
Ask us for access
Tell us what your team keeps asking for. We will reply with a time to show you it being built — not a recorded demonstration of one that was built earlier.
If you are reviewing this on behalf of somebody else, say so and we will send what your security and procurement people need first.