Skip to content

Software built torun.Not to demo.

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.

The proof is in production.

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.

Three kinds of work.Often all at once.

01

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
Internal ERPCustom POSCustomer appOne backend, one source of truth
02

AI inside real systems

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.

  • Local LLMs
  • Vector retrieval
  • Agent farms
  • Validation
03

Systems we keep running

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.

  • Web
  • Internal tools
  • Integrations
  • Monthly releases
LaunchTodayWebInternal toolsIntegrations

Case study 01 · Education

Simulation Concours

A near-leaderin under two months.

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.

Client
Our own product
We built
The platform, its AI content pipeline, payments
Timeline
Live 6 July, exam 27 August 2026

Case study01Simulation Concours

01July

A fleet of agents writes the library.

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 case

Interfaces 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

Signed on a Wednesday.Live on Monday.

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.

Client
A freight forwarder, Brussels
We built
Counter app, warehouse scanner, label printing, invoicing
Timeline
Contract 29 July, live 3 August 2026

Case study02A freight forwarder

01The counter

The heavier number wins.

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 case

Interfaces 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.

The internetgoes down.

How the restaurant system we built in 2020 handles the night it was designed for. Four restaurants, two countries, one local network each.

Client
A restaurant group, two countries
We built
Linux POS, staff ordering, ticket routing, owner dashboard
Live since
2020, four restaurants

Case study03A restaurant group

19:30Saturday
Internet: upFloor: running

Service starts.

Staff phones take orders at the tables. Every order lands on the mini-PC in the back office, the source of truth.

Mini-PC, source of truthBarKitchenCloud, in batchesOwner dashboardLocal network, runs without internet

Case study 04 · Mobility

Two chauffeur companies

The browser neversets the price.

Websites, booking engines and back offices for two premium chauffeur companies in Brussels: airport runs, corporate accounts and festival weekends.

Client
Two chauffeur companies, Brussels
We built
Sites, quotes, online payment, driver dispatch
Languages
French, Dutch, English, German, Spanish

Case study04Two chauffeur companies

01The quote

Two addresses in. A price out.

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 case

Interfaces redrawn from the two products, in English, with an example ride.

How we keep it running

We don't stop at launch.Here is our release log.

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.

deploys to production between 15 September and 8 October
apps that redeploy themselves on every push
days of nightly backups kept for the freight system
Release log, production16 Sep to 08 Oct 2026
  1. #40

    16 SepFreight, API

    Wired to deploy on every push. Health check green.

    Health 200Rollback ready
  2. #47

    16 SepFreight, invoicing

    Numbering continuous. Next invoice: FVB/2600025.

    Health 200Rollback ready
  3. #51

    17 SepFreight, API

    Migrations 016 and 017 applied once. 15 receipts archived, 15 checks passed.

    Health 200Rollback ready
  4. #92

    02 OctChauffeur site

    French, Dutch, English and booking pages answer 200. The old domain answers 301.

    Health 200Rollback ready
  5. #94

    03 OctPoint of sale, API

    Receipts rendered as 576-dot images on the server. 60 MB, 0 restarts.

    Health 200Rollback ready
  6. #102

    04 OctPoint of sale, API

    Six analytics pages run read-only against production: 17 to 190 ms.

    Health 200Rollback ready
  7. #106

    04 OctPoint of sale, API

    Stock import replayed on production data: 14 and 354 lines, 0 difference.

    Health 200Rollback ready
  8. #108

    05 OctRecruiting CRM, demo

    Every route answers 200. Bundle identical to the local build.

    Health 200Rollback ready
  9. #117

    08 OctStock count, perfume retailer

    First deploy. 102 brands loaded, login checked, offline manifest served.

    Health 200Rollback ready

Our first system is still running.

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.

2020First system live
2024Second generation
2026Next one, in the works

Businesses where the software has to run.

  • Retail

    Physical and digital flows that have to agree, in one shop or forty.

  • Hospitality

    Groups running several venues, often where stable connectivity is the exception.

  • Logistics and field services

    Counters, warehouses and work away from a desk. The software has to follow it there.

  • Mobility

    Quotes, payments and drivers, in several languages, at three in the morning.

  • Education

    Content at volume and exams that have to be right, for students who get one attempt a year.

  • Platforms and ERPs

    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.

Three thingswe won't trade.

  1. 01

    Software that runs the business.

    Not a tool that sits next to it. If the team can work around it, we built the wrong thing.

  2. 02

    Built for the worst day.

    The rush, the outage, the long close. The demo is the easy part.

  3. 03

    End to end, on purpose.

    Web, mobile, APIs and AI, designed together. Projects break at the seams, so that's where we spend the time.

You know the part of the business that breaks first when it gets busy?

That's where we work.