De meeste bedrijven hebben geen nieuw softwarepakket nodig, maar één dat doet wat zij doen. Je werkt met drie systemen die niets van elkaar weten, dus typt iemand elke dag dezelfde gegevens over. Of er is een proces dat in geen enkel standaardpakket past en daarom in een Excel-bestand beland is, met alle versies en vergissingen van dien. Voor precies die twee situaties schrijven wij software. En voor gebruiksgemakoplossingen, zoals een screensaver die dashboards weergeeft als collega's wegstappen van hun scherm.
Eerst kijken of je het gewoon kan kopen
Elk gesprek begint bij dezelfde vraag: bestaat dit al? Een pakket dat honderden bedrijven vóór jou gebruikt hebben, is doorgaans goedkoper, sneller in huis en beter uitgetest dan wat wij vanaf nul schrijven. Vinden we zoiets, dan zeggen we dat — ook wanneer we onszelf daarmee een opdracht ontzeggen.
Maatwerk wordt pas interessant wanneer het standaardantwoord niet past: je proces wijkt wezenlijk af van wat de markt aanbiedt, je betaalt per gebruiker voor een pakket waar je maar één functie uit nodig hebt, of de software bestaat wél maar praat met niets anders in je bedrijf. Dan is een eigen stuk software geen luxe, maar de kortste weg.
Waarvoor klanten ons bellen
Opdrachten komen zelden binnen als "bouw een applicatie". Ze beginnen met een ergernis die al maanden duurt. In de praktijk komt dat meestal neer op zes soorten werk:
- Koppelingen tussen systemen die vandaag naast elkaar leven — je CRM, je facturatie, je webshop, je kassa;
- Portalen waar klanten of medewerkers zelf iets opzoeken, aanvragen of opvolgen, zonder dat er iemand voor moet bellen;
- Rekenmodules op je website: een calculator die een bezoeker in enkele stappen een prijsindicatie geeft, in plaats van een offerte die telkens een half uur werk kost;
- Automatisering van werk dat elke week terugkeert — bestanden verwerken, gegevens overzetten, een rapport samenstellen;
- Rapportering op je eigen data, zodat je cijfers ziet die kloppen met jouw manier van tellen;
- Apps en hulpmiddelen voor wie op de vloer staat — een Android-app op een tablet, of een klein Windows-programma dat op de achtergrond zijn werk doet.
Herken je jouw vraag hier niet in, dan is dat op zich al informatie: we nemen alleen werk aan dat we ook over twee jaar nog kunnen dragen.
Eerst het proces, dan pas code
We beginnen niet in een editor maar aan tafel, met de mensen die het werk vandaag doén. Wie doet wat, in welke volgorde, waar loopt het vast, en wat gebeurt er in de uitzonderingen — want daar zit doorgaans de helft van de complexiteit. Dat gesprek levert een schema op dat jij zelf kan nalezen en corrigeren, vóór er één regel code bestaat.
Soms eindigt het daar. Meer dan eens blijkt de oplossing een instelling in software die je al hebt, een koppeling die allang bestaat, of een stap die gewoon geschrapt kan worden. Dat is een kleinere factuur voor ons en een betere uitkomst voor jou. Het alternatief — code schrijven rond een proces dat zelf niet klopt — betaal je jarenlang terug.
Koppelingen: systemen die met elkaar praten
Het grootste deel van ons werk gaat niet over nieuwe software, maar over software die elkaar niet vindt. Een bestelling die online binnenkomt en met de hand in de facturatie belandt. Een klantenfiche die in twee pakketten staat en in geen van beide klopt. Via API's laten we die systemen gegevens uitwisselen — in één richting of in beide — met logging, zodat je achteraf ziet wat er gepasseerd is en waar het misliep.
Voor de klanten van ons kassasysteem schreven we de koppeling met de 3CX-telefooncentrale zelf, omdat ze niet bestond. Daar hoort meteen de eerlijke voetnoot bij: een koppeling valt of staat met wat de andere partij toelaat. Heeft het pakket waarmee je wil koppelen een bruikbare API, dan bouwen we erop; is die er niet of staat ze dicht, dan hoor je dat vóór je iets bestelt en niet halverwege. Over software van derden doen we geen beloftes die wij niet kunnen waarmaken.
Portalen en modules op je site
Een portaal is niets anders dan dit: informatie die mensen vandaag bij jou komen halen, laat je hen zelf opzoeken. Klanten die hun dossier, bestellingen of documenten zien. Medewerkers die een aanvraag indienen zonder mailketting van zeven berichten. Elk portaal krijgt eigen accounts en rechten, zodat iedereen enkel ziet wat voor hem bedoeld is.
Hoort de functie op je publieke site thuis, dan bouwen we ze zo dat ze in je bestaande website past in plaats van als een vreemd eiland aan te voelen. De offertecalculator op centerzuid.be bijvoorbeeld: die laat een bezoeker in een paar stappen zelf een prijsindicatie maken en stuurt het resultaat naar jou én naar de aanvrager. Voor dat soort interactieve schermen gebruiken we Vue; de logica en de gegevens blijven aan de serverkant, waar niemand ze kan bijsturen.
Onze stack, en waar ze ophoudt
We schrijven in PHP, met Laravel als framework, Vue voor interactieve schermen en REST API's om systemen aan elkaar te knopen. Moet er iets lokaal op een Windows-toestel draaien, dan schrijven we dat in C#. En wanneer een AI-assistent veilig bij je eigen gegevens moet, ontsluiten we die via een MCP-server, in plaats van er kopieën van te laten rondgaan. Het blijft een bewuste beperking: een klein team dat zijn stack door en door kent, levert code op die elke collega kan overnemen — ook wanneer wie ze schreef met verlof is of ooit vertrekt.
Apps horen daar ook bij. Android-apps bouwen we, en we doen dat ook effectief: voor Burney's schreven we er zelf een, en je vindt dat project bij onze realisaties. Al stellen we liever eerst de andere vraag: kan het ook als webapplicatie? Die draait in elke browser en op elk toestel, je onderhoudt er één versie van in plaats van twee, en dat scheelt je jaren onderhoudskosten. Kan het niet als web-app, dan bouwen we de app.
Daar hoort een keerzijde bij. Wij zijn geen softwarehuis dat elk denkbaar systeem bouwt. Vraag je een native app voor de Apple App Store, aansturing van machines op een werkvloer of een rekenmodel waar een specialistische achtergrond bij hoort, dan is ons antwoord nee — of we verwijzen je door naar iemand uit ons netwerk die dat wél elke dag doet.
Wat we zelf gebouwd hebben, en wat niet
Dezelfde mensen bouwen ook de software waar we zelf op draaien — onze interne tooling is home-made, en dat is de eerlijkste test die bestaat: wij dragen zelf de gevolgen van een slechte keuze. Op onze teller staan verder een vouchermodule voor WordPress-webshops, een verjaardagscadeau dat automatisch naar je klanten vertrekt, en PDSS Send om sms-berichten te versturen. Geen indrukwekkende systemen — wel software die jaren na de eerste versie nog draait en nog onderhouden wordt.
Waar we het onderscheid wel maken: PDSS Screens is niet van ons. Dat is een partnerproduct waar we samen met die partner aan meebouwden, van de editor waarin je je content samenstelt tot het beheer van schermen over meerdere filialen heen. Het blijft hun product; wat wij eraan toevoegen is dat we het door en door kennen, het bij jou opzetten en je aanspreekpunt blijven. Dat verschil benoemen we liever dan het weg te moffelen.
Jouw data blijft van jou
Over eigendom zijn we liever meteen duidelijk. De applicatie zelf blijft ons werk: wij schrijven ze, wij onderhouden ze en wij houden ze veilig. Wat er in zit, is van jou. Je klantenfiches, je bestellingen, je dossiers en je metingen zijn jouw gegevens en blijven dat ook — tot en met de dag dat je met een andere partij verder wil. Dan krijg je ze mee in een formaat waar je iets aan hebt.
Wat je van bij de start meekrijgt, is de uitleg: in gewone taal wat het systeem doet, welke gegevens waar staan en waarom bepaalde keuzes gemaakt zijn. Dat is geen formaliteit. Software die niemand meer kan uitleggen, wordt vanzelf software die niemand meer durft aan te raken — en dat kost je op termijn meer dan de bouw zelf.
Waar het draait, en wie het onderhoudt
Bij zo goed als elke opdracht hoort een managementpaneel: het scherm waarin jij je eigen toepassing beheert — gebruikers, prijzen, teksten, instellingen. Dat paneel hosten wij, op hosting bij onze partners op Belgische infrastructuur, met certificaten, back-ups en monitoring. Jij hoeft daar geen server voor open te houden en geen updates voor op te volgen.
Soms vraagt de toepassing iets anders. Hangt ze rechtstreeks aan apparatuur ter plaatse, verplaatst ze grote hoeveelheden data of moet ze ook blijven werken wanneer de internetlijn eruit ligt, dan zetten we ze on-prem — in het gebouw zelf. Voor een grote voetbalclub draait op die manier een interne streamserver in het stadion, die de match live op de schermen in het gebouw zet: die hoort daar, niet in een datacenter. Wat waar draait spreken we vooraf af, samen met wie wat opvolgt.
Daarna begint het onderhoud, en dat doet hetzelfde team dat de code geschreven heeft. PHP, Laravel en de gebruikte bibliotheken krijgen updates en lopen ooit uit ondersteuning; wie dat laat liggen, staat na een paar jaar voor een herbouw in plaats van een update. Wij volgen die versies op, testen vóór we iets uitrollen, en trekken aan de bel wanneer er een beslissing nodig is. Wil je er AI bij — een samenvatting, een classificatie, zoeken in je eigen documenten — dan bekijken we nuchter wat vandaag betrouwbaar werkt, in lijn met onze dienst AI-implementatie.
Hoe we starten
Met een gesprek over je proces, niet over technologie. Daaruit volgt een voorstel met een duidelijke scope: wat er gebouwd wordt, wat er bewust buiten valt, en in welke volgorde we het aanpakken. Blijkt onderweg dat iets anders moet, dan bespreken we dat vóór we het bouwen — niet achteraf, op de factuur.
Benieuwd wat we in de praktijk al opleverden? Neem een kijkje bij onze realisaties.