Skip to content
Case study01Education, Brussels. Our own product.

Simulation Concours: a near-leader in under two months.

papers

mock exams sat over five Thursdays

Scope

Design, build and run a prep platform for the Belgian medical entrance exam: courses, question bank, PDFs, a weekly mock exam, payments, and the content pipeline behind all of it.

Context

Students get one attempt a year, prep courses cost thousands of euros, and the exam was seven weeks away. We made the library and the Thursday exam free, and sold one pack for the rest. By exam day it was a near-leader: among the students preparing for the exam, the Thursday paper had become an institution.

What we built

  1. 01

    An agent farm on one server

    One process runs a bounded pool of headless agents, pauses at 90% of the usage window, resumes at the reset and never pays twice for finished work. A live dashboard shows every agent and the exact prompt it was given.

  2. 02

    Gates before anything ships

    Parsing, unique ids, a LaTeX round-trip, at least 99.5% of the source words kept and every formula identical. One source feeds the web pages and the watermarked PDFs.

  3. 03

    Blind solvers and a refuter

    Two agents answer each paper from a copy with the key removed; a third, with the key, tries to refute it. A script also checks that the right answer isn't suspiciously often the longest one.

  4. 04

    The Thursday exam

    80 original questions scored on the official scale out of 160, open from 8:00 to midnight, on screen or on a printed booklet. A ranked report the next morning, with three revision sheets picked from the paper.

  5. 05

    Payments and access

    One-time codes instead of passwords, Stripe with Bancontact and Apple Pay, and every page and PDF checked on the server before it's served.

accounts in seven weeks

students signed up for the Thursday paper

of opened checkouts paid

Built withNext.jsMySQLStripeLaTeX and KaTeXHeadless ChromeClaude agents

Launched in July, an institution among candidates by August. And every paper went out checked.

Case study02Freight, Brussels.

A freight forwarder's counter, warehouse and books, live five days after signing.

days

from signed contract to production

Scope

Replace a custom Odoo module and website with one system: the counter, the warehouse scanner, the label printer, invoicing and the export to accounting.

Context

A Brussels company sending parcels to Cameroon, Rwanda, Burundi and the DR Congo. The contract is dated 29 July 2026, the delivery note 3 August. Their history had to come across, books included.

What we built

  1. 01

    The counter

    Files, parcels, quotes and payments. Each parcel is billed on the higher of real and volumetric weight, with negotiated rates and credit notes when something changes.

  2. 02

    Silent labels

    A Windows app at the counter prints barcode and QR labels on the thermal printer without a dialog, and diagnoses the printer over the network when it doesn't answer.

  3. 03

    The warehouse scanner

    A phone app scans parcels into suitcases, pallets and containers, shows the weight against the limit, and flags a parcel bound for another destination.

  4. 04

    Invoices and accounting

    Numbering that continues the old Odoo series and can't be edited, receipts archived, notifications by email and WhatsApp, and a numbered export for the accountant.

  5. 05

    The migration

    59,453 records from 156 Odoo models exported, and 163 accounting entries moved to a newer Odoo without a cent of difference. Every clean-up in production is rehearsed and undone before it runs for real.

records out of Odoo

accounting entries, €0.00 difference

surfaces: counter, warehouse, print station, public site

Built withNode and ExpressMySQLReactElectronPWA scannerCloudflare R2

Live in five days. Still shipping two months later.

Case study03Hospitality, offline-first

A restaurant system across two countries, live since 2020.

churn

four restaurants, still running it

Scope

An end-to-end operational system for a hospitality group: multi-device, offline-first, with owners online.

Context

Four restaurants in two countries, where the internet is a sometimes thing. That constraint shaped every decision: the system runs whether the connection does or not.

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

What we built

  1. 01

    Central Linux POS

    A small headless mini-PC in each restaurant holds the source of truth on the local network. It survives outages and runs the floor.

  2. 02

    Ordering on staff phones

    Servers take orders at the table and send them straight to the kitchen and the bar, across devices and floors.

  3. 03

    Ticket routing

    Each ticket prints where it belongs, bar or kitchen, based on the product. Nobody sorts tickets by hand at peak.

  4. 04

    Real-time stock

    Stock counts down with every order, on every device. The end-of-night count is already done.

  5. 05

    Offline-first by default

    Orders, payments and prints all run on the local network. The internet is a way to sync, not a requirement to work.

  6. 06

    Cloud sync and owner dashboard

    The day syncs to the cloud in batches. Owners follow revenue, recipes and performance across every venue, from anywhere.

One of the systems we're proudest of. Not the biggest. The one that's still running, five years in, in exactly the conditions it was built for.

Case study04Mobility, Brussels.

Two chauffeur companies whose sites quote, take payment and dispatch.

pages

in Google's index by June, up from 19

Scope

Sites, booking engines and back offices for two premium chauffeur companies: live quotes, online payment, driver dispatch, and price grids the owners edit themselves.

Context

Airport runs, corporate accounts and festival weekends, booked by travellers, assistants and hotel concierges, in French, Dutch and English at the very least.

What we built

  1. 01

    One quoting engine

    The server geocodes both addresses, checks festival fares and the fixed airport grid by radius, then falls back to the road distance. The same code answers the live quote and the checkout.

  2. 02

    Checkout that trusts nothing

    Stripe for one company, Mollie for the other. The amount is always recomputed on the server, the booking is saved before payment, and refunds go out from the back office.

  3. 03

    Dispatch by link

    The office picks a driver and a vehicle and sends the ride by email or WhatsApp. The driver answers from a one-time link and only sees their own fee.

  4. 04

    Five languages, localized pages

    Every page in French, Dutch, English, German and Spanish, generated pages per route, city and airport, structured data, and cookie-free analytics of our own.

languages on one booking flow

localized addresses in the sitemap

pages generated in three languages for the second company

Built withNext.jsMySQLStripeMollieGoogle Maps APIsResend

Quote, payment, dispatch. The price is decided once, on the server.

Case study05AI in production

An AI layer inside an ERP that serves 70+ companies.

a week

of customer operations through the layer

Scope

Architect and ship the full AI layer of an existing ERP, end to end.

Context

We didn't build the ERP. The team behind it brought us in because their customers needed AI that runs on real production data, not a chat window bolted on top. They trusted us with the architecture, the build and the launch.

ERP dataCleaningVector DBCacheLocal LLMValidationReport

What we built

  1. 01

    Cleaning and ingestion

    Each customer's production data, prepared for retrieval in the real shape of their business. Edge cases are handled in code, not handed to the model.

  2. 02

    Vector database and retrieval

    Retrieval shaped around the ERP's data model, with vectorization tuned per data class. Queries are reconciled with the source of truth before anything is generated.

  3. 03

    Caching

    The system never pays twice for the same thought. Vectors are batched and persisted, so cold starts stay predictable under load.

  4. 04

    Local language models

    Self-hosted where data, latency or cost rule out an API. Chosen for what the system needs, not for ideology.

  5. 05

    Mathematical validation

    Anything that touches finance, operations or stock is checked against the underlying numbers before it leaves the system. The model proposes. The system checks.

  6. 06

    Reports on request, in chat

    A manager asks for a custom report in plain language. The system produces it on their own data: formatted, validated, reconciled.

The result is an automated manager that 70+ companies trust with $5M+ of operations every week. Not an API wrapper. A system.

Case study06Full operational stack

The whole backbone of a specialty perfume retailer.

a month

in operations on the system

Scope

Design and ship the entire operational stack from scratch: internal ERP, custom POS and a customer ordering app.

Context

Off-the-shelf POS, ERP and ordering tools didn't talk to each other, and none of them fit the way perfume is actually sold. We built one system with three interfaces instead.

Internal ERPCustom POSCustomer appOne backend, one source of truth

What we built

  1. 01

    Internal ERP

    Inventory, suppliers, purchase orders, stock movements and staff, on one backend and one schema. Built for the people who use it every day.

  2. 02

    Custom POS

    Designed around the real choreography of a perfume sale: sampling, several items, gift wrapping, recognising the customer.

  3. 03

    Customer ordering app

    Customers order, staff fulfil, stock updates in real time. Same source of truth, no overnight reconciliation.

  4. 04

    One backend

    The three interfaces share one schema and one source of truth, so the warehouse, the till and the phone always agree.

  5. 05

    A stock count that works offline

    Since October 2026, the stock is counted on phones that keep working without a connection: every tap is queued, sent in batches and never counted twice. 2,311 products from 102 brands.

One backend. Three interfaces. One source of truth. The point was never to ship three apps. It was one system that behaves like one, from the warehouse to the till to the customer's phone.

Smaller systems.Same principle.

Beyond these six, we've shipped smaller operational systems: internal dashboards, custom workflows, integrations between tools that never talked to each other. Different scopes, same rule: software that runs the business, not software that sits next to it.

  • Home healthcare

    Brussels

    Live

    Site and back office, with analytics that store no cookies and no IP addresses. A model drafts the articles; a person publishes them.

  • Two shops, one owner

    Retail

    Launching

    Handheld tills that print receipts designed in the browser and update over the air, with one loyalty balance across a menswear boutique and a fishmonger.

  • A recruiting agent

    Brussels

    Demo live

    The model picks a level for each criterion and quotes the profile; plain code adds up the score. Nobody is rejected automatically.

Systems we keep running.

Active retainers with several companies: web presence, internal tools and monthly evolutions. Four production websites shipped for retail and hospitality along the way.

production websites, retail and hospitality

The kind of relationship where nobody has to re-explain the business every quarter.

Got something like thisin your operation?