Skip to main content
FromNine
Menu

Engineering

Enterprise software your team can still change years from now.

We build SaaS products, portals for residents and staff, and core business applications. They are accessible, secure from the start and built so your own developers can maintain them long after go-live.

For Irish software companies building SaaS, and for public bodies whose portals must meet Irish accessibility rules and language duties.

Talk to us about your projectExplore legacy modernisation
Enterprise Software & SaaS: the layersFour layers, one behind the other. First the accessible interface people use, then the domain modules where the rules live, then platform services for tenancy and identity, and last the secure delivery pipeline that underpins it all.01Interfaces everyone can use02Domain modules and their rules03Identity, tenancy, data04Secure build and release
  1. 01Domain-driven design for work full of rules, such as case handling
  2. 02Built to WCAG 2.2 AA and EN 301 549, starting with the first design
  3. 03Decision records and documentation your team can take over

01 Problems

What people tell us before a rebuild

  1. 01

    Each change takes three months

    The application does its job, but nobody dares to touch the core. Even small changes need heavy regression testing and a release window.

  2. 02

    The portal lets down the people it is for

    It fails with a screen reader, does not work properly in Irish and is awkward on a phone. Complaints come in before the accessibility audit does.

  3. 03

    A change for one customer breaks another

    The SaaS product grew through customer-specific tweaks. Each release is now a negotiation, and a few tenants cannot move off old versions.

  4. 04

    The know-how left with the supplier

    Nobody wrote the decisions down. The original team has moved on, and the code is all the documentation there is.

  5. 05

    Customers and regulators start asking security questions

    A request for tender asks for an SBOM, a vulnerability process and evidence for the Cyber Resilience Act, and none of it is ready.

02 Delivery ledger

What you get from us

  1. 01 Engineering SaaS products

    Products that serve many customers from a single codebase: a tenancy model that suits, configuration rather than customisation, and releases that reach every tenant.

    What we do

    • Choosing how tenants are separated: shared, pooled or fully isolated
    • A strategy for configuration and feature flags
    • Integration with metering and billing
    • Release trains that roll out tenant by tenant

    What you receive

    • Design for tenancy and isolation
    • A configuration model with guardrails
    • A release process that can roll back per tenant

  2. 02 Domain design where the rules are complex

    When the rules are what the product is about (case handling, eligibility, calculations set by regulation), we use domain-driven design. The choice between a modular monolith and microservices is deliberate, and the monolith usually comes first.

    What we do

    • Event storming sessions with your domain experts
    • Bounded contexts and the boundaries between modules
    • Rules written out explicitly and tested
    • Decision records for the major architectural choices

    What you receive

    • A domain model and context map
    • A modular codebase that enforces its boundaries
    • Executable specifications for the key rules

  3. 03 Portals for residents and staff

    Interfaces built on a design system, accessible as standard and ready for more than one language at the first release. Public bodies in Ireland have Irish-language duties under the Official Languages Act, so their portals publish in Irish and English; for companies, it means the languages your customers actually use.

    What we do

    • A design system with accessible components
    • Content written in plain language
    • Testing with assistive technology and real users
    • A localisation workflow that covers every language, Irish included

    What you receive

    • A portal on a design system you can reuse
    • An accessibility conformance report
    • A workflow for content and translation

  4. 04 Quality engineering and secure development

    Automated tests at the levels that matter, contract tests between services, performance testing before launch, and secure development practice grounded in OWASP ASVS, with SBOMs and controls on the software supply chain.

    What we do

    • A test strategy and its automation
    • Contract tests and performance tests
    • Threat modelling and verification against ASVS
    • Generating SBOMs and setting a dependency policy

    What you receive

    • Automated test suites inside the pipeline
    • A report on security verification
    • A process for handling vulnerabilities, in line with what the Cyber Resilience Act expects

  5. 05 Modernising step by step

    Swap out a legacy application one capability at a time, behind a routing facade, while day-to-day business continues. See also modernising legacy systems.

    What we do

    • A map of the capabilities in the current application
    • Strangler-fig routing and wrapping with APIs
    • Data migration backed by reconciliation reports
    • Running old and new side by side for critical calculations

    What you receive

    • A modernisation sequence tied to business milestones
    • The facade and new modules running in production
    • Reconciled data at every cut-over

  6. 06 Built to be handed over

    Software your team can own: readable code, decision records, runbooks, and a handover plan agreed on day one rather than discovered at the end.

    What we do

    • Your developers pair with ours during the build
    • Decision records stored with the code
    • Runbooks for operations and on-call guides
    • Milestones for knowledge transfer

    What you receive

    • A handover plan with acceptance criteria
    • Documentation in your own repositories
    • An in-house team trained to take over

03 Architecture

Reference architecture, for illustration

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

Tenancy and configuration are platform services in their own right, rather than if-statements spread across the codebase. Underneath, every build runs the tests and security checks and produces an SBOM.

Layers in the drawing

People
Residents, customers and staff, on any device and with assistive technology.
Modernisation
The routing facade, the current application and a data migration that is reconciled at each step.
Platform
API layer, identity, the modular core, tenancy and configuration, and operational data.
Secure delivery
Every build runs contract and performance tests and ASVS checks, and produces an SBOM.
Illustrative example

  1. People

    • Residents, customers, staff
    • Accessible front end

  2. Step-by-step modernisation

    • Routing facade
    • Current application
    • Reconciled data migration

  3. Platform

    • API layer with contracts
    • Roles and identity
    • Modular core: intake, cases, billing
    • Feature flags, configuration, tenancy
    • Operational data stores

  4. Secure delivery

    • Each build: contract and performance tests, ASVS checks and an SBOM
Routing facade in front of a modular core

An illustration, not a client’s system.

Read the diagram as text

The main route leads from people to an accessible front end, through a routing facade and an API layer, and into a modular core split into bounded contexts.

The facade sends some capabilities to the existing application, which is retired in stages. Its data passes through a reconciled migration into the operational data stores.

Identity serves the API layer, and tenancy and configuration services sit below the core. Along the bottom, a secure delivery band covers contract and performance tests, security verification and SBOMs.

04 Considerations and limits

What to weigh up, and where the limits are

  • Start with a modular monolith

    How we handle it

    We begin with well-defined modules in a single deployable unit, and split off services only where scale, release rhythm or team ownership call for it.

    Limits and dependencies

    Microservices answer organisational problems as much as technical ones. Without teams to own them, they bring extra cost and new ways to fail.

  • Accessibility is engineering work

    How we handle it

    We use components that are accessible by design, run automated checks on every build, and test by hand with screen readers and other assistive technology ahead of each major release.

    Limits and dependencies

    Automated tools catch only some of the problems. Full conformance takes manual audits and, ideally, testing with people with disabilities.

    Pages and documents that editors add after launch must meet the same bar. We train editors, but what they publish is up to them.

  • Modernisation moves at the speed of the data

    How we handle it

    Data migration is planned capability by capability, rehearsed and reconciled, and the business signs off each cut-over.

    Limits and dependencies

    The state of legacy data often sets the pace, and cleaning it up is as much a business job as a technical one.

  • Regulation of software products

    How we handle it

    SBOMs, vulnerability handling and secure defaults are standard in our pipeline, which gets products ready for the Cyber Resilience Act.

    Limits and dependencies

    Whether the Act applies to your product, and how, is a legal question. We supply the engineering evidence; your legal advisers make the assessment.

05 How we work

How we work

Short cycles, real users from early on, and handover planned in week one.

  1. 01

    Map the domain

    Event storming with the people who know the rules, plus a map of the capabilities that exist today.

    OutputContext map and the first decision records

  2. 02

    Deliver a thin slice

    One capability from end to end, through the facade and live in production for real users.

    OutputA working slice in production

  3. 03

    Grow capability by capability

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

    OutputA release plan by capability

  4. 04

    Hand over

    Your developers work in pairs with ours, take over on-call duty, and own the roadmap once the agreed handover criteria are satisfied.

    OutputHandover accepted

06 Human control

Where your people keep control

In business software, control means you can see who changed what and who approved it, and you know how to reverse it.

  • Product owners set scope

    Your product owner decides priorities and accepts each increment. We give advice; the decision is theirs.

  • Every setting has an owner

    Roles you assign change tenant settings and feature flags, through a process that is audited.

  • Cut-overs need approval

    The business signs off every move from the old system to the new, and a rollback has been rehearsed.

  • Decisions are recorded

    Each architecture decision is recorded with what was chosen, who chose it and the reasons, so later teams can revisit it with their eyes open.

07 Technologies

Technology we use

Back end
  • Java and Kotlin
  • .NET
  • TypeScript and Node.js
  • Python
Front end
  • React and Next.js
  • Angular
  • Accessible design-system components
  • Mobile apps, native and cross-platform
Data
  • PostgreSQL
  • SQL Server and Oracle in existing estates
  • Event streaming
  • Search engines
Quality and security
  • Playwright, contract tests
  • Load and performance tests
  • SAST, DAST, dependency scanning
  • SBOMs as CycloneDX or SPDX

A technology on this list reflects our engineering experience with it, not a partnership with its vendor or an endorsement by them.

08 Example

An example, for illustration

Illustrative example

A resident portal for a county council, in Irish and English

01The situation
A county council runs separate online forms for housing, planning queries and local services, built at different times by different suppliers. Each fails accessibility checks in its own way, the Irish versions lag behind the English ones, and residents set up a new account for every service.
02What we would put in place
One portal on a shared design system, with MyGovID for login, Irish and English content managed in a single workflow, and links to the council’s case systems held in configuration on one release train.
03Where staff decide
Service owners in each section approve content and configuration for their area; the product owner decides on shared features and the order of releases.
04How we would judge it
Accessibility issues per release, how long the Irish version of a page trails the English one, and lead time for a change across all services.

09 Sector lens

By sector

  • Public Service & Government

    Case management and resident portals for Government departments, State agencies and local authorities that meet S.I. No. 358 of 2020 on public-sector web accessibility, publish in Irish and English and can use MyGovID for login.

  • Financial Services

    Broker and customer portals for insurers and banks, and back-office applications with strong audit trails and release processes that pass change control.

  • Manufacturing & Industry

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

Ireland

Irish rules for software, handled in the pipeline

In Ireland, products and services within the scope of the European Accessibility Act are covered by S.I. No. 636 of 2023, which has applied since 28 June 2025 and is enforced by the CCPC, with ComReg and Coimisiún na Meán covering their own services. Public bodies are also bound by S.I. No. 358 of 2020 on the accessibility of their websites and apps, monitored by the National Disability Authority, and by Irish-language duties under the Official Languages Act.

The Cyber Resilience Act adds EU-wide obligations in stages, with the main ones from 11 December 2027. We hold these requirements in configuration and clearly bounded modules, so serving Irish public bodies, or adding another EU market, means a new release and not a separate copy of the code. The pipeline produces accessibility evidence and security documentation, ready for the questions in a request for tender on eTenders.

Questions we hear about enterprise software and SaaS

Should we build our own or configure a platform?

Where your process is fairly standard, configuring a platform makes sense. Build your own where the process is what makes you different, or where no platform can handle the rules. Because we work with SAP, Salesforce and Odoo as well as custom code, we gain nothing by pushing one answer. Our architecture and consulting service puts this choice on the table explicitly.

Can you guarantee that our portal will be accessible?

We build to WCAG 2.2 AA and EN 301 549, test with tools and by hand, and hand over a conformance report that lists any known issues, useful evidence for public bodies covered by S.I. No. 358 of 2020. Nobody can honestly promise a portal with no issues at all. What we commit to is finding them, reporting them and fixing the ones within our scope.

Is modernisation possible without one big cut-over?

Yes, and we advise it. With a routing facade we move a single capability at a time while the current application keeps running, and reconcile the data at every step.

Can our own developers take over the software?

That is the plan from the start. We agree handover criteria at the outset, your developers work in pairs with ours during the build, and the decision records and runbooks sit in your repositories.

What will the Cyber Resilience Act mean for our product?

If your product counts as a product with digital elements sold in the EU, the Act may bring obligations around secure design, vulnerability handling and documentation, with the main ones applying from 11 December 2027. On the engineering side we deliver the evidence: secure defaults, an SBOM for every build and a process for handling vulnerabilities.

What has to keep running while you change it?

Tell us, and we will suggest where to start and what your team will own once we step back.

Talk to us about your projectExplore legacy modernisation