Enterprise applications in .NET and Angular, and native mobile apps. TBL-IT works on assignment with its clients and builds its own software — from design through to release. From the first screen to the server that answers.
An application does not end at its interface. What makes it dependable happens where nobody is looking.
The domain kept apart from everything around it: a business rule knows nothing of the database or the transport, and can therefore be tested without starting either. The principle does not depend on the language, only on the discipline — the same one holds up our own services, written in Rust.
Portals and admin consoles in Angular — the kind of screen a team opens every morning and keeps open all day. What matters then is not the visual effect, it is how many gestures it takes to get today’s work done.
An Angular application that becomes an installable app on iOS and Android, distributed internally or through the stores. One codebase when it serves the product better than two — and two when the app touches hardware, media or security.
iOS and Android written in their own languages. And then what few teams go looking for: the television in the living room, the screen in the car, the watch. Each has its own rules — a remote control is not a finger, and a car does not show video.
Protected playback on every platform, and a gate that REFUSES when it cannot guarantee protection — rather than letting it through in silence. Tokens live in the hardware key store, not in a preferences file.
Sign-in by one-time link, pairing a television from a phone, device handover, revocation. Tokens are opaque and verified server-side: what travels says nothing, and what decides is never the client.
Many applications assume a stable connection. These do not: they degrade in stages — direct link, relay, then offline — and say so instead of spinning in place. The same engine decides on mobile and on the web.
TBL-IT is not only a service company: the house designs, publishes and sells its own software. That is what puts the theory to the test — a product you run yourself, whose outages and complaints land on your desk, teaches something a project you deliver and leave never will.
Technical lead of a team: settling architecture, framing with the business, splitting work, estimating, reviewing. And bringing others up — a decision only its author understands does not survive their departure.
Working alongside existing teams, and inheriting code whose author has left. The work starts by understanding WHY it is the way it is — an oddity usually hides a real case — and rarely by rewriting it.
Store releases, internal distribution, and above all what comes after: a server fleet that updates ENTIRELY or not at all, migrations that add before they remove, and checks that stop a release the moment the contract no longer holds.
The level is stated as it is. "Every day" means in production, on assignment; "in our own products" means we write it daily, but in the company’s own software; "comfortable" means we deliver without help; "we can take it over" means we maintain what exists without claiming we would design it from scratch.
A command that returns zero does not say a feature works: it says it finished. What counts is checking what actually answers.
A silent fallback — a default value standing in for an error, a screen showing something other than what was asked for — costs more than a clean refusal, because nobody reports it.
What explains a decision is worth as much as the decision. Six months later, it is what lets someone fix it without breaking it.
These lines are reproduced unchanged from the Belgian Crossroads Bank for Enterprises. They match the public register, digit for digit.
