If your feed is JavaScript and Python, you can go a whole career without hearing the word WinDev. Meanwhile it is quietly running warehouses, pharmacies, garages and logistics operations across France — the kind of software that never gets a Show HN and never stops being paid for.
I have spent real time in it. Here is an honest account, because "it isn't on GitHub" is not an analysis.
What it actually is
WinDev is an AGL — atelier de génie logiciel, a software engineering workshop — from the French vendor PC SOFT. It is a 4GL in the old sense: not a language you add libraries to, but a single product that contains the entire toolchain.
One purchase gives you:
- WLangage, a proprietary language whose keywords exist in both French and English
- an IDE, a GUI designer, a report designer and a query builder
- HFSQL, its own database engine, alongside connectors for SQL Server, Oracle, Postgres and MySQL
- GDS, its own source control system
- one-click deployment to Windows desktop, Linux, web and mobile
Three products share that core. WinDev builds desktop and Windows services. WebDev builds web applications and web services from the same language. WinDev Mobile builds Android and iOS apps, including for industrial barcode terminals. Projects can share code between all three.
That last point is the pitch. One developer, one language, one database, and a Windows client, a browser app and a handheld terminal app that all talk to the same schema.
What it is genuinely good at
Line-of-business CRUD, very fast. Screens bound to tables, validation, grids, filters. The kind of thing a React team spends a sprint assembling from libraries appears here in an afternoon, because it is a first-class feature rather than an ecosystem choice.
Printing and reports. Labels, delivery notes, invoices, barcodes, a preview window that matches the printer. The JavaScript ecosystem is still bad at this. In an AGL it is a designer and a function call, and it works with the Zebra on the packing bench.
Industrial hardware. Barcode terminals, scales, label printers, serial devices. Support for the hardware a warehouse already owns is in the box, not a native module somebody abandoned in 2019.
A deployment story IT departments accept. A signed executable, an installer, a Windows service, an on-premise SQL Server. No container runtime, no Node version, no build pipeline. For a company whose IT is one person who also fixes the printers, that is not a limitation — it is the requirement.
What it costs you
I am not going to pretend the trade is free.
It is proprietary and paid, per seat, and major versions are a purchase rather than an upgrade. There is no meaningful open-source ecosystem — no package registry, no Stack Overflow depth; when you hit something odd you read the vendor documentation or the francophone forums, and that is the whole world. Hiring is hard outside France and a few francophone markets. Source control is GDS rather than git, so the branching and review habits the rest of the industry converged on do not transfer. And the language is verbose in a way that ages: you write a lot of lines to say a small thing.
If I were starting a consumer product tomorrow, I would not choose it. That is a different statement from "it is bad".
The pattern worth stealing
The most interesting thing I took from this world is not the tooling. It is how these systems drive handheld terminals in a warehouse.
The naive approach is to build a mobile app with the business logic inside it, talking to an API. In a warehouse that goes wrong quickly: the terminals are cheap and slow, there are two hundred of them, the Wi-Fi has dead zones near the racking, and pushing an update to all of them is a project.
The pattern these suites use instead is a server-driven UI:
[ barcode terminal ] [ Windows service ]
thin renderer keystroke all business logic
no business logic ───────────────▶ talks to SQL
no local state builds the next screen
◀───────────────
screen content
A Windows service on the customer's server holds every rule and every database call. The handheld application does two things: send what the operator pressed, and draw whatever comes back. The "UI" is a text screen with a function-key menu — F1=RECEIVING, F2=PICKING, F3=STOCK — that an operator drives at speed without looking at it.
It sounds primitive. It is extremely well matched to the problem:
- Business logic changes without touching 200 devices. You restart one service. There is no app store, no staged rollout, no device left on an old version for eight months.
- The terminal holds no state. A flat battery mid-pick loses nothing, because nothing was ever on the device.
- A function-key menu is faster than a touch UI for someone wearing gloves, holding a scanner, reading a rack.
- Debugging is one place. The service has the logic and the logs; you are never reconstructing what a handheld thought it was doing.
And the honest limits: it needs a stable LAN — every keystroke is a round trip, so it is unusable over a flaky link; there is no offline mode, by construction; and the interaction model is dated in any context where a customer, rather than a trained operator, is the user.
Where you have seen this before
That diagram is server-driven UI, and the industry rediscovered it about three years ago. React Server Components send rendered output rather than data. Hotwire and LiveView ship HTML fragments over a socket instead of JSON for a client to interpret. Stripe and Airbnb have both written about server-driven layouts in their mobile apps so they can change a screen without shipping a build.
The motivation is identical in every case: keep the logic where you can change it, and make the client a renderer. Industrial software arrived there twenty years earlier because the constraint — slow devices, hundreds of them, impossible to update — was inescapable rather than merely annoying.
The takeaway
There is a large, well-paid category of software that is invisible from inside the open-source bubble, and it is not badly built. It made different trade-offs because it faced different constraints: on-premise deployment, industrial hardware, one-person IT departments, twenty-year lifespans.
You do not have to want to work in it. But the next time you are designing for constrained clients you cannot reliably update, the answer may well be one that a French 4GL shipped in the nineties.