What Desifex is

You describe an application your team needs. Desifex builds it — a real web application with its own database, its own address and its own users — runs it, and keeps working on it as you ask for changes.

The unusual part is not that software writes the code. It is that the technology is not yours to choose. Every application built here uses the same framework, the same two database options, the same file storage, the same way of sending an email. You get one decision about the machinery, and it is a small one.

That constraint is the product. It is what lets somebody who is not a developer own the result, what lets every application be reviewed the same way, and what lets a developer take one over without an archaeology session.

What you get#

Not a prototype, and not a mock-up that is thrown away when the real work starts. The first build produces the actual application, and every change after it changes that same application.

• Real software. A Nuxt application with its own database, its own cache, its own file storage, in its own container. It builds for production or it does not go out.
• A real address. proposals.yourcompany.com, with a certificate, or a domain you own pointed at it.
• Real users. Your colleagues or your customers, signing in with accounts, or behind one shared password, or nobody at all if it is public.
• Ordinary source code. A git repository a developer can open, with history. You can download it whenever you like.

What it will not do#

Worth knowing before you start, because these are design decisions rather than things on a roadmap.

It will not use a service we have not implemented. Email, SMS and Google Drive, Docs and Calendar are built in. Something else — a payment provider, a CRM, an internal API — is not available as a connected service, though an application can of course call an ordinary HTTP API with a key you configure.

It will not let you choose the framework. Not React, not a different CSS system, not a different server. Asking for one is the one request the builder will decline.

It will not deploy because it finished. A build changes a preview only your team can reach. Putting something in front of anybody is a separate, deliberate act. See Environments.

It will not show you code. There is no source browser and no log viewer in the interface. Builds are narrated in plain language; a failure arrives as a sentence rather than a stack trace. If you want the code, you download it.

Who it is for#

Somebody who knows what the business needs and has been waiting for it: a product manager, an operations lead, somebody in sales who keeps rebuilding the same spreadsheet. You need to be able to describe what you want and to judge whether what came back is right. You do not need to know what a database is.

It is also used by developers, for the unglamorous internal tool that would otherwise sit at the bottom of a backlog for a year.

Who is not the audience#

If what you need is a large, long-lived product with a team of engineers on it, this is the wrong shape. Desifex is at its best on the application that is genuinely useful and genuinely nobody's priority — the supplier portal, the survey tool, the tracker that lives in a spreadsheet and should not.