Naar de hoofdinhoud
FromNine
Menu

Software en cloud

Bedrijfssoftware en SaaS-producten op maat, gebouwd om lang mee te gaan

Wij ontwikkelen SaaS-producten, portalen voor burgers en medewerkers en kernapplicaties die toegankelijk zijn, standaard veilig en nog lang na de lancering onderhoudbaar door uw eigen teams.

Voor Belgische softwarebedrijven, overheden en ondernemingen die gebruikers bedienen in meerdere landstalen en op meerdere bestuursniveaus.

Bespreek uw projectBekijk onze aanpak
Bedrijfssoftware & SaaS: de lagen van de dienstVier lagen, in de diepte gestapeld. Van boven naar beneden: de toegankelijke interface die mensen gebruiken, de domeinmodules met de bedrijfsregels, de platformdiensten voor tenancy en identiteit, en daaronder de veilige opleverpijplijn.01Toegankelijke interfaces02Domeinmodules en regels03Tenancy, identiteit, data04Veilige opleverpijplijn
  1. 01Domain-driven design voor werk vol regels, zoals dossierbehandeling
  2. 02Toegankelijkheid volgens EN 301 549 en WCAG 2.2 AA vanaf de eerste sprint
  3. 03Documentatie en vastgelegde beslissingen die uw teams kunnen overnemen

01 Knelpunten

Wat wij horen vóór een herbouw

  1. 01

    Elke wijziging duurt een kwartaal

    De applicatie werkt, maar niemand durft aan de kern te komen. Kleine wijzigingen vragen grote regressietests en een releasevenster.

  2. 02

    Het portaal laat de mensen in de steek voor wie het bestaat

    Het werkt niet met een schermlezer, niet in de tweede officiële taal en niet op een smartphone. De klachten komen eerder binnen dan de toegankelijkheidsaudit.

  3. 03

    De wijziging van de ene klant breekt die van de andere

    Het SaaS-product groeide door per klant maatwerk toe te voegen. Nu is elke release een onderhandeling en zitten sommige tenants vast op oude versies.

  4. 04

    De kennis vertrok met de leverancier

    Beslissingen werden nooit opgeschreven. Het team dat de software bouwde is verdergegaan, en de code is de enige documentatie.

  5. 05

    Klanten en toezichthouders stellen beveiligingsvragen

    Inkoop vraagt om een SBOM, een proces voor kwetsbaarheden en bewijs voor de Cyberweerbaarheidsverordening (CRA). Niemand heeft ze klaar.

02 Wat we leveren

Wat wij leveren

  1. 01 SaaS-productontwikkeling

    Producten die vanuit één codebase veel klanten bedienen: het juiste tenancymodel, configuratie in plaats van maatwerk per klant, en releases die elke tenant bereiken.

    Wat we doen

    • Keuze van het tenancymodel: gedeeld, gegroepeerd of geïsoleerd per tenant
    • Strategie voor configuratie en feature flags
    • Integratie van verbruiksmeting en facturatie
    • Releasetreinen met uitrol per tenant

    Wat u ontvangt

    • Ontwerp voor tenancy en isolatie
    • Configuratiemodel met vangrails
    • Releaseproces met terugdraaien per tenant

  2. 02 Domeinontwerp voor complexe regels

    Domain-driven design waar de regels het product zijn: dossierbehandeling, toekenningsvoorwaarden, berekeningen vol regelgeving. Wij kiezen eerlijk tussen een modulaire monoliet en microservices, en starten meestal met het eerste.

    Wat we doen

    • Event storming met domeinexperts
    • Bounded contexts en modulegrenzen
    • Regels expliciet en testbaar gemaakt
    • Architectuurbeslissingen vastgelegd in decision records

    Wat u ontvangt

    • Domeinmodel en contextkaart
    • Modulaire codebase met afgedwongen grenzen
    • Uitvoerbare specificaties voor de belangrijkste regels

  3. 03 Portalen voor burgers en medewerkers

    Interfaces op een designsysteem, standaard toegankelijk en meertalig vanaf de eerste release. In België betekent dat drie officiële talen; elders de talen die uw gebruikers werkelijk spreken.

    Wat we doen

    • Designsysteem met toegankelijke componenten
    • Inhoud in heldere taal
    • Tests met hulptechnologie en echte gebruikers
    • Vertaalproces voor elke taal

    Wat u ontvangt

    • Portaal op een herbruikbaar designsysteem
    • Rapport over de conformiteit met toegankelijkheidseisen
    • Werkproces voor inhoud en vertaling

  4. 04 Quality engineering en veilige ontwikkeling

    Testautomatisering op de juiste niveaus, contracttests tussen diensten, performancetests vóór de lancering en een veilige ontwikkelcyclus op basis van OWASP ASVS, SBOM’s en controles op de softwareketen.

    Wat we doen

    • Teststrategie en testautomatisering
    • Contract- en performancetests
    • Dreigingsmodellering en verificatie volgens ASVS
    • Aanmaak van SBOM’s en beleid voor afhankelijkheden

    Wat u ontvangt

    • Geautomatiseerde testsuites in de pijplijn
    • Rapport van de beveiligingsverificatie
    • Proces voor kwetsbaarheden, klaar voor de Cyberweerbaarheidsverordening

  5. 05 Stapsgewijze modernisering

    Vervang een verouderde applicatie functie per functie, achter een routeringslaag, terwijl de organisatie gewoon doorwerkt. Zie ook modernisering van legacysystemen.

    Wat we doen

    • Functiekaart van de bestaande applicatie
    • Routering volgens het strangler-fig-patroon en API-wrapping
    • Datamigratie met afstemmingsrapporten
    • Parallelle runs voor kritieke berekeningen

    Wat u ontvangt

    • Moderniseringsvolgorde met zakelijke mijlpalen
    • Routeringslaag en nieuwe modules in productie
    • Afgestemde gegevens bij elke overgang

  6. 06 Onderhoudbaarheid en overdracht

    Software waar uw teams eigenaar van kunnen worden: leesbare code, vastgelegde beslissingen, runbooks en een overdrachtsplan dat bij de start wordt afgesproken, niet aan het eind wordt ontdekt.

    Wat we doen

    • Pair programming met uw ontwikkelaars tijdens de bouw
    • Architecture decision records, bewaard bij de code
    • Operationele runbooks en handleidingen voor wachtdiensten
    • Mijlpalen voor kennisoverdracht

    Wat u ontvangt

    • Overdrachtsplan met acceptatiecriteria
    • Documentatie in uw eigen repositories
    • Opgeleid intern team

03 Architectuur

Een illustratieve referentiearchitectuur

Een typische vorm voor een bedrijfsapplicatie die een oudere vervangt: een toegankelijke front-end, een routeringslaag die elke functie naar het oude of het nieuwe systeem stuurt, een API-laag met duidelijke contracten en een modulaire kern, opgebouwd rond het domein.

Tenancy en configuratie zijn expliciete platformdiensten, geen voorwaarden die verspreid door de code staan. Daaronder doorloopt elke build tests en beveiligingscontroles en levert hij een SBOM op.

Lagen in de tekening

Mensen
Burgers, klanten en medewerkers, op elk apparaat en met hulptechnologie.
Modernisering
De routeringslaag, de bestaande applicatie en de datamigratie met afstemming.
Platform
API-laag, identiteit, de modulaire kern, tenancy en configuratie, operationele data.
Veilige oplevering
Contract- en performancetests, ASVS-controles en een SBOM in elke build.
Illustratief voorbeeld

  1. Mensen

    • Burgers, klanten, medewerkers
    • Toegankelijke front-end

  2. Stapsgewijze modernisering

    • Routeringslaag
    • Bestaande applicatie
    • Migratie met afstemming

  3. Platform

    • API-laag en contracten
    • Identiteit en rollen
    • Modulaire kern: instroom, dossiers, facturatie
    • Tenancy, configuratie, feature flags
    • Operationele datastores

  4. Veilige oplevering

    • Contract- en performancetests, ASVS-controles, SBOM in elke build
Modulaire kern achter een routeringslaag

Illustratieve architectuur, geen systeem van een klant.

Lees het diagram als tekst

De hoofdroute loopt van mensen naar een toegankelijke front-end, via een routeringslaag en een API-laag, naar een modulaire kern die is opgedeeld in bounded contexts.

De routeringslaag stuurt sommige functies ook naar de bestaande applicatie, die stap voor stap wordt uitgefaseerd. De gegevens daarvan gaan via een migratie met afstemming naar de operationele datastores.

Identiteit bedient de API-laag. Diensten voor tenancy en configuratie liggen onder de kern. Een band voor veilige oplevering onderaan omvat contracttests, performancetests, beveiligingsverificatie en SBOM’s.

04 Aandachtspunten en grenzen

Technische afwegingen en grenzen

  • Eerst een modulaire monoliet

    Hoe we het aanpakken

    Wij starten met duidelijke modules in één deploybare eenheid en splitsen pas diensten af waar schaal, releaseritme of teameigenaarschap daarom vragen.

    Grenzen en afhankelijkheden

    Microservices lossen evenveel organisatorische als technische problemen op. Zonder teams die er eigenaar van zijn, voegen ze vooral kosten en faalwijzen toe.

  • Toegankelijkheid is engineeringwerk

    Hoe we het aanpakken

    Toegankelijke componenten, geautomatiseerde controles in de pijplijn en handmatige tests met hulptechnologie vóór elke grote release.

    Grenzen en afhankelijkheden

    Geautomatiseerde tools vinden maar een deel van de problemen. Volledige conformiteit vraagt handmatige audits en idealiter tests met gebruikers met een beperking.

    Inhoud en documenten die redacteuren na de lancering toevoegen, moeten aan dezelfde norm voldoen. Wij leiden redacteuren op, maar bepalen niet wat zij publiceren.

  • Modernisering duurt zo lang als de data

    Hoe we het aanpakken

    Datamigratie wordt per functie gepland, geoefend en afgestemd, met zakelijke goedkeuring bij elke overgang.

    Grenzen en afhankelijkheden

    De kwaliteit van de oude gegevens bepaalt vaak het tempo. Opschonen is evenzeer een taak van de organisatie als een technische taak.

  • Regelgeving voor softwareproducten

    Hoe we het aanpakken

    SBOM’s, de afhandeling van kwetsbaarheden en veilige standaardinstellingen horen bij onze standaardpijplijn. Zo zijn producten voorbereid op de Cyberweerbaarheidsverordening.

    Grenzen en afhankelijkheden

    Of en hoe de verordening op uw product van toepassing is, is een juridische vraag. Wij leveren het technische bewijs; uw juristen maken de beoordeling.

05 Hoe we werken

Zo werken wij

Korte cycli, vroeg echte gebruikers en een overdracht die vanaf de eerste week is gepland.

  1. 01

    Het domein in kaart brengen

    Event storming met de mensen die de regels kennen, en een functiekaart van wat er vandaag bestaat.

    ResultaatContextkaart en eerste decision records

  2. 02

    Een dunne plak opleveren

    Eén functie van begin tot eind, via de routeringslaag, in productie bij echte gebruikers.

    ResultaatWerkende plak in productie

  3. 03

    Groeien per functie

    Elke release verhuist een functie, met haar gegevens en gebruikers, met afstemming en een terugvalplan klaar.

    ResultaatReleaseplan per functie

  4. 04

    Overdragen

    Uw ontwikkelaars werken samen met de onze, nemen de wachtdienst over en worden eigenaar van de roadmap zodra aan de overdrachtscriteria is voldaan.

    ResultaatAanvaarde overdracht

06 Menselijke controle

Waar mensen de controle houden

In bedrijfssoftware betekent controle: weten wie wat heeft gewijzigd, wie het heeft goedgekeurd en hoe het terug te draaien is.

  • Producteigenaars bepalen de scope

    Uw product owner bepaalt de prioriteiten en aanvaardt elke oplevering. Wij adviseren, zij beslissen.

  • Configuratie heeft een eigenaar

    Instellingen per tenant en feature flags worden gewijzigd via een geaudit proces, door rollen die u toewijst.

  • Overgangen worden goedgekeurd

    Elke overstap van het oude naar het nieuwe systeem wordt door de organisatie goedgekeurd, met een geoefend terugvalplan.

  • Beslissingen worden opgeschreven

    Architecture decision records tonen wat werd gekozen, door wie en waarom, zodat toekomstige teams er met kennis van zaken op kunnen terugkomen.

07 Technologieën

Technologieën waarmee wij werken

Back-end
  • Java en Kotlin
  • .NET
  • TypeScript en Node.js
  • Python
Front-end
  • React en Next.js
  • Angular
  • Designsystemen met toegankelijke componenten
  • Native en cross-platform mobiele apps
Data
  • PostgreSQL
  • SQL Server en Oracle (bestaande omgevingen)
  • Eventstreaming
  • Zoekmachines
Kwaliteit en beveiliging
  • Playwright en contracttests
  • Load- en performancetests
  • SAST, DAST en scans van afhankelijkheden
  • SBOM in CycloneDX of SPDX

Een technologie in deze lijst beschrijft onze engineeringervaring. Ze impliceert geen partnerschap met of aanbeveling door de leverancier.

08 Voorbeeld

Een illustratief voorbeeld

Illustratief voorbeeld

Eén klantenportaal in drie landstalen

01Situatie
Een Belgische dienstverlener heeft drie klantenportalen van drie leveranciers: een Nederlandstalig, een Franstalig en een voor zakelijke klanten. Elk faalt op andere toegankelijkheidstesten en elke wijziging gebeurt drie keer.
02Wat we zouden bouwen
Eén portaal op een gedeeld designsysteem, met inhoud in het Nederlands, het Frans en het Duits, aanmelden via itsme en koppelingen in configuratie, op één releasetrein.
03Waar mensen beslissen
Redacteurs per taal keuren de inhoud goed; de product owner beslist over gedeelde functies.
04Wat we zouden meten
Toegankelijkheidsproblemen per release, doorlooptijd van een wijziging en aandeel wijzigingen dat maar één keer gebeurt.

09 Per sector

In uw sector

  • Publieke sector & overheid

    Dossierbeheer en burgerportalen die aan de toegankelijkheidswetgeving voldoen, in elke officiële taal werken en aansluiten op nationale gegevensuitwisseling.

  • Financiële dienstverlening

    Klantportalen en backofficeapplicaties met sterke audittrails en releaseprocessen die aan de eisen van change management voldoen.

  • Industrie & productie

    Configurators, serviceportalen en SaaS-producten voor machinebouwers, gekoppeld aan ERP en buitendienst.

België

Software voor Belgische gebruikers

Software voor Belgische gebruikers is meertalig van bij het begin, en vaak gekoppeld aan federale of Vlaamse bouwstenen: aanmelden met eID of itsme via de Federale Authenticatiedienst, berichten naar de eBox, gegevens volgens de OSLO-standaarden. De Europese toegankelijkheidsrichtlijn is in Belgisch recht omgezet en geldt sinds juni 2025 ook voor heel wat private digitale diensten.

Wij houden die verschillen in configuratie en duidelijk afgebakende modules. Bewijs van toegankelijkheid en beveiligingsdocumentatie komen uit de pijplijn, klaar voor de vragen in een bestek.

Vragen over bedrijfssoftware en SaaS

Moeten we op maat laten bouwen of een platform configureren?

Configureer een platform waar uw proces dicht bij de standaard ligt, en bouw op maat waar het proces u onderscheidt of waar geen platform bij de regels past. Wij werken met Salesforce, SAP en Odoo én met maatwerkcode, dus wij hebben geen reden om één antwoord door te drukken. Ons werk in architectuur en advies maakt die keuze expliciet.

Kunt u garanderen dat ons portaal toegankelijk is?

Wij bouwen volgens EN 301 549 en WCAG 2.2 AA, testen geautomatiseerd en handmatig, en leveren een conformiteitsrapport met de bekende problemen. Wij beloven niet dat er geen enkel probleem is; wij beloven dat we ze opsporen, rapporteren en oplossen wat binnen onze scope valt.

Kunt u moderniseren zonder big-bangmigratie?

Ja, en dat raden wij ook aan. Met een routeringslaag verhuizen we functie per functie terwijl de bestaande applicatie blijft draaien, met afgestemde gegevens bij elke stap.

Kan ons eigen team de software overnemen?

Dat is het standaardplan. De overdrachtscriteria worden bij de start afgesproken, uw ontwikkelaars werken tijdens de bouw samen met de onze, en decision records en runbooks staan in uw eigen repositories.

Wat betekent de Cyberweerbaarheidsverordening (CRA) voor ons product?

Als u software met digitale elementen op de Europese markt brengt, kan die verordening verplichtingen meebrengen voor veilig ontwerp, de afhandeling van kwetsbaarheden en documentatie. Wij leveren het technische bewijs: SBOM’s, een proces voor kwetsbaarheden en veilige standaardinstellingen. De juridische beoordeling blijft bij uw juristen.

Vertel ons wat moet blijven draaien terwijl het verandert

Wij stellen voor welke functionaliteit eerst verhuist en wat uw team op het einde zelf beheert. Een prijsofferte voor een afgebakende eerste fase is mogelijk.

Bespreek uw projectBekijk onze aanpak