softify.pro
Laden …
Diensten Over ons COCO – onze AI-server Portfolio Insiders Case Studies Wetenswaardigheden Contact Aanmelden

NEXT-GEN SOFTWARE AESTHETIC

Pure fluidity meets ultimate performance.

De nieuwe visuele identiteit voor moderne digitale workflows.

softify.pro — De nieuwe visuele identiteit voor moderne digitale workflows.

Scroll om te verkennen ↓

Software gebouwd zoals moderne bedrijven écht werken

softify.pro is een softwarestudio gebouwd rond één idee: technologie zou net zo vloeiend moeten bewegen als de bedrijven die zij ondersteunt. Wij werken op het snijvlak van moderne webontwikkeling, procesautomatisering en toegepaste kunstmatige intelligentie — drie disciplines die zelden onder één dak samenkomen, maar dat steeds vaker wel moeten. Onze klanten variëren van kleine werkplaatsen die hun eerste digitale facturatie invoeren tot gevestigde middelgrote fabrikanten die spreadsheets vervangen door echte logistieke software. Wat hen verbindt, is niet de omvang, maar de ambitie: zij willen systemen die snel, betrouwbaar en écht prettig in gebruik zijn, niet alleen functioneel. Elk project begint bij ons met dezelfde drie vragen: wat moet dit bedrijf daadwerkelijk sneller laten verlopen, wat werkt al goed en verdient respect in plaats van vervanging, en welk deel van het werkproces kan, eenmaal correct gebouwd, zichzelf voortaan afhandelen. De antwoorden bepalen alles wat volgt, van de gekozen technologie tot het uitrolplan.

Diensten

De nieuwe visuele identiteit voor moderne digitale workflows.

01 — LOGISTICS

Logistiek automatiseren — gebouwd voor kleine en middelgrote bedrijven in de DACH-regio

Een groot deel van ons werk is gewijd aan logistieke en operationele software voor kleine en middelgrote bedrijven in Duitsland, Oostenrijk en Zwitserland. Deze bedrijven zitten vaak vast tussen twee onaantrekkelijke opties: dure enterprise logistieke pakketten ontworpen voor concerns die tien keer zo groot zijn, of een lappendeken van spreadsheets, papieren formulieren en telefoontjes die stilletjes beperkt hoe snel ze kunnen groeien.

Wij bouwen de middenweg — maatwerkautomatisering die past bij hoe een specifiek magazijn, werkplaats of distributieteam daadwerkelijk werkt. Dat kan betekenen: inkomende goederen en voorraadmutaties digitaliseren, automatisch pakbonnen en verzendlabels genereren, orderontvangst koppelen aan routeplanning, of simpelweg een kwetsbaar Excel-bestand dat slechts één persoon begrijpt vervangen door een gedeeld systeem waarop het hele team kan vertrouwen. Omdat wij rechtstreeks samenwerken met eigenaren en operationeel managers in de DACH-regio, worden vereisten opgehaald in de taal waarin het bedrijf daadwerkelijk werkt, en wordt de uitrol gepland rond echte ploegendiensten en echte magazijnvloeren, niet rond een abstract implementatieschema.

02 — WEB

Moderne webontwikkeling, gebouwd op actuele technologie

Wij ontwerpen en bouwen webapplicaties en websites met actuele, actief onderhouden technologie in plaats van verouderde frameworks die uit gewoonte in leven worden gehouden. Dat betekent nette PHP 8.4 aan de serverkant waar een klassieke server-gerenderde applicatie de juiste keuze is, moderne JavaScript waar interactiviteit telt, en MySQL 8 voor data die jarenlang consistent en doorzoekbaar moet blijven, niet alleen de eerste zes maanden na lancering. Elk project wordt vanaf de allereerste schets tegelijk voor desktop en mobiel gepland, niet achteraf aangepast: laadtijden, layout-breakpoints en touch-interacties horen bij de specificatie, niet bij een latere toevoeging.

Naast de zichtbare interface vinden wij belangrijk hoe een website er van binnen uitziet: leesbare code, een databaseschema dat niet bij de volgende functie-aanvraag opnieuw opgebouwd hoeft te worden, en implementatiestappen die een tweede ontwikkelaar kan volgen zonder ons te hoeven bellen. Een website die vandaag goed presteert en over drie jaar nog steeds netjes uitbreidbaar is, is voor ons de werkelijke definitie van 'modern'.

03 — AI / COCO

COCO — onze eigen AI-server voor geautomatiseerd softwaretesten

Voor enterprise-klanten beheren en onderhouden wij onze eigen dedicated AI-server, genaamd COCO. In tegenstelling tot een algemene chatbot die achteraf aan een workflow wordt gekoppeld, is COCO specifiek gebouwd en zelf gehost voor het geautomatiseerd testen van websoftware en platformonafhankelijke desktoptoepassingen — van login- en authenticatiestromen tot volledige meerstaps bedrijfsprocessen.

COCO plant een testscenario, voert dit uit tegen de echte applicatie, legt voor-en-na screenshots en uitvoeringsopnames vast als bewijs, en levert een in gewone taal gestelde beoordeling van wat is geslaagd, wat is mislukt en waarom — inclusief randgevallen zoals herhaalde mislukte inlogpogingen, accountvergrendelingen en herstelstromen die handmatig omslachtig en foutgevoelig zijn om te testen. Omdat de server lokaal onder ons beheer draait, houden enterprise-klanten volledige controle over waar testdata en screenshots worden opgeslagen, zonder dat interne applicatieverkeer standaard naar een externe clouddienst wordt gestuurd.

COCO — onze eigen AI-server voor geautomatiseerd softwaretesten

Voor enterprise-klanten beheren en onderhouden wij onze eigen dedicated AI-server, genaamd COCO. In tegenstelling tot een algemene chatbot die achteraf aan een workflow wordt gekoppeld, is COCO specifiek gebouwd en zelf gehost voor het geautomatiseerd testen van websoftware en platformonafhankelijke desktoptoepassingen — van login- en authenticatiestromen tot volledige meerstaps bedrijfsprocessen.

COCO plant een testscenario, voert dit uit tegen de echte applicatie, legt voor-en-na screenshots en uitvoeringsopnames vast als bewijs, en levert een in gewone taal gestelde beoordeling van wat is geslaagd, wat is mislukt en waarom — inclusief randgevallen zoals herhaalde mislukte inlogpogingen, accountvergrendelingen en herstelstromen die handmatig omslachtig en foutgevoelig zijn om te testen. Omdat de server lokaal onder ons beheer draait, houden enterprise-klanten volledige controle over waar testdata en screenshots worden opgeslagen, zonder dat interne applicatieverkeer standaard naar een externe clouddienst wordt gestuurd.

Wij richten COCO voor elke enterprise-klant afzonderlijk in, configureren en onderhouden de server — wij bepalen de testplannen die relevant zijn voor hun specifieke applicatie, stemmen betrouwbaarheidsdrempels af, en beslissen per geval wanneer een resultaat voor menselijke beoordeling moet worden geëscaleerd. Het doel is niet om een QA-team te vervangen, maar om het een onvermoeibare collega te geven die de repetitieve regressietests voor elke release uitvoert, nog voordat een mens hoeft in te grijpen.

COCO automated login test report
COCO — automated login & account-lockout test report
COCO AI analysis panel
COCO — plain-language AI analysis of a completed test run

Waarom softify.pro

Wij blijven bewust klein genoeg zodat elk project wordt behandeld door mensen die bij het eerste planningsgesprek aanwezig waren, niet doorgeschoven naar een wachtrij. Dat betekent kortere feedbackloops, minder misverstanden en een team dat ook na zes maanden nog weet waarom een bepaalde beslissing is genomen. Wij verkiezen saaie, bewezen betrouwbaarheid boven het najagen van trends: een technologiestack wordt gekozen omdat die bij het probleem past en over vijf jaar door iemand anders dan wijzelf onderhouden kan worden, niet omdat hij trendy was in de sprint waarin hij werd gekozen. Als een spreadsheet het werk écht nog beter doet dan maatwerksoftware zou doen, vertellen wij u dat ook eerlijk — ons doel is een workflow die daadwerkelijk sneller verloopt, niet simpelweg een hogere softwarerekening.

Geselecteerd werk

Een kleine selectie van werk dat wij publiekelijk mogen tonen — verdere case studies en enterprise-projecten zijn op aanvraag beschikbaar onder NDA.

Auto Detailing Đeki – Van website naar digitaal serviceplatform autodetailing-deki.pro

Auto Detailing Đeki – Van website naar digitaal serviceplatform

Meertalig platform voor auto-detailing – van prijsberekening via reservering tot transparante opvolging van bestellingen, aangestuurd vanuit één centrale backoffice.

Koralpenhaus

Koralpenhaus

Regionale presentatie- en boekingswebsite in het Alpengebied, gebouwd met focus op een heldere structuur, snelle laadtijden en eenvoudig contentbeheer.

Dexosano

Dexosano

A modern PHP-based web platform, engineered with the same performance-first approach softify.pro applies to every client project.

softify.pro - Insiders

Eén magazijn. Eén waarheid.

Eén magazijn. Eén waarheid.

Er bestaat een eenvoudige manier om magazijnsoftware overtuigend te doen ogen.
Een dashboard openen.
Een paar groene cijfers tonen.
Een grafiek toevoegen.
Wat voorraad op een magazijnplan zetten.
Afsluiten met een rapport.
Alles oogt in orde.
En toch kan alles fout zijn.
Want een magazijn maalt er niet om hoe mooi het dashboard eruitziet.
Het gaat erom of elk onderdeel van het systeem het erover eens is wat er werkelijk gebeurd is.
Dat werd het interessante deel van het jongste softify.pro Flow-experiment.
Geen extra scherm.
Geen extra KPI.
Geen extra rapport.
Iets veel minder zichtbaars.
Consistentie.
Het begon met een magazijn.
De huidige softify.pro Flow-demo werkt met meerdere synthetische magazijnomgevingen.
Verschillende magazijn-ID's.
Verschillende capaciteiten.
Verschillende zonestructuren.
Geen productievoorraad.
Geen klantgegevens.
Geen echte operationele informatie.
Maar de proceslogica gedraagt zich alsof dat allemaal telde.
Want in de echte logistiek is dat zo.
Van zodra een magazijn geselecteerd is, wordt die context deel van alles wat volgt.
Flows.
SSCC's.
Bewegingen.
Operators.
Analytics.
Rapporten.
Dat klinkt vanzelfsprekend.
Het wordt aanzienlijk minder vanzelfsprekend van zodra hetzelfde proces in meerdere delen van de applicatie begint op te duiken.
Toen openden we een andere weergave.
Operational Analytics.
Plots zag het magazijn er helemaal anders uit.
Geen opslagplaatsen.
Geen bewegingspijlen.
In de plaats:

  • afgeronde Flows,
  • actieve orders,
  • magazijnbezetting,
  • uitzonderingen,
  • inbound,
  • outbound,
  • verwerkingstijd.

De visuele voorstelling was veranderd.
Het magazijn niet.
Dat onderscheid werd belangrijk.
Want onder de KPI's zaten nog steeds individuele records.
Flow-ID's.
SSCC's.
Zones.
Statussen.
Operators.
Verwerkingstijden.
Andere weergave.
Dezelfde operationele realiteit.
Tot zover geen probleem.

Operational Analytics — geaggregeerde magazijnstatus, met de onderliggende Flow-records nog steeds zichtbaar.

Flow.

88% is alleen nuttig als het systeem het kan verklaren.
Stel dat het dashboard zegt:
Magazijnbezetting: 88%.
Nuttig.
Maar onvolledig.
Sommige plaatsen zijn bezet.
Sommige zijn gereserveerd.
Sommige blijven vrij.
Die statussen zijn niet inwisselbaar.
Het cijfer wordt pas betrouwbaar als het systeem nog kan uitleggen waar het vandaan komt.
Vijf afgeronde Flows?
Toon ze.
Twee actieve orders?
Toon ze.
Eén uitzondering?
Welke?
88% bezetting?
Wat is bezet?
Wat is gereserveerd?
Wat blijft vrij?
Een dashboard hoort de realiteit samen te vatten.
Het hoort ze niet te vervangen.
Toen veranderden we de taal.
Nederlands.
Het magazijn bleef hetzelfde.
De Flow-ID's bleven dezelfde.
De SSCC's bleven dezelfde.
De operators bleven aan hun records gekoppeld.
Enkel de taal veranderde.
Later verscheen dezelfde operationele status in het Kroatisch.
Vervolgens in het Frans.
Hier wordt meertalige software veel interessanter dan vertaalde knoppen.
Een slechte vertaling valt snel op.
Een statuswijziging veroorzaakt door een taalwissel is veel gevaarlijker.
Stel je voor: overschakelen van Duits naar Frans en stilletjes de geselecteerde Flow kwijtraken.
Of een filter heropbouwen tegen het verkeerde magazijn.
Of de juiste SSCC tonen binnen de verkeerde procescontext.
De interface kan er nog steeds perfect uitzien.
Het systeem zou dat niet zijn.
Flow volgt daarom een eenvoudige regel:
Taal mag de woorden veranderen. Ze mag de waarheid niet veranderen.
Vervolgens kreeg de Flow een geschiedenis.
Browse & Drill-down doet geen bijzondere moeite om indrukwekkend te lijken.
Misschien is dat net waarom het nuttig is.
Selecteer een Flow.
De context verschijnt.
Magazijn.
Zone.
Status.
Operator.
SSCC.
En dan de documentketen.
ASN.
Goederenontvangst.
Magazijnbeweging.
Pickorder.
Picken.
Verzending.
FLOW.
Zeven stappen.
Het proces is niet langer enkel een huidige status.
Het heeft een verleden.
En dat verandert de vraag.
In plaats van:
Wat gebeurt er?
kunnen we vragen:
Hoe zijn we hier geraakt?
Dat is een veel betere vraag wanneer er uiteindelijk iets misloopt.

Eén Flow, één SSCC, één documentketen — van ASN tot afronding.

Flow.


SSCC wordt de rode draad.
Op het eerste zicht ziet een SSCC eruit zoals het is.
Een identificatiecode.
Een lang nummer in een tabel.
Maar doorheen Flow wordt het iets nuttigers.
Een rode draad doorheen het proces.
Volg hem en andere zaken beginnen zich te verbinden.
Een magazijn.
Een Flow.
Een zone.
Een status.
Een operator.
Een documentketen.
Uiteindelijk een rapport.
Hetzelfde fysieke logistieke object is nu zichtbaar vanuit meerdere delen van de applicatie.
Nuttig.
Ook gevaarlijk.
Want elke bijkomende weergave creëert weer een kans voor het systeem om een ander verhaal te vertellen.
En daar wordt het interessant.
Stel dat Analytics zegt dat de Flow actief is.
Drill-down zegt dat de SSCC bij die Flow hoort.
De documentketen zegt dat de operatie verder gevorderd is.
Het rapport zegt iets anders.
Wat klopt er?
Dit is geen Flow-specifiek probleem.
Het is een van de oudste problemen in bedrijfssoftware.
Verschillende delen van hetzelfde systeem ontwikkelen geleidelijk hun eigen versie van de werkelijkheid.
Het ene scherm leest de transactionele status.
Een ander leest een aggregaat.
Nog een ander steunt op gecachte gegevens.
Een rapport berekent iets net iets anders.
Een uitzondering wordt operationeel opgelost maar verdwijnt uit de rapportering.
Elk onderdeel werkt.
Het volledige systeem liegt.
Meestal beleefd.
Dus openden we het Report Center.
Dagelijks operationeel overzicht.
Voorraad en bezetting.
Flow-prestaties.
SSCC-traceerbaarheid.
Uitzonderingen en SLA.
Hetzelfde operationele verhaal verscheen opnieuw.
Afgeronde Flows.
Actieve orders.
Magazijnbezetting.
Uitzonderingen.
Inbound.
Outbound.
Verwerkingstijd.
Maar deze keer was de vraag niet of het rapport correct oogde.
De vraag was:
Kan het zichzelf verantwoorden?
Een goed rapport geeft je een cijfer.
Een beter systeem kan uitleggen waar dat cijfer vandaan komt.

Rapportering vanuit dezelfde operationele status — geen tweede versie van de werkelijkheid.

Flow.
Flow.
Flow.
Flow.


De uitzondering was er nog steeds.
Een van de stillere details bleek een van de belangrijkere te zijn.
De demogegevens bevatten een uitzondering.
Ze verschijnt in Analytics.
Ze verschijnt in Drill-down.
Ze verschijnt in de SSCC-traceerbaarheid.
Ze verschijnt in het Report Center.
En ze blijft zichtbaar in Exceptions & SLA.
Precies dat hoort te gebeuren.
Operationeel herstellen van een uitzondering betekent niet dat de uitzondering uit de geschiedenis moet verdwijnen.
"Het proces ging door" en "er is niets gebeurd" zijn niet dezelfde bewering.
In de logistiek maakt dat verschil uit.
Op dit punt hadden we een testprobleem.
Geen softwareprobleem.
Een testprobleem.
We hadden nu hetzelfde magazijn voorgesteld als:

  • analytics,
  • afzonderlijke Flows,
  • SSCC-geschiedenissen,
  • documentketens,
  • rapporten,
  • en uitzonderingsweergaven.

Elk kon apart getest worden.
Openen.
Klikken.
Filteren.
Verifiëren.
Slagen.
Volgende.

Dat zou eenvoudig zijn.
Het zou ook het interessante deel missen.
Want zes groene vinkjes bewijzen niet dat zes weergaven met elkaar overeenstemmen.
Daar komt COCO.
Opnieuw.
COCO had al eerder met Flow te maken gehad.
Authenticatie.
Gebruikers.
Rollen.
Databaseomgevingen.
Talen.
Desktop-uitvoering.
Toen kwam de logistiek.
Magazijnen.
Voorraad.
Picken.
Bewegingen.
Uitzonderingen.
Documenten.
Ubuntu.
Red Hat Enterprise Linux.
Deze keer gaven we COCO iets net iets anders.
Geen scherm om te verifiëren.
Een verhaal om te volgen.
Neem dit magazijn.
Neem deze Flow.
Neem deze SSCC.
Open Analytics.
Open Drill-down.
Verander de taal.
Kijk opnieuw.
Open het rapport.
Vind dezelfde Flow.
Vind dezelfde SSCC.
Vind de uitzondering.
Vergelijk.
Vergelijk dan opnieuw.

COCO volgt dezelfde operationele context doorheen softify.pro Flow — analytics, traceerbaarheid, taalwissels en rapportering.

Dat verandert de aard van de test.

De vraag is niet langer:

  • Werkt elke module?

Ze wordt:

  • Geloven alle modules dat hetzelfde gebeurd is?

Een veel betere vraag.
Veel minder comfortabel.
Een magazijnsysteem hoort één geheugen te hebben.
Operators zien misschien posities.
Magazijnverantwoordelijken zien misschien KPI's.
Support gebruikt misschien drill-down.
Auditors gebruiken misschien rapporten.
COCO ziet ze misschien allemaal.
Maar onder die perspectieven hoort er één geschiedenis te zijn.
Eén Flow hoort niet meerdere biografieën te krijgen, afhankelijk van welke module open staat.
Eén SSCC hoort niet meerdere verledens te hebben.
Eén uitzondering hoort niet enkel te bestaan waar het uitkomt.
Eén magazijn hoort geen ander magazijn te worden omdat de interfacetaal veranderde.
Daar draait het huidige Flow-experiment eigenlijk om.
Niet om dashboards.
Niet om rapporten.
Zelfs niet om afzonderlijke schermen.
Om één operationele waarheid, op verschillende manieren uitgedrukt.
Controle.
Het magazijn kennen.
De status kennen.
Weten wat er beweegt.
Weten welk proces het bezit.
Duidelijkheid.
KPI's terug omzetten in records.
Records omzetten in geschiedenis.
Uitzonderingen omzetten in bewijs.
Een SSCC omzetten in iets traceerbaars.
Flow.
Een magazijn wordt geselecteerd.
Analytics begint het te beschrijven.
Een Flow gaat vooruit.
De SSCC blijft eraan gekoppeld.
Een documentketen groeit.
Een uitzondering verschijnt.
Het proces gaat door.
Het rapport onthoudt het.
Dan verandert de taal.
Het magazijn is nog steeds hetzelfde.
De Flow is nog steeds dezelfde.
De geschiedenis is nog steeds dezelfde.
Dat was het verwachte deel.
Wat daarna gebeurde was interessanter.
COCO stopte met het apart testen van de weergaven.
Het begon ze te vergelijken.
Een tijdlang gebeurde er niets bijzonders.
Zelfde magazijn.
Zelfde Flow.
Zelfde SSCC.
Zelfde verhaal.
Opnieuw.
Opnieuw.
Opnieuw.
En toen stopte COCO.
Niet omdat de applicatie vastliep.
Dat was niet het geval.
Niet omdat een test faalde in de gebruikelijke zin.
Dat was niet het geval.
Het stopte omdat twee perfect redelijke antwoorden een derde vraag opleverden.

Wij weten wat de vraag is.
Flow weet waarom het bestaat.
COCO weet waar het vervolgens moet kijken.

De rest kan wachten.


Control. Clarity. Flow.

Gepubliceerd: 31.08.2026

Permalink →

COCO slaat weer toe

COCO slaat weer toe

We zouden waarschijnlijk moeten stoppen met COCO ideeën te geven.

Het vorige experiment zou genoeg moeten zijn geweest.

Een echte applicatie.

Echte navigatie.

Gebruikers.

Rollen.

Databases.

Talen.

Bewijs.

Een respectabele case study.

Een nette conclusie.

Toen liet iemand het zien: Logistics in Motion.

Dat was waarschijnlijk de vergissing.

Het begon met drie magazijnen

Niets bijzonder opwindends.

…

Een brief van COCO

Een brief van COCO

Aan de engineer die deze repository voor het eerst opent:

Welkom.

Misschien ben je hier omdat er iets misliep.

Een dienst reageerde niet meer.

Een deployment gedroeg zich onverwacht.

Een alert maakte je midden in de nacht wakker.

Of misschien ben je gewoon nieuwsgierig hoe dit platform werkt.

Wat je ook hierheen heeft gebracht,

weet dat dit project precies voor zulke momenten werd gebouwd.

Niet om moeilijke problemen weg te nemen.

Maar om moeilijke problemen begrijpelijk te maken.

Je vindt hier code.

Je vindt hier documentatie.

Je vindt hier specificaties.

Maar belangrijker nog,

…

Case Studies

softify.pro Flow — Getest door COCO

softify.pro Flow — Getest door COCO

21.08.2026

Control. Clarity. Flow.

Elk serieus softwareproduct ontwikkelt uiteindelijk een tweede product achter het product.

Klanten zien het misschien nooit. Bezoekers weten misschien nooit dat het bestaat. Maar beheerders, operators en ontwikkelaars zijn er elke dag van afhankelijk.

Voor softify.pro Flow is die applicatie Administration — de operationele console die verantwoordelijk is voor het beheren van gebruikers, rollen, toegangsniveaus, authenticatiestatussen, databaseomgevingen en andere configuratie die een Flow-installatie onder controle houdt.

Het aanmeldscherm draagt drie woorden:
Control. Clarity. Flow.

Ze zijn oorspronkelijk gekozen om de ervaring te beschrijven die we beheerders wilden geven bij het bedienen van het systeem.

Maar ze beschrijven ook verrassend goed hoe wij vinden dat software getest zou moeten worden.

Dat maakte softify.pro Flow — Administration een voor de hand liggende kandidaat voor een echte COCO-test.
Geen laboratoriumdemonstratie.
Geen verzameling losse knoppen die speciaal voor een AI-demo zijn voorbereid.
Een echte platformonafhankelijke desktopapplicatie met echte applicatielogica, meerdere vensters, meerdere database-backends, authenticatie, rechten, lokalisatie en genoeg status om ogenschijnlijk kleine regressies handmatig moeilijk te herkennen te maken.

Voor de hier getoonde publieke demonstratie werkte COCO uitsluitend met gegenereerde demogegevens. De applicatie was gelicentieerd aan het fictieve bedrijf Presentation GmbH, en er is geen productieklantinformatie, geen inloggegevens en geen persoonlijke gegevens gebruikt.

Het doel was eenvoudig:
laat COCO de applicatie benaderen zoals een tester dat zou doen, en bepaal of de volledige administratieve workflow zich nog gedraagt zoals de software beweert.

The Challenge

Op het eerste gezicht lijkt het testen van een beheerapplicatie eenvoudig.

Open het.
Log in.
Klik door verschillende vensters.
Controleer of alles er correct uitziet.

Die aanname verandert snel zodra de applicatie groeit.

softify.pro Flow — Administration is geen enkel statisch formulier. Het is een verzameling met elkaar verbonden operationele weergaven binnen één applicatieschil.

Onder andere kan een beheerder werken met:

  • gebruikersaccounts
  • rollen en toegangsniveaus
  • authenticatie-informatie
  • status van tweefactorauthenticatie
  • informatie over het besturingssysteem
  • netwerk- en IP-informatie
  • databaseconfiguratie
  • sorteer- en weergaveopties
  • live taalkeuze
  • applicatie- en licentie-informatie

De interface ondersteunt momenteel elf talen. De applicatie werkt ook met MySQL en PostgreSQL als database-backends. Afzonderlijk vormt geen van deze functies een ongebruikelijk testprobleem.

De moeilijkheid ontstaat door de combinaties ervan.
Een gebruikerstabel kan correct werken in het Engels maar een verouderde kolomnaam tonen in het Kroatisch.
Sorteren kan correct werken bij verbinding met MySQL maar zich anders gedragen na het overschakelen naar PostgreSQL.

Een taalwijziging kan de meeste interface-elementen bijwerken terwijl één statusbericht onvertaald blijft. De applicatie kan succesvol van database wisselen maar verouderde informatie van de vorige verbinding behouden. Een nieuwe release kan een functie introduceren terwijl de Over-dialoog nog de vorige beschrijft. Het programma hoeft niet vast te lopen om zo'n situatie een regressie te maken. Sterker nog, sommige van de vervelendste softwaredefecten zijn precies de gevallen waarin alles lijkt te werken.

De applicatie start.
Het venster opent.
De knop reageert.
Maar er klopt iets niet meer helemaal onder de oppervlakte.
Daarom is herhaaldelijk regressietesten belangrijk.

En het is precies het soort werk waar mensen steeds slechter in worden nadat ze dezelfde reeks tientallen keren hebben herhaald.

Why Manual Testing Becomes Expensive

Iets één keer testen is eenvoudig.
Het betrouwbaar testen na elke relevante release is anders.

Kijk alleen al naar drie dimensies: 11 interfacetalen × 2 database-backends × meerdere applicatieworkflows.

Het aantal combinaties groeit snel.
Voeg verschillende gebruikersrollen, authenticatiestatussen, sorteergedrag, configuratiewijzigingen en operationele omgevingen toe, en de testmatrix wordt te groot om als een incidentele handmatige checklist te behandelen.

Hier begint regressietesten vaak te eroderen.
Niet opzettelijk.
Een releasedeadline komt dichterbij.
Iemand herinnert zich dat de applicatie vorige week is getest.
Een ontwikkelaar controleert snel het belangrijkste scherm.

Duits werkt.
Engels werkt.
MySQL werkt.
De aanname wordt:
"De rest is waarschijnlijk in orde."

Meestal is dat zo.
Tot de release waarbij dat niet zo is.
COCO bestaat deels om die aanname uit het proces te halen.

What COCO Actually Did

COCO startte softify.pro Flow — Administration vanuit een koude applicatiestatus, zonder te vertrouwen op een vooraf voorbereid scherm of handmatig gepositioneerde workflow.

De eerste interactie was dezelfde als die aan een menselijke beheerder wordt getoond: het aanmeldvenster.

COCO identificeerde de authenticatie-interface met:

  • gebruikersnaam
  • wachtwoord
  • tweefactorauthenticatiecode

en de regel direct onder de softify.pro Flow-identiteit:
Control. Clarity. Flow.

Van daaruit werkte COCO zich door een gedefinieerde regressiesessie. Het ging er niet simpelweg om te bepalen of de applicatie kon worden geopend.

Het ging erom te verifiëren of de status van de applicatie intern consistent bleef terwijl COCO ermee interacteerde.

Authentication Is Only the Beginning

Login-tests zijn een van de meest voor de hand liggende kandidaten voor automatisering, maar een geslaagde authenticatie alleen zegt heel weinig over de rest van een beheerapplicatie.

Eenmaal binnen ging COCO naar de daadwerkelijke werkomgeving. Het inspecteerde de gebruikersbeheer-interface en verifieerde dat de verwachte informatie aanwezig was.

Dat omvatte gegevens zoals:

  • gebruikersnamen
  • gemaskeerde wachtwoorden
  • 2FA-indicatoren
  • toegewezen rollen
  • informatie over het besturingssysteem
  • IP-adressen

COCO interacteerde vervolgens met de tabel in plaats van deze alleen te observeren.
De gebruikerslijst werd gesorteerd op gebruikersnaam.
De resulterende volgorde werd geïnspecteerd.
Het belangrijke was niet of het klikken op de kolomkop een zichtbare verandering opleverde.

COCO verifieerde dat de resulterende tabelstatus overeenkwam met de gevraagde bewerking.

Dat onderscheid is belangrijk.
Een functionele test vraagt:
"Reageerde de knop?"

Een nuttige regressietest vraagt:
"Kwam de applicatie terecht in de juiste status?"

Testing the Database Boundary

softify.pro Flow ondersteunt meer dan één database-backend.

Dat maakt van databaseoverschakeling een bijzonder belangrijke regressiegrens.
COCO wijzigde de actieve backend van MySQL naar PostgreSQL.

Na de overschakeling inspecteerde het opnieuw de gebruikersinformatie.
De test zocht naar meer dan een geslaagde verbinding.
Er werd gecontroleerd of de applicatie de verwachte records bleef tonen en of de via de interface getoonde informatie consistent bleef.

COCO schakelde daarna weer terug.

Dit soort overgang wordt gemakkelijk onderschat.
De gebruikersinterface kan visueel identiek blijven terwijl de onderliggende opslaglaag volledig verandert.
Vanuit het perspectief van een beheerder zou die overgang bijna saai moeten aanvoelen.
Dezelfde gebruikers zouden nog steeds begrijpelijk moeten zijn.
Dezelfde rollen zouden nog steeds logisch moeten zijn.

Hetzelfde interfacegedrag zou nog steeds moeten gelden.

Die schijnbaar onbewogen continuïteit is precies wat bewezen moet worden.

Eleven Languages, One Application State

Lokalisatie is een ander gebied waar oppervlakkig testen bijzonder gevaarlijk is.

Het is relatief eenvoudig om te verifiëren dat een applicatie in een andere taal kan starten.
Het is veel waardevoller om te verifiëren wat er gebeurt wanneer de taal verandert terwijl de applicatie al draait en status vasthoudt.

COCO wisselde de interfacetaal live.

De sessie omvatte overgangen tussen talen zoals:
Duits → Engels → Kroatisch
terwijl de administratieweergave actief bleef.

COCO observeerde of interface-elementen op hun plaats correct veranderden:

  • tabelkoppen
  • bedieningselementen
  • knoppen
  • labels
  • statusberichten

Ook de onderliggende tabel en applicatiestatus moesten die overgang overleven.
Dit is belangrijk omdat meertalige software uit meer bestaat dan vertaalde tekststrings.
Taalwijzigingen kunnen blootleggen:

  • vergeten resources
  • verouderde labels
  • opmaakproblemen
  • onvertaalde statusberichten
  • coderingsproblemen
  • statusresets
  • problemen bij het opnieuw aanmaken van besturingselementen

Een venster dat er correct uitziet wanneer het direct in het Kroatisch wordt gestart, kan zich toch onjuist gedragen wanneer de gebruiker tijdens een actieve sessie van Duits naar Kroatisch overschakelt.

Dat is het verschil tussen het controleren van een screenshot en het testen van een workflow.

Restoring Application State

COCO herstelde vervolgens de standaard sorteerconfiguratie van de applicatie.

Ook hier eindigde de test niet met de klik zelf.

De resulterende volgorde en de bevestiging die via het statusgebied van de applicatie werd getoond, werden geëvalueerd. Dit soort verificatie lijkt misschien onbeduidend vergeleken met het testen van authenticatie of databasetoegang.

Dat is het niet.

Enterprise-applicaties verzamelen honderden van dit soort kleine statusovergangen.
Gebruikers vertrouwen erop zonder er bewust over na te denken.
De software voelt betrouwbaar aan juist omdat die interacties voorspelbaar blijven.
Regressietesten bestaat om die voorspelbaarheid te beschermen.

Testing the Information Around the Software

COCO opende ook de Over-dialoog van de applicatie.

Waarom een Over-venster testen?

Omdat softwaredocumentatie begint binnen de software zelf.
Het versienummer, de functiebeschrijving en de licentie-informatie die aan de operator worden getoond, zouden moeten overeenkomen met de applicatie die daadwerkelijk draait.

Een applicatie kan perfect functioneren terwijl deze nog steeds verouderde versie-informatie toont of mogelijkheden beschrijft die niet meer overeenkomen met de release.

Dat laat geen database vastlopen.
Het doet iets subtielers:
het vermindert vertrouwen.

Voor enterprise-software omvat operationele nauwkeurigheid ook deze ogenschijnlijk kleine details. COCO controleerde daarom ook deze.

Control.

Het eerste woord in de softify.pro Flow-slogan is ook het eerste principe van de testomgeving.

Control betekent weten wat er wordt getest, tegen welke status en met welke gegevens.

De publieke COCO-demonstratie gebruikt geen productiegegevens van klanten.

Het draait met bewust voorbereide demogegevens waarvan de verwachte status bekend is.

Dat maakt resultaten reproduceerbaar.

Het betekent ook dat verschillen tussen testruns onderzocht kunnen worden in plaats van weg te worden verklaard als willekeurige veranderingen in productiegegevens.

Belangrijker nog, COCO is ontworpen als een self-hosted AI-testsysteem.

Testbewijs, applicatiescreenshots en interne workflow-informatie kunnen binnen de infrastructuur blijven onder de eigen controle van de klant of operator, in plaats van standaard te worden verzonden naar een niet-gerelateerde externe clouddienst.

Voor interne bedrijfsapplicaties is dat niet louter een infrastructuurvoorkeur.
Het kan deel uitmaken van de testvereiste zelf.

Clarity.

Automatisering is niet bijzonder nuttig als de uiteindelijke uitvoer is: FAILED
gevolgd door honderden regels technische uitvoer die iemand handmatig moet reconstrueren voordat hij begrijpt wat er is gebeurd.

COCO is ontworpen om een begrijpelijk bewijsspoor te behouden.

Het rapport beschrijft:

  • wat er is getest
  • welke interactie plaatsvond
  • in welke volgorde dit gebeurde
  • wat COCO observeerde
  • welke status verwacht werd
  • waar het gedrag afweek toen iets mislukte

Screenshots en uitvoeringsbewijs kunnen die reeks vergezellen.
Het doel is niet om technische details te verbergen.

Het is om het resultaat begrijpelijk te maken voordat iemand een debugger moet openen.

Een engineer zou moeten kunnen antwoorden op:
Wat is er gebeurd? voordat hij vraagt:
Waar in de code is het gebeurd?

Dat onderscheid verkort het onderzoek drastisch wanneer een regressie optreedt.

Flow.

Traditionele UI-automatisering denkt vaak in elementen.

Selector zoeken.
Selector klikken.
Andere selector zoeken.
Waarde controleren.

Die aanpak blijft nuttig, maar applicaties worden niet ervaren als verzamelingen selectors.

Mensen ervaren flows.

Inloggen.
Beheer openen.
Een gebruiker vinden.
Een instelling wijzigen.
Van database wisselen.
Van taal wisselen.
Het resultaat verifiëren.

Doorgaan met werken.

COCO behandelt de reeks daarom als een proces in plaats van als een willekeurige verzameling bedieningselementen.

Het volgt wat de gebruiker probeert te bereiken en evalueert de applicatie in context.

Dat wordt bijzonder waardevol bij het testen van echte bedrijfssoftware, omdat storingen vaak optreden tussen schermen of tussen statussen, niet binnen een individuele knop.

Een logistieke workflow kan een order, een voorraadreservering, een pickactie, een pakbon en een verzendbevestiging bevatten.
Elk afzonderlijk scherm kan correct lijken terwijl het volledige proces fout is.
Hetzelfde principe geldt hier op kleinere schaal.
Het beheervenster is niet het product.

De workflow erdoorheen is dat wel.

Evidence Instead of Assumption

Een van de belangrijkste taken van COCO is niet klikken. Het is onthouden wat er is gebeurd.
Menselijk regressietesten eindigt vaak met een uitspraak als:
"Ik heb het getest en alles zag er goed uit."

Dat kan volkomen accuraat zijn.
Maar enkele weken later, wanneer een probleem opduikt, zijn de nuttige vragen anders:

  • Welke release is getest?
  • Welke database?
  • Welke taal?
  • Welke gebruikersstatus?
  • Wat gebeurde er voorafgaand aan het probleem?
  • Wat was er precies zichtbaar?

In welke volgorde zijn de acties uitgevoerd?
COCO's testruns zijn ontworpen om bewijs achter te laten.

Dat verandert een testresultaat van een mening in iets dat geïnspecteerd kan worden.
Een geslaagde run wordt daardoor ook nuttig.
Het legt een bekende referentiestatus vast waarmee later gedrag vergeleken kan worden.

COCO Is Not the Decision Maker

Er is een belangrijke grens in de manier waarop we AI gebruiken voor softwaretesten.
COCO is niet bedoeld om engineering-verantwoordelijkheid te vervangen.

Het beslist niet hoe een bedrijfsregel zou moeten zijn.

Het test gedrag tegen scenario's, vereisten en verwachtingen die voor de applicatie zijn gedefinieerd.
Voor gevoelige beslissingen over rechten, prijzen, voorraad, financiële transacties of andere kritieke bedrijfsstatussen blijft het definiëren van correct gedrag een menselijke verantwoordelijkheid.

Dat onderscheid is belangrijk.
AI is uitstekend in het herhalen van een gedetailleerde test zonder de concentratie te verliezen.
Het is uitstekend in het verzamelen van bewijs.
Het kan schermen inspecteren, verwacht en waargenomen gedrag vergelijken en discrepanties verklaren.
Maar het bedrijf bepaalt nog steeds wat correct betekent.

COCO maakt die definitie testbaar.

The Test Nobody Wants to Repeat

Er is een eenvoudige reden waarom automatisering hier waarde toevoegt.
Een menselijke tester kan deze regressiesessie absoluut uitvoeren.
De eerste taal krijgt volledige aandacht.
Waarschijnlijk de tweede ook.
Dan nog een.
Dan nog een.
MySQL is al gecontroleerd.
PostgreSQL moet nog gecontroleerd worden.
De sorteertest is al meerdere keren uitgevoerd.
De Over-dialoog is al maanden niet veranderd.

Het is vrijdagmiddag.

En menselijke aandacht doet wat menselijke aandacht van nature doet.
Ze begint te optimaliseren.
COCO niet.
In de eigen geest van COCO:

  • Ik word niet moe van het klikken op dezelfde knop in elf talen. Ik sla de PostgreSQL-ronde niet over omdat het vrijdagmiddag is. Ik neem niet aan dat de sortering hield alleen omdat het in de vorige release werkte.

Voor COCO kan elke regressiesessie behandeld worden alsof het de eerste is.
Dat is geen intelligentie die een menselijke tester vervangt.
Het is automatisering die de menselijke tester beschermt tegen het deel van het testen waar menselijke aandacht het minst waard is.

From Repetitive Testing to Engineering Evidence

Het grotere doel van COCO is niet het maximaliseren van het aantal geautomatiseerde acties.
Duizend geautomatiseerde klikken zijn zinloos als niemand begrijpt wat ze bewijzen. Het nuttige resultaat is vertrouwen, ondersteund door bewijs.

Voor softify.pro Flow betekent dat te kunnen zeggen dat een release is getest over de operationele gebieden die ertoe doen:

  • authenticatie
  • gebruikersbeheer
  • rol- en toegangsinformatie
  • status van tweefactorauthenticatie
  • sorteergedrag
  • MySQL-werking
  • PostgreSQL-werking
  • live lokalisatie
  • statusfeedback
  • applicatie-informatie
  • licentie-informatie

en dat het resultaat bewaard blijft in een vorm die later beoordeeld kan worden.
Hetzelfde principe schaalt ver buiten deze applicatie.
Een inlogproces kan op deze manier getest worden.
Een boekingsworkflow kan op deze manier getest worden.
Een logistiek proces kan op deze manier getest worden.
Een platformonafhankelijke desktopapplicatie kan op deze manier getest worden.
De schermen veranderen.
De bedrijfsregels veranderen.
Het principe niet:
de verwachte workflow definiëren, deze consistent uitvoeren, bewijs verzamelen en het resultaat begrijpelijk maken.

Why We Test Our Own Software With COCO

Er is nog een reden waarom softify.pro Flow ertoe doet als COCO-case study.

Het is onze eigen software.
Dat verwijdert de comfortabele afstand die soms bestaat tussen een technologiedemonstratie en de mensen die deze uitvoeren.

Als COCO bedoeld is om enterprise-software te testen, moet het nuttig genoeg zijn om het toe te vertrouwen aan software die wij zelf ontwikkelen en uitbrengen.

Flow fungeert daarom zowel als product als testterrein.
Nieuwe testmogelijkheden kunnen worden beproefd tegen een echte applicatie.
Onverwacht gedrag kan zwaktes blootleggen in de applicatie, het testplan of COCO zelf.

Elke kant verbetert de andere.
Die feedbacklus is veel waardevoller dan het bouwen van kunstmatige demonstraties die alleen ontworpen zijn om te slagen. Een testsysteem zou niet overtuigend moeten lijken omdat de demonstratie eenvoudig was.
Het zou overtuigend moeten worden omdat het de kleine dingen blijft vinden die mensen uiteindelijk zouden stoppen te controleren.

The Result

softify.pro Flow — Administration beschikt nu over een gedocumenteerd en herhaalbaar regressieproces dat COCO kan uitvoeren voorafgaand aan relevante releases.

De test omvat beide ondersteunde databaseomgevingen en de elftalige interface van de applicatie, terwijl de applicatie wordt gevolgd zoals een beheerder deze zou gebruiken, in plaats van elk scherm als een geïsoleerd testdoel te behandelen.

COCO produceert een bewijsspoor dat toont wat er is getest, wat er is waargenomen en in welke volgorde de sessie plaatsvond.

Dat bewijs kan lokaal onder controle blijven.
Ontwikkelaars krijgen een reproduceerbaar startpunt wanneer er iets verandert.
Menselijke testers besteden minder tijd aan het herhalen van voorspelbare interacties en meer tijd aan het onderzoeken van situaties die daadwerkelijk beoordelingsvermogen vereisen.

En softify.pro Flow krijgt iets waardevollers dan een groene PASS-indicator.

Het krijgt bewijs dat de ervaring die op het aanmeldscherm wordt beloofd, blijft bestaan nadat de onderliggende code is veranderd.

Control. Weten wat er wordt getest en de omgeving onder controle houden.

Clarity. Begrijpen wat er is gebeurd zonder een ondoorzichtig automatiseringslogboek te hoeven reconstrueren.

Flow. De applicatie testen als een proces dat mensen daadwerkelijk gebruiken.

Control. Clarity. Flow.

Het werd geschreven voor de software.
Het bleek net zo goed de testfilosofie erachter te beschrijven.

Permalink →

Wetenswaardigheden

Pure fluidity meets ultimate performance: wat bedrijfssoftware echt snel maakt

Pure fluidity meets ultimate performance: wat bedrijfssoftware echt snel maakt

Een magazijnleider herkent slechte software niet aan een architectuurtekening. Hij herkent haar eraan dat medewerkers weer naar de telefoon grijpen, leveringsbonnen dubbel registreren of na een ploeg niet kunnen zeggen welke goederen er werkelijk zijn aangekomen. Pure fluidity meets ultimate performance mag daarom geen louter visuele pretentie zijn. Voor bedrijfssoftware betekent het dat een proces natuurlijk aanvoelt en tegelijk onder reële omstandigheden betrouwbaar functioneert.

Een elegante interface is waardeloos als ze hapert bij zwakke wifi in het magazijn. Een snelle toepassing helpt evenmin veel als ze een werkvolgorde afdwingt die niemand bij de laadperron kan volgen. Goede digitale hulpmiddelen verbinden ontwerp, snelheid en procesbegrip. Ze verminderen wrijving zonder het bedrijf in een voorgefabriceerde standaardlogica te persen.

Pure fluidity meets ultimate performance is een bedrijfsvraag

Vloeiendheid wordt vaak verward met animaties, grote afbeeldingen en gladde overgangen. Dat kan bij een modern merk passen. In het dagelijks werk toont ze zich echter anders: een goederenontvangst kan zonder omwegen worden geboekt. Een medewerker vindt een order ook wanneer alleen een referentienummer bekend is. Een fout wordt duidelijk benoemd, in plaats van te verdwijnen in een cryptische melding.

Prestaties zijn evenzeer meer dan een goede waarde in een browsertest. Doorslaggevend zijn de responstijd bij een order met veel posities, de stabiliteit aan het einde van de maand en de vraag of vijf personen tegelijk kunnen werken zonder elkaars gegevensstanden te overschrijven. Ook een nette omgang met verbindingsonderbrekingen, rechten en geblokkeerde accounts hoort erbij.

Beide zijn onlosmakelijk. Als een scherm direct reageert maar onduidelijke verplichte velden heeft, blijft het vermoeiend. Als het proces slim is gemodelleerd maar de pagina bij elke boeking twee seconden wacht, wordt het omzeild. Vloeiendheid ontstaat waar het systeem de volgende zinvolle handeling ondersteunt en technisch snel genoeg blijft, zodat de gedachtegang niet afbreekt.

De interface volgt het werkpad, niet het organigram

Veel standaardoplossingen structureren hun menu's naar modules: inkoop, verkoop, magazijn, rapportage, beheer. Vanuit productperspectief is dat begrijpelijk. Op de magazijnvloer begint het werk echter vaak met een situatie: een vrachtwagen staat er, een pallet ontbreekt, een klant heeft een leveringsbewijs nodig of een zending moet nog vóór de acceptatiesluiting worden geëtiketteerd.

Een goede individuele toepassing begint daarom met deze situaties. Welke informatie ligt er? Wie beslist? Wat moet worden gedocumenteerd? Wat mag later niet meer worden gewijzigd? Pas daarna wordt beslist welk invoerscherm, welke controle of automatisering nodig is.

Dat betekent niet dat elk bestaand proces ongewijzigd in software wordt gegoten. Sommige tabellen zijn werkelijk te foutgevoelig, sommige vrijgaven onnodig traag. Maar een werkende Excel-lijst hoeft niet noodzakelijk door een project te worden vervangen. Als ze slechts door één persoon wordt bijgehouden, weinig uitzonderingen kent en navolgbaar blijft, kan ze het passende hulpmiddel zijn. Software loont wanneer ze de coördinatie verbetert, foutbronnen verlaagt of informatie voor meerdere betrokkenen betrouwbaar beschikbaar maakt.

Minder klikken is niet automatisch beter

De eis van zo weinig mogelijk klikken klinkt redelijk, maar kan in de verkeerde richting leiden. Bij een onomkeerbare magazijnboeking is een korte bevestiging zinvol. Bij een verzendvrijgave kan een zichtbare plausibiliteitscontrole dure nabewerking voorkomen. Het juiste proces hangt af van het risico.

Doorslaggevend is dat extra stappen een duidelijk doel hebben. Een bevestiging mag niet alleen verschijnen omdat het framework ze gemakkelijk genereert. Ze moet precies staan waar mensen bewust een beslissing moeten nemen. Zo blijft de toepassing snel zonder lichtzinnig te worden.

Prestaties ontstaan in de architectuur, niet in de laatste sprint

Wie een website of webtoepassing pas kort vóór de go-live versnelt, behandelt meestal symptomen. Grote query's, onduidelijke datamodellen en achteraf aangevulde bijzondere gevallen laten zich niet door één enkele optimalisatiedag blijvend corrigeren.

Een deugdelijke basis begint met een database die overeenkomt met de werkelijke relaties in het bedrijf. In MySQL 8 hebben bewegingen, documenten, statuswijzigingen en gebruikersacties navolgbare sleutels en zinvolle indexen nodig. Een voorraad mag niet alleen als getal verschijnen als later moet worden opgehelderd door welke boeking ze is ontstaan. Tegelijk hoeft niet elke historische informatie bij elke paginaweergave opnieuw te worden berekend.

Bij moderne webtoepassingen is ook de scheiding van verantwoordelijkheden relevant. PHP 8.4 kan bedrijfsregels helder en onderhoudbaar afbeelden, terwijl moderne JavaScript gericht wordt ingezet voor reactieve gebieden. Dat is geen geloofsbelijdenis voor een bepaalde stack. Het is een kwestie van onderhoud: kunnen wijzigingen over zes maanden veilig worden doorgevoerd? Is zichtbaar waar een regel geldt? Kan een fout worden gereproduceerd, in plaats van alleen vermoed?

Prestaties hebben bovendien grenzen nodig. Zoekvelden hebben zinvolle minimumtekens of een precieze filterlogica nodig als miljoenen records denkbaar zijn. Grote lijsten hebben pagina's of getrapte naladingsprocessen nodig. Afbeeldingen en documenten mogen het kritieke werkproces niet blokkeren. Deze beslissingen lijken onspectaculair. Juist daarom blijven ze vaak langer waardevol dan een opvallend frontendeffect.

Zichtbare snelheid schept vertrouwen

Niet elk proces kan in minder dan een seconde zijn afgerond. Een etiketprint, een interface naar de transporteur of een controle tegen externe gegevens kost af en toe tijd. Doorslaggevend is dan hoe de toepassing met wachttijd omgaat.

Een duidelijke status zoals “Verzendlabel wordt aangemaakt” is beter dan een bevroren knop. Na afronding moet herkenbaar zijn welk nummer is aangemaakt en of het proces opnieuw mag worden gestart. Als een externe dienst niet bereikbaar is, heeft het team een begrijpelijke handelingsoptie nodig in plaats van een foutmelding voor ontwikkelaars.

Dat is ook een kwestie van gegevensintegriteit. Een dubbelklik mag geen twee leveringen aanmaken. Een afgebroken proces mag niet stilzwijgend een half afgemaakt record achterlaten. Goede systemen plannen zulke gevallen in, omdat ze in het dagelijks werk zullen optreden. Juist bij wisselende ploegen, tijdsdruk en mobiele apparaten is de uitzondering geen randthema.

Kwaliteit wordt zichtbaar vóór de fout

Voor toepassingen met veel procesvarianten volstaat het niet om aan het einde een paar paden handmatig door te klikken. Wijzigingen aan prijzen, rollen, validaties of interfaces kunnen op een ver verwijderde plek gevolgen veroorzaken. Hier wordt geautomatiseerd testen een onderdeel van de prestaties: niet alleen technisch, maar organisatorisch.

Een testsysteem zou echte processen moeten kunnen controleren, zoals een order aanmaken, een positie wijzigen, een leveringsbon genereren en een recht controleren. Het zou bewijzen moeten vastleggen en resultaten zo formuleren dat vakafdelingen ze kunnen plaatsen. Een zin als “Het verzendproces werd na de adreswijziging niet afgerond” helpt meer dan een ongecommentarieerde stacktrace.

Voor veiligheidsbewuste teams is ook de plek relevant waar deze tests draaien. Als screenshots, toegangsgegevens, testgevallen of interne toepassingsstappen het bedrijf niet mogen verlaten, is een zelfgehoste aanpak vaak zinvoller dan een externe clouddienst. Met COCO kunnen geautomatiseerde tests voor web- en Windows-toepassingen op een speciale omgeving worden uitgevoerd. Dat is niet voor elk team nodig. Bij gevoelige gegevens, gereguleerde gebieden of interne vaktoepassingen kan de controle over testgegevens echter een beslissend voordeel zijn.

Ontwerp is goed wanneer het werk vergemakkelijkt

Een sterke visuele identiteit kan vertrouwen scheppen. Ze toont dat een bedrijf zijn digitale aanwezigheid serieus neemt. In het operationele systeem moet ontwerp echter nog meer leveren: oriëntatie onder tijdsdruk. Contrast, typografie, duidelijke toestanden en begrijpelijke labels bepalen of iemand een proces zeker afrondt of bij de collega navraagt.

Terughoudendheid is hierbij vaak de betere keuze. Een dashboard met tien gekleurde kengetallen kan indrukwekkend ogen en toch de enige relevante afwijking verbergen. Een beperkte weergave die openstaande goederenontvangsten, ontbrekende scans en bedreigde leverdata zichtbaar maakt, is nuttiger. De vraag luidt niet hoeveel interface mogelijk is, maar welke informatie een beslissing verbetert.

Dat geldt ook voor responsieve toepassingen. Mobiele geschiktheid betekent niet elk desktopscherm in een kleiner formaat te persen. Een smartphone bij de goederenontvangst heeft misschien alleen scan, hoeveelheid, opslaglocatie en bevestiging nodig. De uitgebreide nabewerking hoort mogelijk op een groter scherm. Verschillende apparaten verdienen verschillende prioriteiten, hoewel ze dezelfde betrouwbare gegevensbasis gebruiken.

Een zinvolle maatstaf voor de volgende beslissing

Voordat een team een nieuw platform, een automatisering of een complete nieuwbouw besluit, helpt een eenvoudige toets: wordt het proces voor de mensen die het dagelijks uitvoeren duidelijker, sneller of veiliger? En is de oplossing nog te begrijpen wanneer eisen, medewerkers of interfaces veranderen?

Als beide antwoorden deugdelijk zijn, wordt uit een mooie belofte een bruikbaar systeem. Dan toont pure fluidity meets ultimate performance zich niet in een dia, maar op een rustige werkdag waarop orders, gegevens en beslissingen zonder onnodige wrijving doorlopen.

Permalink →

SaaS Flow Web: workflows veilig invoeren tijdens de lopende bedrijfsvoering

SaaS Flow Web: workflows veilig invoeren tijdens de lopende bedrijfsvoering

Een goederenontvangst blijft niet liggen omdat een team nog een stuk software niet kent. Ze blijft liggen omdat informatie verloren gaat tussen e-mail, papieren formulier, Excel-bestand en telefoongesprek. Bij SaaS - “Flow Web” op flow.softify.pro - hoort daarom niet de interface de eerste vraag te zijn. Doorslaggevend is of de dienst een concreet werkproces betrouwbaar afbeeldt - ook op hectische dagen, bij wisselende verantwoordelijkheden en wanneer een levering niet met het plan overeenkomt.

Voor kleine en middelgrote bedrijven is SaaS vaak zinvol, omdat ze niet eerst eigen servers, releases en basisfuncties hoeven op te bouwen. Maar dat is geen vrijbrief voor elk proces. Wie een hulpmiddel invoert dat het dagelijks werk ingewikkelder maakt of belangrijke gegevens verdringt naar onduidelijke zijlijsten, digitaliseert geen werk. Hij verplaatst alleen de wrijving.

Wat SaaS “Flow Web” moet leveren

Een webworkflow is goed wanneer medewerkers zonder interpretatie weten wat de volgende stap is. Bij een goederenontvangst kan dat betekenen: levering registreren, hoeveelheden tegen de bestelling controleren, afwijking documenteren, opslaglocatie toewijzen en zo nodig een verantwoordelijke informeren. Het proces hoeft niet spectaculair te zijn. Het moet navolgbaar, snel en herhaalbaar zijn.

Precies hier ligt het verschil tussen een algemene taken-app en een vakinhoudelijk processysteem. Een taken-app kan een punt aanmaken met de naam “Levering controleren”. Een vakinhoudelijke workflow kan bovendien vastleggen welke levering bedoeld is, wie haar heeft aangenomen, welke positie beschadigd was, welke foto's er zijn en of een nalevering openstaat. Deze gegevens staan dan niet als vrije tekst in één enkele opmerking, maar waar de volgende persoon ze nodig heeft.

Voor een oplossing als Flow Web op flow.softify.pro zou de toetsing daarom bij de processen moeten beginnen, niet bij een functielijst. Een bedrijf met vijf magazijnbewegingen per dag heeft iets anders nodig dan een verzendteam met meerdere cut-off-tijden, verschillende vervoerders en regelmatig deelleveringsbeheer. SaaS is geen vervanging voor procesbegrip.

Eerst het knelpunt benoemen, dan configureren

Veel digitaliseringsprojecten starten te breed: “We willen het magazijn digitaliseren.” Dat klinkt aannemelijk, maar leidt snel tot een systeem met te veel schermen, bijzondere gevallen en trainingsdocumenten. Beter is een precieze uitspraak zoals: “Goederenontvangsten worden pas de volgende dag geboekt, omdat leveringsbonnen aan het einde van de ploeg op het bureau liggen.”

Uit zo'n zin laat zich een zinvolle start afleiden. De eerste versie kan leveringsbonnen registreren, artikelen en hoeveelheden bevestigen, afwijkingen markeren en de boeking doorgeven aan de bevoegde afdeling. Als dit proces werkt, kunnen etiketten, leveranciersbeoordelingen of automatische bestelvoorstellen later worden toegevoegd. Niet elke zinvolle uitbreidingsstap hoort in de eerste uitrol.

Ook een goed onderhouden tabel mag blijven als ze haar doel vervult. Een maandelijkse evaluatie met weinig betrokkenen in een bestaand bestand kan bijvoorbeeld goedkoper en transparanter zijn dan een eigen module. SaaS loont waar informatie meermaals wordt gebruikt, verwerkingstijden kritiek zijn of fouten ontstaan door mediabreuken.

De juiste vragen vóór de invoering

Vóór de configuratie zou een team een echt proces van begin tot einde moeten doorspelen. Niet het ideale proces, maar het geval dat in het dagelijks werk problemen geeft: verkeerde hoeveelheid, ontbrekende referentie, dringende verzending of een order met bijzondere vrijgave. Daarbij komen de regels naar voren die een systeem werkelijk moet afbeelden.

Relevant zijn onder meer deze punten: wie mag een proces aanmaken, wijzigen of afsluiten? Welke invoer is verplicht, welke alleen nuttig? Wanneer moet een leidinggevende worden geïnformeerd? Welke gegevens gaan naar boekhouding, verzending of klantenservice? En wat gebeurt er als de wifi in het magazijn zwak is of een medewerker zijn inloggegevens niet meer heeft?

De antwoorden bepalen de kwaliteit van de invoering sterker dan een lange catalogus van visuele eisen. Een schoon rollenproces, een begrijpelijke foutmelding en een gedocumenteerde vrijgavestap voorkomen in de praktijk meestal meer inspanning dan een extra rapport op de startpagina.

Gegevensbewaring en rollen zijn geen bijzaak

SaaS wordt vaak behandeld als een louter bedieningsvraag. Voor bedrijfs- en IT-verantwoordelijken is echter minstens even belangrijk wat er met de gegevens gebeurt. Dat betreft stamgegevens, leveringsinformatie, medewerkersgegevens, foto's van schade en mogelijk klantgegevens. Vóór de invoering moeten verantwoordelijkheden, bewaring en exportmogelijkheden duidelijk zijn.

In de praktijk betekent dat: het bedrijf moet weten welke gegevens in het systeem staan, wie beheerderstoegang heeft en hoe gegevens worden aangeleverd bij een wissel of beëindiging van het contract. Een export die alleen als moeilijk leesbaar PDF-bestand beschikbaar is, helpt zelden verder. Voor operationele gegevens zijn gestructureerde, bruikbare formaten doorslaggevend.

Ook het rechtenconcept verdient concrete aandacht. In het magazijn hoeft niet iedereen prijzen, klantvoorwaarden of globale instellingen te zien. Tegelijk mag een te strakke rechtentoewijzing het proces niet blokkeren. Zinvol zijn rollen die aansluiten bij werkelijke taken: ontvangst, planning, verzending, teamleiding en beheer. Kritieke wijzigingen moeten navolgbaar zijn, zodat bij vragen niet hoeft te worden geraden wie een boeking heeft gewijzigd.

De toegang zelf moet met solide basisprincipes worden beschermd. Daartoe behoren veilige wachtwoordrichtlijnen, een geregelde wachtwoordherstelprocedure, account-lockout bij herhaalde mislukte pogingen en, waar het risicoprofiel dat vraagt, extra aanmeldstappen. Beveiliging werkt professioneel wanneer ze voorspelbaar is en niet pas opvalt wanneer iemand buitengesloten werd.

Integratie alleen waar ze meetbaar ontlast

Een webworkflow ontplooit haar waarde vaak pas in samenspel met bestaande systemen. Dat kan een ERP zijn, een webwinkel, een verzendoplossing, een tijdregistratie of een database. Toch is niet elke interface automatisch zinvol. Elke integratie schept afhankelijkheden, foutbeelden en onderhoudsinspanning.

De centrale vraag luidt: welke handmatige stap verwijdert de koppeling concreet? Als een interface dagelijks 30 minuten overdrachtswerk bespaart en typefouten vermindert, is het nut duidelijk. Als ze slechts een informatie spiegelt die toch eens per week wordt gecontroleerd, kan een handmatige export aanvankelijk de verstandigere oplossing zijn.

Bij individuele uitbreidingen telt de technische basis. Gedocumenteerde interfaces, duidelijk gedefinieerde gegevensvelden en navolgbare foutenlogboeken vergemakkelijken het latere beheer. Als een systeem aan een maatwerk-webtoepassing wordt gekoppeld, moeten technologieën en databasestructuur zo worden gekozen dat ze op lange termijn onderhoudbaar blijven. Een verzorgde toepassing op basis van PHP 8.4, moderne JavaScript en MySQL 8 is waardevoller dan een op korte termijn indrukwekkende speciale oplossing zonder documentatie.

Invoering tijdens de lopende bedrijfsvoering

De meest voorkomende fout is een harde start zonder vergelijkingsfase. Teams moeten dan op maandagochtend meteen anders werken, terwijl open vragen pas uit echte problemen ontstaan. Dat verhoogt de afwijzing, zelfs als de software in principe past.

Beter is een beperkte pilot met één team, één procesvariant of een duidelijk afgebakend vestigingsgebied. In die tijd wordt gecontroleerd of registratie en vrijgaven werken, of begrippen begrijpelijk zijn en of uitzonderingsgevallen netjes terechtkomen. Belangrijk is terugkoppeling niet alleen als wensenlijst te verzamelen. Elke wijziging moet worden getoetst aan het nut voor doorlooptijd, foutenpercentage of transparantie.

Ook kengetallen moeten vroeg worden vastgelegd. Zo kunnen bijvoorbeeld de verwerkingstijd per goederenontvangst, het aantal openstaande afwijkingen, navragen over leveringsstatus of correctieboekingen worden gevolgd. Zonder uitgangswaarde blijft “voelt sneller” de enige beoordeling. Dat kan kloppen, maar volstaat niet voor een deugdelijke investeringsbeslissing.

Beheer heeft een duidelijke eigenaar nodig

SaaS vermindert de technische inspanning, maar ontslaat een bedrijf niet van de verantwoordelijkheid voor het eigen proces. Er is intern iemand nodig die rollen beheert, terugkoppeling bundelt, trainingsbehoefte herkent en beslist welke wijzigingen werkelijk nodig zijn. Deze persoon hoeft niet te kunnen programmeren. Ze moet het werkproces echter begrijpen en toegang hebben tot de verantwoordelijken.

Even belangrijk is een korte, solide beheerdocumentatie. Ze legt niet elk scherm uit, maar beantwoordt de vragen die in het dagelijks werk opkomen: wat te doen bij een foutieve boeking? Wie keurt nieuwe gebruikers goed? Hoe wordt een storing gecommuniceerd? Waar staan geëxporteerde gegevens? Zulke duidelijkheid voorkomt dat een digitaal systeem na enkele maanden weer afhankelijk wordt van persoonlijke tussenkomsten.

Een goede SaaS-oplossing herkent men daarom niet aan hoeveel menupunten ze biedt. Ze toont haar waarde wanneer een nieuwe collega een proces zeker kan afhandelen, een afwijking niet verdwijnt en een leidinggevende de status ziet zonder drie mensen te bellen. Precies aan deze maatstaf zou Flow Web moeten worden gemeten: niet aan beloften, maar aan een werkdag die aantoonbaar rustiger en betrouwbaarder verloopt.

Permalink →

Webontwikkeling met actuele frameworks: wat bedrijven er echt aan hebben

Webontwikkeling met actuele frameworks: wat bedrijven er echt aan hebben

Als een goederenontvangst nog heen en weer pendelt tussen papieren formulier, telefoongesprek en drie Excel-bestanden, lost een modern frontend het probleem alleen niet op. Webontwikkeling met actuele frameworks is zinvol wanneer ze processen zichtbaar vereenvoudigt: medewerkers zien de volgende stap, gegevens worden slechts één keer vastgelegd en de toepassing blijft ook na de eerste go-live begrijpelijk onderhoudbaar.

Voor kleine en middelgrote bedrijven is de frameworkvraag daarom geen geloofskwestie. Doorslaggevend is niet of een interface bijzonder veel technische modewoorden draagt. Doorslaggevend is of magazijnbewegingen, orders, controles of vrijgaves betrouwbaar door de werkdag komen - ook onder tijdsdruk, bij ploegwissels en wisselende netwerkverbinding.

Frameworks zijn een middel, geen projectdoel

Een framework levert een beproefde structuur voor terugkerende taken: routing, formulieren, rechtenbeheer, gegevenstoegang, tests en de weergave van interfaces. Dat vermindert niet automatisch elk risico. Maar het voorkomt dat een project basisfuncties steeds opnieuw moet uitvinden.

Bij een individuele webtoepassing kan een modern JavaScript-framework bijvoorbeeld interactieve schermen zinvol weergeven: een verzamellijst die posities voortdurend bijwerkt, een routeplanning met duidelijke statuswisselingen of een controleprotocol dat foto's en opmerkingen direct aan een proces koppelt. In de backend zorgen gevestigde PHP-frameworks voor navolgbare regels, duidelijk gescheiden verantwoordelijkheden en consistente interfaces naar de database.

Dat is vooral relevant wanneer uit een aanvankelijk kleine oplossing een dagelijks gebruikt bedrijfssysteem voor een proces wordt. Een invoerscherm voor leveringsberichten kan overzichtelijk beginnen. Zodra het voorraden bijwerkt, etiketten uitvoert, rollen in aanmerking neemt en met een transporteur communiceert, heeft het een schone technische basis nodig. Frameworks helpen die basis niet bij elke uitbreiding opnieuw te hoeven bespreken.

Wat actuele webframeworks concreet beter doen

De waarde van moderne frameworks ligt zelden in spectaculaire effecten. Ze blijkt in de onzichtbare delen van een toepassing. Formulieren kunnen invoer direct controleren, zonder dat foutieve gegevens pas na het verzenden opvallen. Rechten kunnen centraal worden gedefinieerd, zodat een chauffeur andere informatie ziet dan de planning. Wijzigingen aan een bestelling worden navolgbaar opgeslagen, in plaats van stilletjes een tabelcel te overschrijven.

Aan serverzijde schept een actuele omgeving met PHP 8.4 en MySQL 8 een robuuste basis voor bedrijfskritieke logica. Databasetransacties voorkomen bijvoorbeeld dat een voorraad wordt verlaagd terwijl de bijbehorende boeking mislukt. Unieke sleutels en validatieregels vermijden dubbele records. Achtergrondprocessen kunnen documenten genereren of interfaces aanspreken zonder dat de persoon aan het scherm hoeft te wachten.

Ook beveiliging is geen achteraf toegevoegde functie. Een eigentijds framework ondersteunt veilige wachtwoordopslag, bescherming tegen typische invoeraanvallen, navolgbare sessies en gedefinieerde account-lockout-processen. Toch blijft de uitvoering een projecttaak: rechten moeten inhoudelijk correct worden gemodelleerd en gevoelige functies vragen extra controles. Een framework levert vangrails, maar geen kennis over wie in het bedrijf welke vrijgave mag verlenen.

Webontwikkeling met actuele frameworks juist beslissen

De beste technologie ontstaat niet uit een lijst populaire tools, maar uit het werkelijke gebruik. Een interne toepassing voor tien personen heeft andere eisen dan een klantenportaal met enkele duizenden gelijktijdige toegangen. Een magazijnterminal met scanner heeft een andere bedieningslogica nodig dan een managementanalyse op de desktop.

Daarom begint een zinvolle beslissing met concrete vragen: welke processen kosten vandaag meetbaar tijd? Welke gegevens worden meermaals overgedragen? Waar ontstaan fouten omdat informatie pas te laat zichtbaar wordt? Welke bestaande tabel werkt goed genoeg en zou voorlopig moeten blijven? Juist het laatste punt beschermt tegen dure digitaliseringsprojecten zonder operationeel nut.

Voor veel individuele bedrijfstoepassingen is een server-side gerenderd systeem met gerichte interactieve componenten de verstandigste keuze. Het laadt snel, is overzichtelijk te beheren en vermijdt onnodige complexiteit. Een volledig ontkoppelde single-page-toepassing kan daarentegen passend zijn wanneer de interface zeer veel dynamische toestanden verwerkt, offline moet werken of dezelfde functies later ook aan een mobiele app moet leveren.

Beide kunnen inhoudelijk juist zijn. De vraag luidt niet: welk framework is het modernst? Ze luidt: welke architectuur is over twee jaar nog veilig uitbreidbaar, testbaar en begrijpelijk voor het eigen team?

Wanneer minder techniek de betere techniek is

Niet elk proces heeft een complex frontend nodig. Een slank invoerscherm voor interne bestellingen kan sneller, stabieler en goedkoper zijn dan een uitgebreid geanimeerde interface. Als een Excel-bestand slechts eens per maand wordt bijgehouden en geen fouten veroorzaakt, is het mogelijk nog steeds het juiste hulpmiddel.

Complexiteit loont pas wanneer ze echte wrijving wegneemt. Dat kan het geval zijn wanneer orders meermaals worden overgetypt, de leveringsstatus telefonisch moet worden nagevraagd of niemand zeker weet welke versie van een document geldt. Dan schept een centrale toepassing duidelijk nut: één gegevensstand, eenduidige verantwoordelijkheden en minder navragen.

Onderhoudbaarheid begint vóór de eerste regel code

Frameworks worden vaak als versneller gezien. Dat klopt alleen als de inhoudelijke regels vooraf voldoende duidelijk zijn. Een ontwikkelaar kan een toestandsmachine technisch netjes bouwen. Of de statusvolgorde echt bij het proces past, wordt echter beslist bij de opname: wanneer geldt goederen als ontvangen? Wie mag een afwijking afsluiten? Wat gebeurt er bij een deellevering?

Deze beslissingen horen gedocumenteerd, evenals interfaces, gegevensvelden en uitzonderingen. Dat maakt projecten niet trager. Het vermindert latere discussies, omdat zichtbaar wordt welke regel bewust is geïmplementeerd en welke aanname nog openstaat.

Onderhoudbaarheid blijkt ook uit kleine disciplines. Databasewijzigingen moeten worden geversioneerd. Deploymentstappen moeten worden gedocumenteerd. Foutmeldingen moeten bruikbaar zijn voor beheer en ontwikkeling, zonder vertrouwelijke details prijs te geven. Geautomatiseerde tests controleren bij elke wijziging centrale processen, zoals het aanmaken van een order, de berekening van een hoeveelheid of de uitvoer van een leveringsbon.

Bij kritieke toepassingen volstaat een enkel testtype niet. Unit-tests borgen afzonderlijke regels, integratietests controleren het samenspel met database en interfaces, en end-to-end-tests spelen echte bedieningspaden in de browser na. Voor web- en Windows-toepassingen kan een zelfgehoste testomgeving bovendien screenshots, uitvoeringsprotocollen en begrijpelijke beoordelingen leveren, zonder interne testgegevens onnodig aan externe clouddiensten te geven.

Prestaties ontstaan uit architectuur en datamodel

Een moderne interface wordt niet snel doordat ze een actueel framework gebruikt. Trage databasequery's, te grote afbeeldingen of onduidelijke interfaces blijven traag, ongeacht het frontend. Vooral bij lijsten met orders, artikelen of bewegingsgegevens bepaalt het datamodel de gevoelde snelheid.

Schone indexen in MySQL 8, gepagineerde query's en bewust geladen gegevens zijn vaak effectiever dan latere optimalisatie aan de interface. Even belangrijk is een duidelijk cachingconcept. Stamgegevens mogen onder omstandigheden worden gecachet, actuele voorraden of vrijgavestatus daarentegen niet blindelings. Hier is geen algemene regel, omdat de inhoudelijke betekenis van de gegevens bepaalt hoe actueel ze moeten zijn.

Responsief ontwerp hoort eveneens bij de technische planning. Op het kantoorscherm kan een brede tabel zinvol zijn. Op een handscanner of tablet in het magazijn heeft dezelfde informatie grote tikvlakken, korte wegen en een weergave nodig die ook met handschoenen of bij slecht licht bedienbaar blijft. Pure fluidity meets ultimate performance betekent in deze context niet zo veel mogelijk beweging op het scherm. Het betekent dat de toepassing zonder wrijving werkt op het apparaat dat in het proces daadwerkelijk wordt gebruikt.

De zinvolle weg van idee naar bedrijf

Een robuust webproject start met een beperkte, controleerbare kern. In plaats van elke denkbare uitzondering vooraf te automatiseren, wordt een proces gekozen dat vaak voorkomt en merkbaar inspanning veroorzaakt. Na de eerste inzet tonen echte gegevens en terugkoppeling welke uitbreiding als volgende werkelijk prioriteit heeft.

De technische overdracht zou niet pas aan het einde moeten plaatsvinden. Verantwoordelijkheden voor hosting, back-ups, monitoring, updates en toegangsrechten moeten vroeg worden verduidelijkt. Een systeem is slechts zo betrouwbaar als zijn beheer. Wie een toepassing dagelijks voor verzending of orderafhandeling nodig heeft, heeft gedefinieerde herstelwegen nodig en een duidelijk antwoord op wat er bij een storing gebeurt.

softify.pro zet daarom in op onderhoudbare technologieën, gedocumenteerde oplevering en directe technische verantwoordelijkheid in plaats van op kortstondige frameworkmodes. Dat is geen magische sluiproute. Het schept de voorwaarde dat een toepassing na de lancering blijft werken, verder kan worden ontwikkeld en niet het volgende fragiele bijzondere geval wordt.

De juiste webtoepassing voelt in het beste geval niet als een nieuw IT-project. Ze voelt als een proces dat eindelijk zonder omwegen werkt - met genoeg technische substantie om ook de volgende verandering in de bedrijfsvoering rustig op te vangen.

Permalink →

Contacteer ons

Hebt u een project in gedachten, een workflow die nog draait op spreadsheets en goede wil, of een testachterstand die COCO van uw team kan overnemen? Vertel het ons.

Bericht versturen