Skip to main content
FromNine
Menu

Engineering

Business software your developers can keep improving themselves.

We engineer SaaS products, portals for the public and for staff, and core business applications. They are accessible, secure from the first release and documented well enough that your own team can carry them forward once we step back.

For Malaysian product companies and organisations whose users need more than one language, and whose customers may sit in the EU.

Arrange a discussionLegacy modernisation
Enterprise Software & SaaS: the four layersFour layers, read downwards: the accessible screens people use, the domain modules where business rules live, shared platform services for tenants, identity and data, and a secured delivery pipeline at the base.01Screens anyone can use02Modules that hold the rules03Tenants, identity and data04Secured delivery pipeline
  1. 01Domain-driven design for rule-dense work such as case handling and eligibility
  2. 02WCAG 2.2 level AA from the first wireframe, and EN 301 549 for products sold in the EU
  3. 03Decision records and runbooks written for the team that inherits the code

01 Common problems

What we hear just before a rebuild

  1. 01

    A minor change needs three months

    The system runs, but no one wants to touch its core. Each small change triggers a large regression cycle and waits for a release slot.

  2. 02

    The portal shuts out some of its users

    Screen readers cannot use it, it shows only one of the languages its users need, and it breaks on a phone. Complaints come in long before any accessibility review.

  3. 03

    A fix for one client breaks another

    The SaaS product grew through client-specific customisation. Every release now needs negotiation, and some tenants remain on outdated versions.

  4. 04

    What the supplier knew, it took away

    Nobody recorded the design decisions. The original developers have left, and only the source code explains the system.

  5. 05

    Customers and regulators ask security questions you cannot answer

    Buyers want a software bill of materials, a vulnerability process and, for EU customers, evidence for the Cyber Resilience Act. None of it is ready.

02 Scope of the service

What the service covers

  1. 01 Engineering SaaS products

    One codebase serving many customers: a tenancy model that suits your risk, configuration in place of client-specific code, and releases that reach every tenant at the same pace.

    Activities

    • Deciding between shared, pooled or isolated tenancy
    • Rules for when a setting or feature flag replaces custom code
    • Usage metering linked to billing
    • Tenant-aware release trains and staged rollout

    What you would receive

    • A design for tenancy and isolation
    • A configuration model with built-in limits
    • Releases that can be reversed for one tenant alone

  2. 02 Designing for complex business rules

    Where the rules are the product, as in case handling, eligibility or calculations driven by regulation, we apply domain-driven design. We choose between a modular monolith and microservices on purpose, and usually begin with the monolith.

    Activities

    • Event storming with the specialists who apply the rules
    • Bounded contexts and firm module boundaries
    • Business rules written so they can be read and tested
    • Decision records for the major architecture choices

    What you would receive

    • Domain model alongside its context map
    • Codebase in modules, with boundaries the build checks
    • Executable specifications for the critical rules

  3. 03 Portals for the public, customers and staff

    Screens built from a design system, accessible from the start and ready for more than one language. In Malaysia that often means Malay and English, with a privacy notice in both, as section 7(3) of the Personal Data Protection Act 2010 (Act 709) requires of data controllers. Public-facing services can offer login with MyDigital ID, the national digital identity.

    Activities

    • Component library designed for accessibility from day one
    • Plain-language content design
    • Sessions with people who rely on screen readers and other aids
    • A translation workflow covering every language the portal offers

    What you would receive

    • Portal assembled from reusable design-system parts
    • An accessibility conformance report
    • A content and translation workflow

  4. 04 Quality engineering and secure development

    Tests automated at unit, service and journey level, contracts checked between services, and load tested before go-live. Secure development follows OWASP ASVS, with an SBOM per build and supply-chain controls.

    Activities

    • A test strategy and its automation
    • Contract tests and load tests
    • Threat modelling and verification against ASVS
    • SBOMs produced automatically, plus rules on third-party libraries

    What you would receive

    • Pipeline-run test suites covering each release
    • A security verification report
    • A vulnerability handling process that also serves EU Cyber Resilience Act needs

  5. 05 Modernisation in stages

    An ageing application is replaced one capability after another, behind a routing layer, while daily operations continue. The legacy modernisation page explains the approach in more depth.

    Activities

    • Inventory of what the current application does
    • Strangler-fig routing, with old functions wrapped as APIs
    • Data migration backed by reconciliation reports
    • Parallel runs for calculations that must not change

    What you would receive

    • Order of migration linked to business milestones
    • The routing layer and new modules in production
    • Reconciled data at every switch-over

  6. 06 Maintainable code and a planned handover

    Software your own team can take ownership of: clear code, recorded decisions, runbooks and a handover plan agreed in the first weeks rather than improvised at the end.

    Activities

    • Your developers paired with ours throughout the build
    • Decision records kept in the repository
    • On-call guides and operating runbooks
    • Milestones for knowledge transfer

    What you would receive

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

03 Architecture

A reference architecture, for illustration

A common outline for a business application that takes over from an older one: accessible screens, a routing layer that sends each capability to either the old or the new system, an API layer with explicit contracts, and a modular core organised by business domain.

Tenancy and configuration exist as separate platform services instead of if-statements scattered through modules. Beneath them, every build tests, scans and emits an SBOM.

Layers shown

Users
The public, customers and staff, on phones or desktops, including users of assistive technology.
Modernisation
Routing layer, old application and the data migration that is reconciled at each step.
Platform
API layer and identity, the modular core, tenancy and settings, operational data.
Secured delivery
Every build runs contract and load tests and ASVS checks, then emits an SBOM.
Illustrative example

  1. Users

    • Public, customers and staff
    • Accessible screens

  2. Modernisation in stages

    • Routing layer
    • Current application
    • Reconciled migration

  3. Platform

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

  4. Secured delivery

    • Each build: contract and load tests, ASVS checks, SBOM
Routing layer in front of a modular core

For illustration only; this is not a system built for a client.

Read the diagram as text

Users reach accessible screens, which call a routing layer, an API layer and finally a modular core divided into bounded contexts.

Part of the traffic still goes from the routing layer to the current application, which is retired in stages. Data leaves that application through a migration with reconciliation and lands in the operational data stores.

The API layer relies on identity. Tenancy and configuration services lie under the core. A secured delivery band along the bottom covers contract and load testing, security verification and SBOMs.

04 Trade-offs and limits

Trade-offs we plan for

  • A modular monolith comes first

    What we do about it

    We begin with well-separated modules in one deployable unit, and split off a service only when load, release rhythm or team ownership calls for it.

    Limits and prerequisites

    Microservices answer questions about organisation as much as about technology. With no team to own each one, they mostly add cost and new ways to fail.

  • Accessibility is part of engineering

    What we do about it

    Components designed to be accessible, automated checks inside the pipeline, and a manual pass with screen readers and other aids before each major release.

    Limits and prerequisites

    Automated checkers find a share of the issues, not all. Conformance needs manual audits and, where possible, sessions with disabled users.

    Pages and files editors publish after launch must meet the same standard. We train the editors, but their later choices sit with them.

  • Data sets the pace of modernisation

    What we do about it

    Each capability’s data migration is planned, rehearsed and reconciled, and the business signs off every switch-over.

    Limits and prerequisites

    The condition of old data frequently dictates the schedule. Cleaning it is a task for the business as well as for IT.

  • Rules for software sold in the EU

    What we do about it

    Our standard pipeline produces SBOMs, handles vulnerabilities and applies secure defaults, which prepares a product for the EU Cyber Resilience Act if you sell it in the EU.

    Limits and prerequisites

    Whether the Act covers your product is a legal matter. We hand over the engineering evidence and your counsel makes the call.

05 Working method

Our working method

Short iterations, real users from the start and a handover plan in the first week.

  1. 01

    Understand the domain

    Event storming with the people who apply the rules each day, and an inventory of current capabilities.

    ResultContext map plus initial decision records

  2. 02

    Release a thin slice

    A single capability, end to end, routed through the new layer and used in production by real users.

    ResultA working slice in production

  3. 03

    Expand capability by capability

    With each release, one capability moves across together with its data and users, reconciliation and rollback ready.

    ResultRelease plan organised by capability

  4. 04

    Transfer ownership

    Your developers code alongside ours, assume on-call duty and take over the roadmap when the handover criteria are satisfied.

    ResultHandover accepted by your team

06 Human oversight

Where decisions stay with people

Control over business software means knowing who changed something, who approved it and how to reverse it.

  • The product owner sets the scope

    Your product owner decides the order of work and accepts each increment. Our role is advice; theirs is the decision.

  • Settings have an owner

    Tenant settings and feature flags change only through a logged process, carried out by roles you appoint.

  • Switch-overs need approval

    The business approves every move from old to new, and the rollback has been practised beforehand.

  • Reasons are recorded

    Decision records show the option chosen, who chose it and why, so later teams can revisit the choice with full knowledge.

07 Technology

Technology we use

Back end
  • Java and Kotlin
  • .NET
  • TypeScript and Node.js
  • Python
Front end
  • React and Next.js
  • Angular
  • Design systems built from accessible components
  • Native and cross-platform mobile apps
Data
  • PostgreSQL
  • SQL Server and Oracle where they already run
  • Event streaming
  • Search engines
Quality and security
  • Playwright and contract tests
  • Load and performance tests
  • SAST, DAST and scanning of dependencies
  • SBOMs in CycloneDX or SPDX format

These names reflect hands-on engineering work. Their inclusion does not mean that a vendor partners with or endorses FromNine.

08 Scenario

An illustrative scenario

Illustrative example

A Malaysian SaaS product prepared for EU customers

01Starting point
A Malaysian software company sells a workforce scheduling product locally and has signed its first customers in the EU. Its privacy notice, accessibility, security evidence and AI features were never designed with EU rules in mind.
02What we would deliver
One codebase with EU-specific settings for consent, data location and retention, an accessibility programme to WCAG 2.2 level AA, a pipeline that produces SBOMs and vulnerability records, and documentation for the AI-based shift suggestions.
03Decisions that stay with people
The product owner decides which features ship in each market; the company’s counsel decides which EU obligations apply.
04How results would be tracked
Accessibility issues per release, time to answer a customer’s security questionnaire, and share of changes released once for all markets.

09 By industry

By industry

  • Public Sector & Government

    Case management systems and public portals for federal agencies, statutory bodies and local authorities, with MyDigital ID login, Malay and English screens and WCAG 2.2 level AA as the design target.

  • Financial Services

    Customer portals and back-office systems for banks, insurers and takaful operators, with detailed audit trails and release processes that pass change control.

  • Manufacturing & Industry

    Product configurators, service portals and SaaS offerings for equipment makers, linked to ERP and to field service.

Malaysia

Malaysian users and EU customers in one product

At home, the data controller behind a product that processes personal data in commercial transactions must give a written notice under the Personal Data Protection Act 2010 (Act 709), and section 7(3) requires that notice in the national and English languages. Public-facing services can also offer login with MyDigital ID, the national digital identity.

Selling the same product in the EU adds the European Accessibility Act for certain consumer services, the Cyber Resilience Act for products with digital elements, with obligations starting in stages, and the EU General Data Protection Regulation (GDPR). We keep these requirements in configuration and well-bounded modules, so a new market becomes a release, not a separate codebase.

Questions on enterprise software and SaaS

Custom code or a configured platform: which suits us?

Configure a platform when your process is close to the standard, and build when the process is what distinguishes you or when no platform fits the rules. Because we deliver on SAP, Odoo and Salesforce as well as in custom code, we have no reason to push either answer. Our Architecture & Consulting service makes the choice explicit.

Will our portal be fully accessible?

We build to WCAG 2.2 level AA, and to EN 301 549 where a product serves EU users. We test with tools and by hand, and hand over a conformance report listing any known issues. We do not promise that no issue exists; we promise to look for issues, report them and fix those within our scope.

Is modernisation possible without a single big switch-over?

Yes, and that is the route we advise. A routing layer lets us move capabilities one at a time while the current application keeps serving users, with the data reconciled at each step.

Can our developers take ownership of the software?

That is the plan from the outset. Handover criteria are agreed at the beginning, your developers work alongside ours during the build, and the decision records and runbooks sit in your own repositories.

We sell our SaaS product to EU customers. What applies?

Several EU rules can reach a Malaysian product company. The EU General Data Protection Regulation (GDPR) applies when you offer goods or services to people in the EU, the EU AI Act when AI output is used in the EU, the European Accessibility Act for certain consumer services, and the Cyber Resilience Act for products with digital elements placed on the EU market. We produce the engineering evidence: SBOMs, a vulnerability process, secure defaults and accessibility reports. Your counsel decides which obligations apply.

What must keep running while it is being rebuilt?

Our proposal will name the first capability to migrate and what your team would own at the end.

Arrange a discussionLegacy modernisation