Skip to content
XSIS
A man working at a desk with several monitors in an open-plan office

Software Engineering

Application, platform and composable product engineering

Core platforms, portals and services built to stay up, stay fast and keep changing

When off-the-shelf software stops fitting

Packaged software fits most of a business, but not the part that makes yours different. That might be a pricing engine, an operations platform, a portal your clients sign in to, or the services that hold your other systems together.

That software often carries the most traffic and the most risk. Downtime stops sales or public services, slow pages lose users, and a fragile architecture turns every new feature into a long project.

What changes for you

  1. Software that fits how you work

    Your rules, workflows and data model in the code, not worked around in spreadsheets and manual steps.

  2. Platforms that hold under load

    High-concurrency services and APIs designed for peak traffic, with limits and quotas that protect them.

  3. Change without starting again

    Composable building blocks, tests and automated releases, so new features ship as small, regular releases rather than large projects.

What we deliver

  • Enterprise software and multi-tenant SaaS

    Core business platforms and multi-tenant SaaS products, with tenant isolation, roles and audit trails designed in from the first release.

  • Composable architecture and micro-apps

    Packaged business capabilities (PBCs) are self-contained parts, such as pricing, onboarding or billing, that can be reused, replaced or released on their own. We build platforms and small apps from them.

  • Back ends and APIs

    Microservices and high-concurrency APIs over REST and GraphQL, with rate and quota management. Model Context Protocol (MCP) servers let AI agents use your systems safely.

  • Customer portals, citizen e-services and internal tools

    Self-service portals, government e-services and back-office tools that load quickly on a slow connection and work with a keyboard and a screen reader.

  • Front ends and design systems

    Interfaces in React, Next.js, Angular or Vue.js, built from a tokenised design system so every product looks and behaves the same as it grows.

  • Languages and right-to-left layouts

    Text kept out of the code and translated per language, with layouts that mirror correctly for Arabic.

  • Tests and a delivery pipeline

    Unit, integration and end-to-end tests on every change, and releases automated from the repository to each environment.

  • Documentation and handover

    Architecture decision records, documented APIs and runbooks, so your engineers or ours can keep changing the system safely.

Desktop applications

Desktop applications still carry much of the daily work at finance desks, shop counters, warehouses, clinics and control rooms. We build them for Windows, macOS and Linux, native or cross-platform. An older one can be modernised in steps.

  • Offline use and sync

    Encrypted local storage and conflict rules, so work continues without a connection and syncs safely later.

  • Device integration

    Connections to barcode scanners, receipt and label printers, scales, payment terminals and other local hardware.

  • Signed installers and updates

    Code-signed packages for your device management tools, with automatic updates, staged roll-outs and rollback.

  • Back-end and API integration

    Secure links to your ERP, CRM and other systems, with retries and clear messages when they are unavailable.

  • Sign-in and local security

    Single sign-on with your identity provider, encrypted local data, and no administrator rights needed to run.

How we work

  1. Discover

    We meet the people who will use and run the software, map the current process and agree the first release.

  2. Design

    We shape the architecture, the data model and the key screens, and test risky assumptions with prototypes.

  3. Build in short iterations

    We deliver working increments, demonstrate them to you on a staging environment and adjust the backlog with what we learn.

  4. Verify on every change

    Automated tests, code review and checks for performance, security and accessibility run before anything is merged.

  5. Release

    We deploy through the pipeline with a rollback plan, and watch the system closely after go-live.

  6. Run and evolve

    We support and extend the system under a service agreement, or hand it over to your team with a period of overlap.

Technologies and standards

We choose a stack your team can run and hire for. Naming a product does not mean a partnership with its vendor.

Languages
  • TypeScript
  • Java
  • C#
  • Python
  • Go
  • PHP
Frameworks
  • Node.js
  • NestJS
  • Spring Boot
  • .NET
  • Django
  • Laravel
  • React
  • Next.js
  • Angular
  • Vue.js
Databases
  • PostgreSQL
  • MySQL
  • MongoDB
DevOps and observability
  • Docker
  • Kubernetes
Design and accessibility
  • Storybook
  • WCAG 2.2
Integration
  • REST
  • GraphQL
  • OpenAPI

How to start

Bring a specification and we answer with a proposal. Bring an idea and the Blueprint Studio turns it into an architecture and a fixed scope first.

What happens next

  1. Pre-consulting session

    A free 30-minute online pre-consulting session: we go through your goals, systems and constraints.

  2. Readiness review

    In a free 48-hour readiness review, a Principal Architect checks your project against the 6-point Definition of Ready and recommends the track that fits.

  3. Choosing the track

    Scope-ready projects receive a binding proposal within 3–5 business days. Concept-stage projects start in the Blueprint Studio. A live system that is failing, undocumented or needs integration starts with a diagnostic of 1–2 weeks. The Blueprint Studio and the diagnostic each have a fixed fee, quoted in the proposal.

  4. Delivery in five stages

    Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.

  • AI-native product teams

    Managed, cross-functional pods of senior engineers, equipped with agentic coding and QA harnesses.

  • Fixed-outcome projects and round-the-clock managed services

    Fixed-scope, milestone-driven delivery with named delivery leads, and round-the-clock application managed services under SLA governance.

Questions and answers

How do you choose the technology stack?

We start from what your team can run and hire for, what your other systems use and what the software must do. For most business software that means a mainstream language such as TypeScript, Java, C# or Python, a relational database and the cloud you already use. We record each choice and its reasons.

Can you build a multi-tenant SaaS product?

Yes. We design tenant isolation, per-tenant configuration, roles, billing hooks and audit trails from the first release, because adding them later means rewriting the data model. We agree with you whether tenants share a database, a schema or nothing, based on your security and cost needs.

What does composable architecture mean for us?

Your platform is built from self-contained business capabilities with their own APIs, such as pricing, onboarding or billing. Each can be changed, scaled or replaced without touching the rest, and new products can reuse them. It suits platforms that will grow for years; a small tool does not need it.

Which front-end framework do you use?

We use React with Next.js for most new applications because it supports server rendering and has strong tooling. We also work with Angular and Vue.js, and we continue in the framework you already use when that is the sensible choice.

Can our own engineers work alongside your team?

Yes. Many clients want their engineers in the same repository from the start, so knowledge stays in-house. We agree code review, branching, the definition of done and who approves releases. Your engineers can pair with ours or take over parts of the system when they are ready.

What if our requirements change during the project?

They usually do, and the process expects it. The backlog is reviewed with you at every iteration. On a fixed-scope project, a change is agreed in writing, with its effect on cost and dates, before work on it begins.

What happens after go-live?

You choose. We can support and extend the system under an agreement with response times and monitoring. Or we hand it over to your team with the code, the documentation and a period of overlap.

Why build a desktop application rather than a web application?

Choose desktop when the work needs offline use, direct access to devices or local files, heavy data or graphics, or fast keyboard-driven screens. For most other needs, a web application is easier to roll out and update. We recommend case by case, and sometimes a web application with a small desktop component is the right answer.

Native or cross-platform desktop: which should we choose?

Native applications give the best performance and the closest fit to each operating system. Cross-platform applications share one codebase across Windows, macOS and Linux, which lowers the cost of building and changing them. We recommend native when one platform dominates or the work is demanding, and cross-platform when several platforms matter.

Can a desktop application work without a network connection?

Yes, for the tasks that allow it. We decide with you which data each user needs on the device, keep it encrypted, and record their changes until the network returns. When the same record changes in two places, agreed rules decide which change wins or ask a person to choose.

Can the application work with our scanners, printers and other devices?

Yes. We integrate with the devices your staff use, such as barcode scanners, receipt and label printers, scales and payment terminals. We connect through each device's drivers, SDKs or standard ports, and test with the exact models and firmware you run, because devices of the same type often behave differently.

How are desktop updates delivered and controlled?

Every release is code-signed, so each device can check that it has not been altered. Releases go out through your device management tools or a built-in updater, first to a pilot group and then to everyone. If a release causes problems, devices can return to the previous version.

Ready to build? Ask for a proposal.

Send your requirements or RFP. Our architects validate them and return a binding, fixed-scope proposal.

What happens next

  1. Readiness review

    In a free 48-hour readiness review, a Principal Architect checks your project against the 6-point Definition of Ready and recommends the track that fits.

  2. Binding proposal

    After architecture validation at no cost, you receive a binding, fixed-scope proposal within 3–5 business days: milestones, architecture, team structure and SLAs. We sign a non-disclosure agreement (NDA) with you on request, before you share your requirements.

  3. Mobilisation

    Once you sign, our engineering pods begin Sprint 0 within 5–10 business days of contract signature.

  4. Delivery in five stages

    Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.