Full operational stacks
ERP, POS, customer apps and dashboards, designed as one system around one source of truth. From the stockroom to the till to the customer's phone.
- ERP
- POS
- Mobile apps
- Dashboards
Corporus designs, ships and keeps running the systems behind businesses where the operation is the business: retail and hospitality, logistics and mobility, education, and platforms that need a real AI layer.
Every week,
of operations move through an AI layer we shipped inside a partner's ERP.
That layer serves
companies, each on its own production data.
Every month,
flows through a retail stack we built from zero: ERP, POS and customer app.
Since 2020,
clients lost on long-term work. The first system we shipped is still running.
Most software is built for the demo: clean data, a quiet afternoon, a polite audience. Ours is built for the Saturday-night rush, the connection that drops at 21:47, the mock exam that opens for everyone at 8:00, the month-end close that cannot be wrong. We design for the worst day. The good ones take care of themselves.
ERP, POS, customer apps and dashboards, designed as one system around one source of truth. From the stockroom to the till to the customer's phone.
Retrieval, local models, caching and mathematical validation on production data, and agent farms that write and check content at volume. The model proposes, the system checks, then someone acts on it.
One team for the web, the internal tools, the integrations and the monthly releases. Years later, you still don't have to re-explain the business.
One backend, three interfaces, one source of truth.
01 / 03Our work
Six systems we designed, built and keep running, for clients and for ourselves. The first four play below as short case studies, redrawn from the real product: what the business needed, what we built, what it changed.
Case study 01 · Education
Simulation Concours
Our own prep platform for the Belgian medical entrance exam: courses, 4,000 practice questions and a free mock exam every Thursday. Launched on 6 July. By the exam on 27 August it was a near-leader, and among the students preparing for it, the Thursday paper had become an institution.
Case study01Simulation Concours
01July
Up to twelve AI agents work side by side on one server. They pause at 90% of the usage window, resume at the reset and pick up where they stopped, for days, with nobody watching.
On screen: The agent farm's dashboard. Each card is an agent writing a series of questions.
Case study01Simulation ConcoursThe result
mock-exam papers sat over five Thursdays
students signed up for the Thursday paper
packs sold in seven weeks, and not one dispute
Launched in July. An institution by August.And no paper went out unchecked.
Read the full caseInterfaces redrawn from the product and shown in English, with example data. Figures from the season report of 8 September 2026.
Case study 02 · Logistics
A freight forwarder
The software behind a Brussels freight forwarder sending parcels to Cameroon, Rwanda, Burundi and the DR Congo: the counter, the warehouse, the labels and the books.
Case study02A freight forwarder
01The counter
18.6 kg on the scale, 60 × 45 × 45 cm on the tape. The counter bills the higher of real and volumetric weight, 20.25 kg here, and shows the clerk why.
On screen: The counter app, adding a parcel to a customer's file.
Case study02A freight forwarderThe result
days from the signed contract to production
records exported from 156 Odoo models
difference across 163 migrated accounting entries
Live in five days.Still shipping two months later.
Read the full caseInterfaces redrawn from the product's demo data and shown in English. Dates from the signed contract and delivery note.
Case study 03 · Hospitality
A restaurant group
Saturday, 21:47.
How the restaurant system we built in 2020 handles the night it was designed for. Four restaurants, two countries, one local network each.
Case study03A restaurant group
Staff phones take orders at the tables. Every order lands on the mini-PC in the back office, the source of truth.
Case study 04 · Mobility
Two chauffeur companies
Websites, booking engines and back offices for two premium chauffeur companies in Brussels: airport runs, corporate accounts and festival weekends.
Case study04Two chauffeur companies
01The quote
The server geocodes both ends, checks festival fares and the fixed airport grid, and only then measures the road. The same code answers every quote on every page.
On screen: The booking form, and what the server does with it, on the map.
Case study04Two chauffeur companiesThe result
languages, one booking flow
pages in Google's index by June, up from 19 in April
localized addresses in the sitemap
Quote, payment, dispatch.The price is decided once, on the server.
Read the full caseInterfaces redrawn from the two products, in English, with an example ride.
How we keep it running
These are real entries from the log of our production deploys, September and October 2026. Every release takes a backup, applies its migrations once, runs its checks and has to pass a health check that refuses errors. The previous version stays one command away.
16 SepFreight, API
Wired to deploy on every push. Health check green.
16 SepFreight, invoicing
Numbering continuous. Next invoice: FVB/2600025.
17 SepFreight, API
Migrations 016 and 017 applied once. 15 receipts archived, 15 checks passed.
02 OctChauffeur site
French, Dutch, English and booking pages answer 200. The old domain answers 301.
03 OctPoint of sale, API
Receipts rendered as 576-dot images on the server. 60 MB, 0 restarts.
04 OctPoint of sale, API
Six analytics pages run read-only against production: 17 to 190 ms.
04 OctPoint of sale, API
Stock import replayed on production data: 14 and 354 lines, 0 difference.
05 OctRecruiting CRM, demo
Every route answers 200. Bundle identical to the local build.
08 OctStock count, perfume retailer
First deploy. 102 brands loaded, login checked, offline manifest served.
The restaurant system we shipped in 2020 still runs four restaurants in two countries, with the same client. We're building its next generation now.
Physical and digital flows that have to agree, in one shop or forty.
Groups running several venues, often where stable connectivity is the exception.
Counters, warehouses and work away from a desk. The software has to follow it there.
Quotes, payments and drivers, in several languages, at three in the morning.
Content at volume and exams that have to be right, for students who get one attempt a year.
Existing products that need a real AI layer inside them, not bolted on top.
That's the sweet spot, not the fence. If the project is serious and the team is committed to shipping it, we want to hear about it.
Not a tool that sits next to it. If the team can work around it, we built the wrong thing.
The rush, the outage, the long close. The demo is the easy part.
Web, mobile, APIs and AI, designed together. Projects break at the seams, so that's where we spend the time.
That's where we work.