Skip to main content
FromNine
Menu

Engineering

Business software your developers can keep extending.

We engineer SaaS products, service portals for residents and staff, and core business applications. They meet accessibility standards, are secure from the first build, and remain maintainable by your in-house developers for years after go-live.

For Indian software companies selling into the European Union, and for enterprises and public bodies whose users span several languages and rulebooks.

Share your requirementsView legacy modernisation
Enterprise Software & SaaS: the four layersFour layers drawn one behind the other. Top: the accessible screens that users work in. Second: the domain modules that carry the business rules. Third: platform services for tenants, identity and data. Bottom: the secure build and release pipeline.01Accessible screens02Domain modules and rules03Tenants, identity, data04Secure build pipeline
  1. 01Domain-driven design for rule-heavy processes such as applications, claims and approvals
  2. 02Accessibility to WCAG 2.2 AA, EN 301 549 and IS 17802 from the first wireframe
  3. 03Decision records and runbooks that your own developers can take over

01 Challenges

What teams tell us before a rebuild

  1. 01

    A minor change needs a full quarter

    The system runs, but no developer will touch its core. Small changes trigger long regression cycles and wait for a release window.

  2. 02

    Residents and staff cannot use the portal

    It breaks with screen readers, on low-end phones and in the Indian languages the department publishes in. Grievances come in before any accessibility audit.

  3. 03

    A change for one client breaks another

    The SaaS product grew through client-specific customisation. Each release is now negotiated, and several tenants are stuck on old versions.

  4. 04

    Knowledge left with the previous vendor

    No design decision was recorded. The original developers have moved to other accounts, and the code is the only documentation left.

  5. 05

    EU customers send security questionnaires

    A European buyer asks for an SBOM, a vulnerability handling process and evidence for the Cyber Resilience Act. None of it is ready.

02 Scope of work

Scope of the practice

  1. 01 Engineering SaaS products

    Products that serve many clients from a single codebase: a suitable tenancy model, configuration in place of client-specific code, and releases that every tenant receives.

    Scope of work

    • Choice of tenancy model: shared, pooled or one isolated stack per tenant
    • Approach to configuration and feature flags
    • Usage metering and billing integration
    • Release trains with rollout per tenant

    Deliverables

    • Design for tenancy and isolation
    • Configuration model with guardrails
    • Release procedure with rollback for each tenant

  2. 02 Domain design where the rules are complex

    Domain-driven design for software whose value lies in its rules: applications and approvals, eligibility, tax and regulatory calculations. We choose consciously between a modular monolith and microservices, and usually begin with the monolith.

    Scope of work

    • Event storming sessions with subject experts
    • Bounded contexts and the boundaries between modules
    • Business rules written so that they can be tested
    • Decision records for the major design choices

    Deliverables

    • Domain model and context map
    • Modular codebase whose boundaries are enforced
    • Executable specifications for the critical rules

  3. 03 Service portals for residents, customers and staff

    Screens built on a design system and accessible from the first release. For a State department this can mean Aadhaar-based authentication, document fetch from DigiLocker and content in the Indian languages it publishes in; for EU customers, the languages of their markets.

    Scope of work

    • Design system with accessible components
    • Content written in plain language
    • Testing with screen readers and other assistive technology, with real users
    • Translation workflow for each published language

    Deliverables

    • Portal on a reusable design system
    • Accessibility conformance report against WCAG and IS 17802
    • Content and translation workflow

  4. 04 Test engineering and secure development

    Automated tests at the right levels, contract tests between services, load tests before go-live, and a secure development lifecycle based on OWASP ASVS, SBOMs and controls on the software supply chain.

    Scope of work

    • Test strategy and automation
    • Contract tests and load tests
    • Threat modelling and verification against ASVS
    • SBOM generation and a policy for dependencies

    Deliverables

    • Automated test suites running in the pipeline
    • Security verification report
    • Vulnerability handling process that EU buyers can review under the Cyber Resilience Act

  5. 05 Modernisation in stages

    An old application is replaced one function at a time behind a routing layer, while daily work carries on. Related: legacy modernisation.

    Scope of work

    • Map of the functions the current system performs
    • Strangler-fig routing and wrapping of old interfaces in APIs
    • Data migration with reconciliation reports
    • Parallel runs for critical calculations

    Deliverables

    • Sequence of modernisation steps tied to business milestones
    • Routing layer and new modules running in production
    • Reconciled data at every switchover

  6. 06 Maintainable code and a planned handover

    Software that your developers can own: readable code, decision records, runbooks, and a handover plan agreed in the first week rather than improvised at the end.

    Scope of work

    • Pair programming with your developers during the build
    • Decision records stored next to the code
    • Runbooks and on-call guides for operations
    • Milestones for knowledge transfer

    Deliverables

    • Handover plan with acceptance criteria
    • Documentation held in your own repositories
    • An in-house team able to run the system

03 Architecture

Reference architecture (illustrative)

A common pattern when a new business application replaces an older one: an accessible front end, a routing layer that sends each function either to the old or to the new system, an API layer with defined contracts, and a modular core structured around the business domain.

Tenants and configuration are handled as explicit platform services rather than as conditions spread across the code. Below it all, each build runs the tests and security checks and generates an SBOM.

Layers shown

Users
Residents, customers and staff on any device, including those using assistive technology.
Modernisation
The routing layer, the current application and the reconciled data migration.
Platform
API layer, identity, modular core, tenants and configuration, and operational data.
Secure build
Contract and load tests, ASVS checks and an SBOM generated by every build.
Illustrative example

  1. Users

    • Residents, customers, staff
    • Accessible front end

  2. Modernisation in stages

    • Routing layer
    • Current application
    • Reconciled migration

  3. Platform

    • API layer and contracts
    • Identity and roles
    • Modular core: applications, cases, billing
    • Tenants, configuration, feature flags
    • Operational databases

  4. Secure build

    • Contract and load tests, ASVS checks and an SBOM in each build
A modular core behind a routing layer

An illustration only; not drawn from any client system.

Read the diagram as text

The primary path leads from users to an accessible front end, then through a routing layer and an API layer into a modular core divided into bounded contexts.

The routing layer also sends certain functions to the current application, which is switched off in stages. Its data passes through a reconciled migration into the operational databases.

Identity serves the API layer. Services for tenants and configuration lie beneath the core. A secure build band at the base covers contract tests, load tests, ASVS verification and SBOMs.

04 Trade-offs and limits

Design trade-offs and limits

  • Begin with a modular monolith

    How we address it

    We begin with well-separated modules in a single deployable unit and extract services only when load, release frequency or team ownership require it.

    Limits and prerequisites

    Microservices address organisational questions as much as technical ones. Without a team to own each service, they bring extra cost and new ways to fail.

  • Accessibility is part of the engineering

    How we address it

    Accessible components, automated checks in the pipeline, and manual tests with assistive technology ahead of every major release.

    Limits and prerequisites

    Automated checkers catch only a share of the defects. Full conformance requires manual audits and, where possible, testing by persons with disabilities.

    Pages and documents that editors publish after go-live must meet the same standard. We train the editors, but what they publish is outside our control.

  • Data sets the pace of modernisation

    How we address it

    Migration is planned function by function, rehearsed and reconciled, and the business approves each switchover.

    Limits and prerequisites

    Old data is often the limiting factor. Cleaning it is as much a business responsibility as a technical one.

  • EU product rules for Indian software

    How we address it

    SBOMs, vulnerability handling and secure defaults are standard in our pipeline, which prepares a product for the Cyber Resilience Act before it is sold in the EU.

    Limits and prerequisites

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

05 Delivery steps

Delivery steps

Short iterations, real users from early on, and a handover planned from the first week.

  1. 01

    Understand the domain

    Event storming with the staff who apply the rules, plus a map of the functions the current system performs.

    OutcomeContext map and the first decision records

  2. 02

    Release one narrow slice

    A single function from screen to database, routed through the new layer and live with real users.

    OutcomeFirst slice running in production

  3. 03

    Extend function by function

    Every release moves one function with its data and its users, with reconciliation and a rollback prepared.

    OutcomeRelease plan organised by function

  4. 04

    Transfer ownership

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

    OutcomeSigned-off handover

06 Approvals

Who approves what

For business software, control means being able to show who changed what, who approved it and how to reverse it.

  • Your product owner sets scope

    Your product owner sets the priorities and accepts every increment. We advise; the decision is theirs.

  • Every setting has an owner

    Tenant settings and feature flags change only through an audited procedure, by the roles you designate.

  • Each switchover is approved

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

  • Design decisions are recorded

    Decision records state what was chosen, by whom and for what reason, so later teams can revisit a 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 already in place
  • Event streaming
  • Search engines
Quality and security
  • Playwright and contract testing
  • Load and performance testing
  • SAST, DAST and dependency scanning
  • SBOMs in CycloneDX or SPDX format

A product listed here reflects our engineering experience with it, not a partnership with or endorsement by its vendor.

08 Scenario

Illustrative scenario

Illustrative example

An Indian SaaS product preparing for its first EU customers

01Starting point
An Indian software company sells a customer service product to Indian enterprises and has signed its first European buyers. Client-specific code has crept in, accessibility has never been audited, and the EU buyers’ security questionnaires ask for an SBOM and a vulnerability process.
02What we would set up
One codebase with tenant configuration replacing client-specific code, a design system tested against WCAG 2.2 AA, and a pipeline that generates SBOMs and records the vulnerability handling process.
03Where an officer decides
The product owner decides on shared features; the head of security approves the vulnerability process before it is shared with EU buyers, and the company’s legal advisers assess EU obligations.
04How success would be measured
Accessibility defects per release, time to roll a change out to every tenant, and security questionnaires answered without new engineering work.

09 By industry

By industry

  • Government & Public Sector

    Application processing systems and service portals for departments and urban local bodies, designed to GIGW 3.0, with Aadhaar-based authentication and DigiLocker where the department uses them.

  • Banking & Financial Services

    Customer portals and back-office systems for banks, NBFCs and insurers, with complete audit trails and a release process that passes change management review.

  • Manufacturing & Industry

    Product configurators, dealer and service portals, and SaaS products for machinery and component makers, linked to ERP and field service.

India

Building in India for European buyers

An Indian SaaS company that sells to consumers in the EU meets the European Accessibility Act, applied through national laws since 28 June 2025, and the Cyber Resilience Act, whose obligations for products with digital elements start in stages. Where it offers services to people in the EU, the GDPR applies as well (Article 3(2)).

At home, IS 17802 from the Bureau of Indian Standards is aligned with WCAG 2.1 and EN 301 549, and GIGW 3.0 sets WCAG 2.1 level AA for government websites and apps. We hold market differences in configuration and bounded modules, so entering a new market is a release rather than a separate codebase, and the pipeline produces the accessibility and security evidence buyers ask for.

FAQs on enterprise software and SaaS

Should we develop our own software or configure a platform?

Configure a platform where your process is largely standard, and develop where the process is your differentiator or where no platform can carry the rules. Since we implement Salesforce, SAP and Odoo and also write custom code, we have no incentive to favour either route. Our Architecture & Consulting practice makes the decision explicit.

Will you guarantee that our portal is accessible?

We develop to WCAG 2.2 AA, EN 301 549 and IS 17802, test with tools and by hand, and hand over a conformance report listing any open issues. We do not promise a defect-free result; we commit to finding the issues, reporting them and fixing those within our scope.

Is it possible to modernise without a single big switchover?

Yes, and it is what we advise. A routing layer lets us move one function at a time while the current application keeps running, with the data reconciled at every step.

Can our in-house developers take over the system?

That is the plan unless you decide otherwise. Handover criteria are set at the start, your developers work in pairs with ours throughout the build, and decision records and runbooks are kept in your repositories.

We are an Indian software company. Does the Cyber Resilience Act affect us?

If you place software with digital elements on the EU market, it can create obligations for secure design, vulnerability handling and documentation, wherever you are based. We produce the engineering evidence: SBOMs, a vulnerability process and secure defaults. Whether and how it applies is for your legal advisers.

Tell us which system must keep running while it changes

We will suggest the first function to move and describe what your team would own once the work is done.

Share your requirementsView legacy modernisation