Skip to main content
FromNine
Menu

Engineering

Custom software your own developers can keep changing.

We build SaaS products, portals for residents and staff, and the core applications a business depends on. They are accessible, secure from the outset, and designed so that your own developers can maintain them for years after go-live.

For public entities that serve residents online and Maltese software companies that sell their products across the EU.

Start a conversationExplore legacy modernisation
Enterprise Software & SaaS: the layers we buildFour layers shown one behind the other. Top to bottom: the accessible screens people work with, the domain modules where the rules live, platform services for identity and tenancy, and beneath them a secure pipeline for delivery.01Screens everyone can use02Rules in domain modules03Identity, tenancy and data04Secure delivery pipeline
  1. 01Domain-driven design for work full of rules, such as case files and permits
  2. 02Accessibility to WCAG 2.2 AA and EN 301 549 from the first screen designs
  3. 03Decision records and documentation that let your developers take over

01 Common problems

What organisations tell us before a rebuild

  1. 01

    A small change takes three months

    The system runs, yet no one wants to touch its core. Minor changes call for heavy regression testing and a fixed release window.

  2. 02

    The portal lets its users down

    It cannot be used with a screen reader, on a phone or in Maltese as well as English. Complaints come in before any accessibility audit is done.

  3. 03

    A change for one client breaks another

    The SaaS product grew through client-specific customisation. Every release has become a negotiation, and some tenants are stuck on outdated versions.

  4. 04

    The know-how left with the previous supplier

    No one recorded the decisions. The original team has gone, and the code is the only documentation left.

  5. 05

    Clients and regulators ask security questions

    A call for tenders asks for an SBOM, a process for vulnerabilities and evidence for the Cyber Resilience Act. None of it is ready.

02 Delivery scope

Our delivery scope

  1. 01 Engineering SaaS products

    Products that serve many clients from a single codebase: a suitable tenancy model, configuration in place of customisation, and every release reaching every tenant.

    Our work

    • Choosing the tenancy model: shared, pooled or isolated for each tenant
    • A strategy for configuration and feature flags
    • Integration with metering and billing
    • Release trains that roll out with each tenant in mind

    What you get

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

  2. 02 Domain design where rules are complex

    Domain-driven design for cases where the rules are the product: case files, eligibility, calculations driven by regulation. We weigh a modular monolith against microservices with care, and we usually begin with the monolith.

    Our work

    • Event storming sessions with subject experts
    • Bounded contexts and the edges of each module
    • Rules written down explicitly and made testable
    • Architecture decision records for the major choices

    What you get

    • A domain model and a context map
    • A modular codebase whose boundaries are enforced
    • Executable specifications for the main rules

  3. 03 Portals for residents, clients and staff

    Screens built on a design system, accessible by default and ready for more than one language from the first release. For a Maltese public entity that usually means Maltese and English, the two official languages, with sign-in through Malta e-ID where the service calls for it.

    Our work

    • A design system made of accessible components
    • Content written in plain language
    • Tests with real users of assistive technology
    • A localisation workflow covering each language

    What you get

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

  4. 04 Quality engineering and secure development

    Automated tests at the levels where they pay off, contract tests between services, load tests before launch, and a secure development lifecycle based on OWASP ASVS, SBOMs and controls on the supply chain.

    Our work

    • A test strategy and its automation
    • Contract tests and performance tests
    • Threat modelling and verification against ASVS
    • SBOM generation and a policy for dependencies

    What you get

    • Automated test suites running in the pipeline
    • A report on security verification
    • A process for vulnerabilities that is ready for the Cyber Resilience Act

  5. 05 Modernising step by step

    An older application is replaced capability by capability behind a routing facade, and the organisation keeps working throughout. More on this under legacy modernisation.

    Our work

    • A capability map of the current application
    • Strangler-fig routing and wrapping in APIs
    • Data migration backed by reconciliation reports
    • Parallel running for critical calculations

    What you get

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

  6. 06 Handover and long-term maintenance

    Software your developers can own: code that reads easily, decision records, runbooks, and a handover plan agreed at the outset rather than improvised at the end.

    Our work

    • Our developers pairing with yours while we build
    • Architecture decision records stored with the code
    • Runbooks and guides for on-call duty
    • Milestones for transferring knowledge

    What you get

    • A handover plan with acceptance criteria
    • Documentation kept in your own repositories
    • An in-house team trained to carry on

03 Architecture

A reference architecture, shown for illustration

When a business application takes over from an older one, it usually has this form: a front end everyone can use, a routing facade that sends each capability to the old or the new system, an API layer with clear contracts, and a modular core built around the domain.

Tenancy and configuration are separate platform services rather than conditions spread across the code. Beneath it all, every build runs the tests and security checks and generates an SBOM.

Layers shown in the diagram

Users
Residents, clients and staff, on any device and with any assistive technology.
Modernisation
The facade that routes requests, the current application and the reconciled data migration.
Platform
API layer, identity, the modular core, tenancy and settings, and operational data.
Secure delivery
Contract and load tests, ASVS checks and an SBOM with each build.
Illustrative example

  1. Users

    • Residents, clients and staff
    • Front end everyone can use

  2. Step-by-step modernisation

    • Facade that routes requests
    • Current application
    • Reconciled data migration

  3. Platform

    • API layer with contracts
    • Identity, roles and e-ID
    • Modular core: intake, case files, billing
    • Tenancy, settings and feature flags
    • Operational data stores

  4. Secure delivery

    • Each build runs contract and load tests and ASVS checks and produces an SBOM
A modular core behind a routing facade

Shown for illustration only; this is not a client system.

Read the diagram as text

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

The facade sends some capabilities to the current application, which is switched off in stages. Its data moves through a migration with reconciliation into the operational data stores.

Identity supports the API layer. Services for tenancy and configuration sit beneath the core. A band for secure delivery at the bottom covers contract tests, load tests, security verification and SBOMs.

04 Choices and limits

Engineering choices and their limits

  • A modular monolith comes first

    Our approach

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

    Limits and what we rely on

    Microservices address organisational questions as much as technical ones. If no team owns them, they bring extra cost and more ways to fail.

  • Accessibility is an engineering task

    Our approach

    We use accessible components, run automated checks in the pipeline and test manually with assistive technology ahead of every major release.

    Limits and what we rely on

    Automated checks catch only some of the problems. Full conformance requires manual audits and, at best, tests with users who have disabilities.

    Pages and documents that editors publish after launch must meet the same bar. We train the editors, but what they publish is outside our control.

  • Data sets the pace of modernisation

    Our approach

    We plan the data migration for each capability, rehearse and reconcile it, and ask the business to approve every cut-over.

    Limits and what we rely on

    How clean the old data is often decides the timeline. Cleaning it is as much work for the business as for the engineers.

  • Rules for software products

    Our approach

    Our standard pipeline includes SBOMs, vulnerability handling and secure defaults, which prepares a product for the Cyber Resilience Act.

    Limits and what we rely on

    Whether the Act applies to your product, and how, is a legal matter. We supply the engineering evidence and your legal advisers form the view.

05 Our method

Our method

Short cycles, real users involved early, and a handover planned from week one.

  1. 01

    Chart the domain

    Event storming with the staff who know the rules, plus a capability map of the systems in place today.

    ResultA context map and the first decision records

  2. 02

    Deliver a thin slice

    A single capability built end to end, routed through the facade and live with real users.

    ResultA working slice in production

  3. 03

    Expand capability by capability

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

    ResultA release plan organised by capability

  4. 04

    Hand over to your team

    Your developers pair with ours, take on call duty and own the roadmap once the handover criteria are met.

    ResultA handover you have accepted

06 People in control

Where people keep the decision

With business software, control means knowing who changed something, who approved the change and how to reverse it.

  • Product owners set the scope

    Your product owner sets the priorities and accepts every 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.

  • Each cut-over is approved

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

  • Decisions are on record

    Architecture decision records state what was chosen, by whom and for what reason, so later teams can revisit them with full knowledge.

07 Technologies

Technologies in our toolset

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

We list a technology because our engineers have worked with it. The list does not mean that its vendor partners with or endorses FromNine.

08 Illustrative case

An illustrative case

Illustrative example

An online permit application for a public entity

01Starting point
A public entity accepts permit applications on paper and by email. Applicants send the same documents more than once, officers retype the data into a case system, and the existing web form fails basic accessibility checks.
02The system we would put in place
An accessible application portal with sign-in through Malta e-ID, listed alongside other online services on servizz.gov, feeding a modular case system that tracks each application from submission to decision.
03Where staff decide
Officers of the entity decide every application. The entity’s content owners approve forms, guidance texts and both language versions before release.
04How we would judge success
Accessibility issues found per release, days from complete application to decision, and the share of applications submitted online.

09 By sector

Sector by sector

  • Government & Public Entities

    Case management and portals for ministries, public entities and local councils that meet S.L. 418.03 on public-sector websites, serve users in Maltese and English, and connect to Malta e-ID and servizz.gov.

  • Financial Services

    Client portals and back-office systems for licence holders, with solid audit trails and a release process that stands up to change control.

  • Manufacturing & Industry

    Configurators, service portals and SaaS products for manufacturers and equipment suppliers, linked to the ERP and to field service.

Malta

Maltese accessibility rules, one release train

A portal or product used in Malta meets accessibility law on two fronts. Public-sector websites and apps fall under S.L. 418.03, which transposes the Web Accessibility Directive, and products and services in scope of the European Accessibility Act fall under S.L. 627.03, where the Commission for the Rights of Persons with Disability (CRPD) is the market surveillance authority and microenterprises providing services are exempt. The Cyber Resilience Act adds obligations for software products in stages, and public services increasingly expect sign-in through Malta e-ID.

We hold these Maltese and EU requirements in configuration and in clearly bounded modules, so entering another EU market means shipping a release, not maintaining a second codebase. The pipeline produces the accessibility evidence and security documentation that a call for tenders on ePPS tends to ask for.

Common questions on enterprise software and SaaS

Is it better to build bespoke software or configure a platform?

Configure a platform when your process is close to the standard, and build when the process itself is what makes you different or when no platform can carry the rules. We deliver on Odoo, SAP and Salesforce as well as in custom code, so we gain nothing by pushing one option. Our Architecture & Consulting service sets out this choice openly.

Will you guarantee that our portal is accessible?

We build to WCAG 2.2 AA and EN 301 549, test both automatically and by hand, and hand over a conformance report listing any known issues. We cannot promise there will be none; we promise to find them, report them and fix those within our scope. Whether S.L. 418.03 or S.L. 627.03 covers your service is for your legal advisers to confirm.

Can the old system be replaced without one big switch-over?

It can, and that is what we advise. With a routing facade we move one capability at a time while the current application stays in use, and we reconcile the data after each move.

Will our own developers be able to take over?

That is the plan we start from. We agree the handover criteria at the beginning, your developers pair with ours while we build, and the decision records and runbooks are kept in your repositories.

How does the Cyber Resilience Act affect our product?

A Maltese software company that sells a product with digital elements on the EU market may take on duties for secure design, vulnerability handling and documentation. We produce the engineering evidence: SBOMs, a vulnerability process and secure defaults.

Tell us which system must keep running while it changes

We will suggest the first capability to move and describe what your team would own once we are done.

Start a conversationExplore legacy modernisation