PCSOFT charges WinDev and WinDev Mobile applications per session: one session is one executable used by one user on one machine, whether or not the application accesses a database (definition given by PCSOFT in its July 2026 video, which set aside the multiplicative reading of its own pages). Last published list price: 290 € excl. VAT per session per year — recorded on 10 July, removed from the site mid-July 2026: pricing is now quote-only. The circulating 3-year commitment offer: 75 € excl. VAT in year one… then 150 € in year two and 225 € in year three. A threefold increase over three years, on a session count that grows mechanically.
Calculate my exposure The staged exitEnter your application landscape. The calculation runs entirely in your browser: no data is sent, to us or to anyone. The result is a range, and we explain why just below.
Until 9 August this calculator followed the definition displayed on PCSOFT's pages: one session = 1 user × 1 machine × 1 application × 1 database type. In late July, PCSOFT set that reading aside in a video, with an example: an ERP of 10 executables, 2 databases and 500 users is billed 500 sessions, not 10 × 2 × 500.
We therefore removed the database type from the calculation and changed the unit: we now count solutions, not applications. The figures go down, sometimes a lot. If you used this tool before that date, run your estimate again.
The range itself has changed meaning. It no longer measures a counting uncertainty: it measures your negotiation risk, because PCSOFT has never published the rule that tells two solutions apart from two modules of one solution. The lower bound assumes grouping is granted to you. The upper bound assumes it is refused.
| Application | Users | Machines | Real workstations* | Executables** |
|---|
* Workstations = user-machine combinations actually in service. Leave
“auto” if you don't know them: we then use max(users, machines). This is the
real counting basis. Rule published by PCSOFT: a session is activated for 30 days and
automatically released if unused, so in steady state only genuinely
active workstations count. Developer workstations? A circulating sales answer says they
are excluded, forum testimonies say the opposite, and the July video does not settle it:
get it confirmed in writing.
** Executables in the solution. This is where your range is decided. In its
video, PCSOFT groups the executables of a single solution: 10 executables used by
500 people make 500 sessions, not 5,000. But PCSOFT has published no
rule telling two solutions apart from two modules of one solution. The lower bound
assumes grouping is granted, the upper bound assumes it is refused. Have the list of
grouped executables written into your purchase order.
| Estimated sessions (realistic → maximum) | — |
| Year 1 (full price) | — |
| Year 2 (full price) | — |
| Year 3 (full price) | — |
| 3-year commitment total (full price) | — |
| 3-year total with negotiated discount | — |
| After complete migration out of WinDev (stage 3) | 0 sessions*** |
WinDev and WinDev Mobile are affected by per-session pricing (official “Offers” page). For WebDev, nothing published, nothing priced to date — but the sales-desk answers reported on specialist forums, consistent since late May, already sketch a model. Here is how to read that uncertainty.
Since the video PCSOFT published in late July 2026: one session = one executable used by one user on one machine, whether or not the application accesses a database. The executables of a single solution are grouped: the example given is an ERP of 10 executables and 2 databases used by 500 people, billed 500 sessions. Sessions are activated for 30 days and automatically released if unused. Prices: 290 € excl. VAT list, 225 € under “Solutions & Services” offers, and 75 / 150 / 225 € on a 3-year commitment. The fate of developer workstations remains contradictory across sources.
No priced decision yet, but the first elements circulating sketch a distinct model: a fixed part computed on the server (number of cores and GB of RAM) and a variable part based on the number of HTTP requests per day, averaged over a month. In other words: exemption was never the plan. Traffic-based billing tracks your audience, not the value you get from it — and migrating to WebDev to escape sessions is not a strategy.
The WebDev uncertainty doesn't change the underlying logic: it is the dependency on the PCSOFT runtime that exposes you to the grid, whatever the product. Moving the data out (stage 2) then the application itself, module by module (stage 3), protects you in every scenario — WebDev exempt, WebDev billed, or the grid changed yet again.
The model, as reported to us: 4,490 € excl. VAT per C.U per year with no commitment. Under a “Fidélité” loyalty offer over three years the C.U drops to 1,490 € in year 1, 2,990 € in year 2 and 4,490 € in year 3 — year three lands exactly on the no-commitment rate, the same spring as on the session side.
The estate is added up before it is converted, and that sum includes test and staging servers — “even though they are used less”. The two examples given: one server with 8 vCPU and 12 GB makes 2 C.U; two servers of 8 vCPU/8 GB and 8 vCPU/24 GB, “a combined 16 vCPU and 32 GB”, make 4 C.U. Note this carefully: taken separately those two servers would be 2 and 3 C.U, which is 5. The grid is not linear, and pooling costs less than billing server by server.
| Server role | vCPU | GB of RAM | What it adds* |
|---|
* What it adds = what the estate costs with this server, minus what it would
cost without it. On a stepped grid that is the only honest measure, and it has a consequence
that surprises people: these figures do not add up to the total, and a small
server can show + 0 € because it fits inside a unit you already pay
for. The reverse holds too: the server that tips a unit over carries the price of that whole
unit on its own.
Your staging server counts. That is what this calculator exists to show:
nothing in what has been reported to us exempts a working environment, nor a
passive high-availability node, which serves nobody at all.
** These two values are deduced, not published, which is why they are editable like the prices. PC SOFT did not give the definition of a C.U: we rebuilt it from the only two worked examples. 4 vCPU and 8 GB per unit, taking whichever dimension is more demanding and rounding up, is the only pair where both dimensions land exactly right in both examples. But those same examples would also be explained if RAM did not count at all: on a 4 vCPU, 32 GB server the two readings give 4 C.U or 1 C.U. Get the definition of a C.U confirmed in writing — it is worth a factor of four on your bill.
| Combined estate capacity | — vCPU and — GB |
| Billable capacity units | — C.U |
| Year 1 | — |
| Year 2 | — |
| Year 3 (reaches the no-commitment rate) | — |
| Loyalty offer total over 3 years | — |
| The same estate with no commitment, 3 years | — |
| What your non-production servers cost you (— C.U) | — |
This calculator only sees the surface. The dependency audit — fixed price, on documents, with no access to your production data — gives you the facts; then each stage is decided separately and has its own value.
A map of your database and its access points, a forecast PCSOFT invoice on your real figures (as a realistic → maximum range), measured exit complexity, and the mechanical replacement rate of your data access. The analysis is tooled: a profiler reads the full project and ranks tables, fields and processes by actual weight — the costing is measured, not guessed. A costed, factual and verifiable report. Fixed price.
Your data migrated to PostgreSQL, your WinDev or WebDev application reconnected as is, with exhaustive verification delivered (counts, checksums, sampling). You no longer depend on HFSQL. Price per database.
Your modules leave one by one for a modern web application (Rust + JavaScript), produced by our generation tools built on design patterns — the existing WinDev system keeps running during the transition, on the PostgreSQL of stage 2. Every migrated module removes its workstations from the grid; the last one ends the billing. You set the pace. Fixed price per module.
A migration is judged on its method and on who carries it out, not on the promise.
Unidus is a software craftsman who spent years inside the WinDev/WebDev ecosystem — with software vendors and with end clients — before rebuilding his entire toolchain in Rust and JavaScript. Your windows, your reports, your HFSQL analyses: he reads them fluently. Nobody "discovers" your application on your invoice.
The target is produced by in-house generation tools built on industry design patterns: every screen, every data access, every rule goes through the same mould, proven by thousands of automated tests. That is what makes the migration reproducible — and its schedule sustainable for a lean structure.
Every stage ships its proof: counts, checksums and sampling for the data; dated, sourced reports for the figures. The same discipline as this calculator — publicly corrected, downwards, when a source disproved it.
PCSOFT charges WinDev and WinDev Mobile applications per session. Since the video PCSOFT published in late July 2026: one session = one executable used by one user on one machine, whether or not the application accesses a database, and the executables of a single solution are grouped. The example PCSOFT gives is an ERP of 10 executables and 2 databases used by 500 people, billed 500 sessions, and not 10 × 2 × 500. Sessions are activated for 30 days and automatically released when no longer used. Prices: 290 € excl. VAT list, 225 € under “Solutions & Services” offers, and 75 / 150 / 225 € on a 3-year commitment, a threefold increase over three years. The “Offers” page bundles sessions (5 to 100 from Bronze to Titanium) and carries a discount reserved for subscriptions taken at least 90 days before expiry.
On the number of workstations actually in use (real user-machine combinations), and on how many executables PCSOFT agrees to group into a single solution. The database type no longer counts since July 2026. Our calculator above gives a range, and that range now measures a negotiation risk rather than a measurement uncertainty: the lower bound assumes grouping is granted, the upper bound assumes it is refused. As conditions remain negotiated case by case, these amounts are exposure estimates, never certain invoices.
No priced decision to date, but WebDev will not stay free: the first elements circulating (July 2026, no figures) sketch a distinct model — a fixed part computed on the server (number of cores and GB of RAM) and a variable part based on the number of HTTP requests per day, averaged over a month. Migrating to WebDev to escape sessions is therefore not a strategy: you change the meter, not the dependency. Traffic-based billing also raises its own questions (do crawlers count? what does a traffic spike cost?). Our staged approach protects you in every scenario, because it reduces the dependency itself, not just today's invoice.
Not publicly settled. A circulating sales answer (July 2026) says developer workstations are not counted; testimonies on specialist forums claim the opposite. In the absence of a rule published by PCSOFT, get this point confirmed in writing before any commitment — exactly the kind of grey area a dependency audit documents for your file.
WinDev Mobile is part of the commercial grid — the "Offers" page covers the whole suite, "three native targets" — but the "Sessions" page, the one that defines the counting, mentions neither mobile, nor Android, nor iOS: its definition speaks of an "executable, service, DotNet assembly" on a physical or virtual machine — desktop and server vocabulary. If a phone counts as a machine, a field fleet of 200 smartphones hitting HFSQL would represent 200 sessions — mechanically worse than a fleet of fixed workstations, since every field agent carries their "machine" in their pocket. Nothing is published on this point: if you deploy WinDev Mobile applications, get the mobile counting rule confirmed in writing before any commitment.
No — and above all not in one go. We proceed in stages: a costed dependency audit, then the migration of the data from HFSQL to PostgreSQL (your application reconnected as is), then, if and when you decide, the batch migration: your modules leave one by one for a modern web application, produced by our generation tools, while the existing system keeps running. Never a big bang: your WLanguage business code — your real value — remains the reference until its module has left, proven and verified.
Through the number of workstations, and through that alone. We must correct what this page said until 10 August 2026. Freeing an application from the database connectors reduced the invoice as long as the database type counted. PCSOFT has since clarified that it counts “one executable used by one user on one machine”, whether or not the application accesses a database. Leaving HFSQL keeps all its value (portability, liberated data), but it no longer lowers this particular invoice. Two negotiation levers remain: the number of workstations, and the grouping scope negotiated in your purchase order, which can move the amount by a factor equal to your number of executables. And one structural lever: every module migrated out of WinDev (stage 3) removes its workstations from the grid — the last one ends the billing.
No. The audit is done on documents, from an export of the structure of your database and your application landscape — without any access to your production data. You receive a costed, factual and verifiable report, at a fixed price. Reply within 48 hours.
That's exactly why you should request the dependency audit. Reply within 48 h.
Request a dependency audit Chat on WhatsAppWhatsApp: free and instant, including from the European Union or Switzerland.
