Skip to main content
FromNine
Menu

Engineering

Enterprise software your own teams can keep changing.

We engineer SaaS products, citizen and employee portals and core business applications that are accessible, secure by default and maintainable by your own teams long after launch.

For product companies and public bodies that serve users in several countries, languages and legal regimes.

Discuss your projectSee legacy modernisation
Enterprise Software & SaaS: capability stackFour layers stacked in depth. From top to bottom: the accessible interface people use, the domain modules that hold the rules, the platform services for tenancy and identity, and the secure delivery pipeline underneath.01Accessible interfaces02Domain modules and rules03Tenancy, identity, data04Secure delivery pipeline
  1. 01Domain-driven design for rule-heavy work such as case handling
  2. 02Accessibility to EN 301 549 and WCAG 2.2 AA from the first design
  3. 03Documentation and decision records your teams can take over

01 Problems

What we hear before a rebuild

  1. 01

    Every change takes a quarter

    The application works, but nobody dares touch the core. Small changes need large regression tests and a release window.

  2. 02

    The portal fails the people it serves

    It does not work with a screen reader, in the second official language or on a phone. Complaints arrive before the accessibility audit does.

  3. 03

    One customer’s change breaks another’s

    The SaaS product grew by customising per client. Now every release is a negotiation and some tenants are stuck on old versions.

  4. 04

    The knowledge left with the supplier

    Decisions were never written down. The team that built it has moved on, and the code is the only documentation.

  5. 05

    Security questions arrive from customers and regulators

    Procurement asks for an SBOM, a vulnerability process and evidence for the Cyber Resilience Act. Nobody has them ready.

02 Delivery ledger

What we deliver

  1. 01 SaaS product engineering

    Products designed to serve many customers from one codebase: the right tenancy model, configuration instead of customisation, and releases that reach every tenant.

    What we do

    • Tenancy model choice: shared, pooled or isolated per tenant
    • Configuration and feature-flag strategy
    • Metering and billing integration
    • Release trains with tenant-aware rollout

    What you receive

    • Tenancy and isolation design
    • Configuration model with guardrails
    • Release process with rollback per tenant

  2. 02 Domain design for complex rules

    Domain-driven design where the rules are the product: case handling, eligibility, regulation-heavy calculations. We choose deliberately between a modular monolith and microservices, and most often start with the first.

    What we do

    • Event storming with domain experts
    • Bounded contexts and module boundaries
    • Rules made explicit and testable
    • Architecture decision records for the big choices

    What you receive

    • Domain model and context map
    • Modular codebase with enforced boundaries
    • Executable specifications for key rules

  3. 03 Citizen and employee portals

    Interfaces built on a design system, accessible by default and multilingual from the first release. In Belgium that means three official languages; elsewhere it means the languages your users actually speak.

    What we do

    • Design system with accessible components
    • Content design in plain language
    • Assistive-technology testing with real users
    • Localisation workflow for every language

    What you receive

    • Portal on a reusable design system
    • Accessibility conformance report
    • Content and translation workflow

  4. 04 Quality engineering and secure development

    Test automation at the right levels, contract tests between services, performance tests before launch, and a secure development lifecycle built on OWASP ASVS, SBOMs and supply-chain controls.

    What we do

    • Test strategy and automation
    • Contract and performance testing
    • Threat modelling and ASVS verification
    • SBOM generation and dependency policy

    What you receive

    • Automated test suites in the pipeline
    • Security verification report
    • Vulnerability handling process ready for the Cyber Resilience Act

  5. 05 Incremental modernisation

    Replace a legacy application one capability at a time, behind a routing facade, while the business keeps running. See also legacy modernisation.

    What we do

    • Capability map of the existing application
    • Strangler-fig routing and API wrapping
    • Data migration with reconciliation reports
    • Parallel runs for critical calculations

    What you receive

    • Modernisation sequence with business milestones
    • Facade and new modules in production
    • Reconciled data at each cut-over

  6. 06 Maintainability and handover

    Software your teams can own: readable code, decision records, runbooks and a handover plan agreed at the start, not discovered at the end.

    What we do

    • Pairing with your developers during the build
    • Architecture decision records kept with the code
    • Operational runbooks and on-call guides
    • Knowledge transfer milestones

    What you receive

    • Handover plan with acceptance criteria
    • Documentation set in your repositories
    • Trained in-house team

03 Architecture

An illustrative reference architecture

A typical shape for a business application that replaces an older one: an accessible front end, a routing facade that sends each capability to the old or the new system, an API layer with clear contracts, and a modular core organised around the domain.

Tenancy and configuration are explicit platform services, not conditions scattered through the code. Underneath, every build runs tests, security checks and produces an SBOM.

Layers in the drawing

People
Citizens, customers and employees, on any device and with assistive technology.
Modernisation
The routing facade, the existing application and the data migration with reconciliation.
Platform
API layer, identity, the modular core, tenancy and configuration, operational data.
Secure delivery
Contract and performance tests, ASVS checks and an SBOM in every build.
Illustrative example

  1. People

    • Citizens, customers, employees
    • Accessible front end

  2. Incremental modernisation

    • Routing facade
    • Existing application
    • Migration with reconciliation

  3. Platform

    • API layer and contracts
    • Identity and roles
    • Modular core: intake, cases, billing
    • Tenancy, configuration, feature flags
    • Operational data stores

  4. Secure delivery

    • Contract and performance tests, ASVS checks, SBOM in every build
Modular core behind a routing facade

Illustrative architecture, not a client system.

Read the diagram as text

The main route runs from people to an accessible front end, through a routing facade and an API layer, to a modular core organised in bounded contexts.

The facade also routes some capabilities to the existing application, which is retired step by step. Its data moves through a migration with reconciliation into the operational data stores.

Identity serves the API layer. Tenancy and configuration services sit under the core. A secure delivery band underneath covers contract tests, performance tests, security verification and SBOMs.

04 Considerations and limits

Engineering considerations and limits

  • Modular monolith first

    How we handle it

    We start with clear modules in one deployable unit and split out services only where scaling, release cadence or team ownership demand it.

    Limits and dependencies

    Microservices solve organisational problems as much as technical ones. Without teams to own them, they add cost and failure modes.

  • Accessibility is engineering work

    How we handle it

    Accessible components, automated checks in the pipeline and manual testing with assistive technology before each major release.

    Limits and dependencies

    Automated tools find only part of the issues. Full conformance needs manual audits and, ideally, testing with users with disabilities.

    Content and documents added by editors after launch must meet the same standard. We train editors, but we do not control what they publish.

  • Modernisation takes as long as the data

    How we handle it

    Data migration is planned per capability, rehearsed and reconciled, with business sign-off at every cut-over.

    Limits and dependencies

    The quality of legacy data often sets the pace. Cleaning it is a business task as much as a technical one.

  • Regulation for software products

    How we handle it

    SBOMs, vulnerability handling and secure defaults are part of our standard pipeline, which prepares products for the Cyber Resilience Act.

    Limits and dependencies

    Whether and how the Act applies to your product is a legal question. We provide the engineering evidence; your counsel makes the assessment.

05 How we work

How we work

Short cycles, real users early, and the handover planned from the first week.

  1. 01

    Map the domain

    Event storming with the people who know the rules, and a capability map of what exists today.

    OutputContext map and first decision records

  2. 02

    Ship a thin slice

    One capability end to end, through the facade, into production with real users.

    OutputWorking slice in production

  3. 03

    Grow by capability

    Each release moves a capability, its data and its users, with reconciliation and rollback ready.

    OutputRelease plan by capability

  4. 04

    Hand over

    Your developers pair with ours, take over on-call, and own the roadmap when the handover criteria are met.

    OutputAccepted handover

06 Human control

Where people stay in control

In business software, control means knowing who changed what, who approved it and how to undo it.

  • Product owners decide scope

    Your product owner sets priorities and accepts each increment. We advise, they decide.

  • Configuration has an owner

    Tenant settings and feature flags are changed through an audited process, by roles you assign.

  • Cut-overs are approved

    Every move from old to new system is signed off by the business, with a rehearsed rollback.

  • Decisions are written down

    Architecture decision records show what was chosen, by whom and why, so future teams can revisit them knowingly.

07 Technologies

Technologies we work with

Back end
  • Java and Kotlin
  • .NET
  • TypeScript and Node.js
  • Python
Front end
  • React and Next.js
  • Angular
  • Design systems with accessible components
  • Native and cross-platform mobile
Data
  • PostgreSQL
  • SQL Server and Oracle (existing estates)
  • Event streaming
  • Search engines
Quality and security
  • Playwright and contract testing
  • Load and performance testing
  • SAST, DAST and dependency scanning
  • SBOM in CycloneDX or SPDX

Listing a technology describes our engineering experience. It does not imply a partnership with or endorsement by its vendor.

08 Example

An illustrative example

Illustrative example

A customer portal rolled out in several countries and languages

01Situation
A company with operations in four EU countries runs four portals built by four suppliers. Each fails accessibility checks differently, and every change is made four times.
02What we would build
One portal on a shared design system, with country-specific content, languages and integrations held in configuration and one release train.
03Where people decide
Country teams approve content and configuration for their market; the product owner decides on shared features.
04What we would measure
Accessibility issues per release, lead time for a change across all countries, and share of changes made once instead of per country.

09 Sector lens

In your sector

  • Public Sector & Government

    Case management and citizen portals that meet accessibility law, work in every official language and connect to national data exchanges.

  • Financial Services

    Customer portals and back-office applications with strong audit trails and release processes that satisfy change control.

  • Manufacturing & Industry

    Configurators, service portals and SaaS products for equipment makers, connected to ERP and field service.

International

A new market is a release, not a fork

A product sold across the EU meets the European Accessibility Act through national laws that differ in detail, and the Cyber Resilience Act through one regulation with obligations that start in stages. Customers in each country also expect their own language, their own invoicing rules and their own identity schemes.

We keep these differences in configuration and in clearly bounded modules, so a new market is a release rather than a fork. Accessibility evidence and security documentation are produced by the pipeline, ready for the procurement questions each market asks.

Questions about enterprise software and SaaS

Should we build custom or configure a platform?

Configure a platform where your process is close to standard, and build where the process is what sets you apart or where no platform fits the rules. We work with Salesforce, SAP and Odoo as well as custom code, so we have no reason to push one answer. Our Architecture & Consulting service makes this choice explicit.

Can you guarantee our portal is accessible?

We build to EN 301 549 and WCAG 2.2 AA, test automatically and manually, and deliver a conformance report with any known issues. We do not promise zero issues; we promise to find them, report them and fix what is in our scope.

Can you modernise without a big-bang migration?

Yes, and we recommend it. A routing facade lets us move one capability at a time while the existing application keeps running, with data reconciled at each step.

Can our own team take over the software?

That is the default plan. Handover criteria are agreed at the start, your developers pair with ours during the build, and decision records and runbooks live in your repositories.

What does the Cyber Resilience Act mean for our product?

If you place software with digital elements on the EU market, it may bring obligations on secure design, vulnerability handling and documentation. We build the engineering evidence: SBOMs, a vulnerability process and secure defaults.

Tell us what has to keep running while it changes

We will propose the first capability to move and what your team would own at the end.

Discuss your projectSee legacy modernisation