Een gebruiker ziet uiteindelijk vooral schermen.
Een formulier. Een planning. Een dashboard. Een zoekveld. Misschien een knop die precies doet wat nodig is.
Als die interface prettig werkt, voelt de software eenvoudig.
Maar achter een eenvoudig scherm kan behoorlijk veel techniek zitten.
Data komt uit verschillende bronnen. Gebruikers hebben verschillende rechten. Externe systemen reageren soms niet. Achtergrondprocessen verwerken werk buiten het zicht van de gebruiker. Deployments moeten zonder verrassingen verlopen. En als er om drie uur 's nachts iets misgaat, wil je kunnen terugvinden wat er is gebeurd.
Daarom kijken we bij SolidForm liever naar een applicatie als systeem dan als verzameling schermen.
De interface is het topje
Een planning voor medewerkers lijkt aan de voorkant misschien op een kalender.
Maar voordat een naam op die kalender kan verschijnen, moet het systeem bijvoorbeeld weten:
- wie beschikbaar is;
- welke kwalificaties nodig zijn;
- of iemand al op een ander project staat;
- welke gegevens uit een extern systeem komen;
- wie de planning mag wijzigen;
- en welke wijziging later nog terug te vinden moet zijn.
Die onderliggende regels bepalen uiteindelijk of een mooi scherm ook betrouwbaar is.
Dat zien we bij vrijwel ieder type project.
Data moet eerst betrouwbaar zijn
Bij datagedreven software zit veel werk op plekken die de eindgebruiker nooit ziet.
Elvera verwerkt bijvoorbeeld gegevens uit sensoren, meters en andere bronnen. Voordat daar een bruikbaar dashboard of een melding uit kan komen, moeten gegevens worden ontvangen, gevalideerd, vertaald en op een consistente manier beschikbaar gemaakt.
Bij ImpactBuying zit de waarde juist in het samenbrengen van complexe keten- en impactdata zodat organisaties er daadwerkelijk op kunnen sturen.
In beide gevallen geldt: als de datalaag niet klopt, kan de mooiste visualisatie dat niet repareren.
Integraties zijn nooit alleen een stekker
Veel maatwerksystemen staan niet op zichzelf.
Ze praten met boekhoudpakketten, CRM-systemen, Microsoft 365, sensoren, API's van leveranciers of systemen die al jaren binnen een organisatie bestaan.
Op papier klinkt een integratie vaak eenvoudig: systeem A stuurt gegevens naar systeem B.
In de praktijk ontstaan de interessante vragen pas daarna.
Wat gebeurt er als B tijdelijk niet bereikbaar is? Mag A ondertussen doorgaan? Hoe voorkom je dubbele verwerking? Welke versie van een record is leidend? Hoe zie je achteraf waarom iets niet is aangekomen?
Dat zijn geen randzaken. Ze bepalen of medewerkers op het systeem kunnen vertrouwen.
Beheer begint voordat iets live staat
Monitoring en logging worden soms gezien als iets voor later.
Wij proberen daar eerder over na te denken.
Als een achtergrondtaak faalt, willen we weten welke invoer erbij hoorde. Als een externe koppeling trager wordt, willen we dat kunnen zien voordat gebruikers alleen maar melden dat "de site soms langzaam is". Als een deployment een probleem veroorzaakt, moet duidelijk zijn welke versie actief is en wat er veranderd is.
Een systeem dat goed te beheren is, levert op de lange termijn veel minder verborgen werk op.
Full-stack betekent voor ons vooral: verbanden zien
Ons team werkt daarom bewust over meerdere technische lagen heen.
Niet iedereen hoeft overal even diep in te zitten. Maar we willen wel dat een ontwikkelaar verder kan kijken dan het component waar hij toevallig aan werkt.
Een performanceprobleem in de browser kan uit de database komen.
Een fout in een rapportage kan zijn ontstaan in een importproces van twee dagen eerder.
Een AI-assistent die een vreemd antwoord geeft kan niet alleen een promptprobleem hebben, maar ook verkeerde bronselectie, rechten of verouderde kennis.
Hoe beter je die verbanden ziet, hoe sneller je de echte oorzaak vindt.
Eenvoud aan de voorkant vraagt discipline aan de achterkant
Goede maatwerksoftware voelt voor een gebruiker vaak helemaal niet ingewikkeld.
Dat is juist het doel.
De complexiteit verdwijnt alleen niet. Ze wordt op een plek opgelost waar de gebruiker er zo min mogelijk last van heeft.
Dat is voor ons een groot deel van softwareontwikkeling: niet zoveel mogelijk techniek zichtbaar maken, maar genoeg technische zorg in het systeem stoppen om het dagelijks werk rustig en voorspelbaar te maken.