Software engineering

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 such as PostgreSQL or SQL Server, and the cloud you already use. We avoid niche tools unless they solve a real problem, and we record each choice and its reasons.

Read more: Custom software developmentLink to this question

We use React with Next.js for most new applications because it supports server rendering, has strong tooling and is widely known by engineers. We also work with Angular and Vue, and we continue in the framework you already use when that is the sensible choice. The decision depends on your team’s skills, what the application must do and what you will maintain afterwards.

Read more: Web applicationsLink to this question

Yes. We keep every piece of text out of the code so it can be translated, and we lay out pages with logical properties so they mirror correctly for right-to-left languages such as Arabic. Dates, numbers and currencies follow each locale. We plan this from the start, because adding a second language to an application built for one is far more work.

Read more: Web applicationsLink to this question

Native apps in Swift and Kotlin give the fullest access to device features and the closest fit to each platform. Cross-platform apps in React Native or Flutter share most of their code between iOS and Android, which lowers the cost of building and changing them. We recommend native when the app depends heavily on the device, such as payment hardware or complex media, and cross-platform for most business and consumer apps.

Read more: Mobile appsLink to this question

Yes, where the journeys allow it. We store the data the user needs on the device, encrypted, and queue their changes until the connection returns. Sync rules decide what happens when the same record changed in two places. We design those rules with you, because they are business decisions as much as technical ones.

Read more: Mobile appsLink to this question

Usually the one you already use, unless there is a clear reason to change. Amazon Web Services, Microsoft Azure and Google Cloud all run enterprise workloads well. The deciding factors are your existing contracts and skills, the managed services you need, data-residency rules and how your other systems connect. We work across all three and keep provider-specific code to the places where it is worth it.

Read more: Cloud and DevOpsLink to this question

We use the tools that fit your stack and your team: Playwright or Cypress for web end-to-end tests, Appium for mobile, Jest, JUnit or pytest for unit tests, Postman for API checks, k6 or JMeter for performance and OWASP ZAP for security scans. We keep the tests in your repository and in your engineers’ language where we can, so they can maintain them.

Read more: QA and test automationLink to this question

We use the partner’s test environment or sandbox where one exists, and simulators where it does not, so tests can run on every change without depending on a third party. Test data covers the unhappy paths: rejected payments, timeouts, duplicate messages and partial failures. End-to-end checks confirm that totals reconcile across systems, not only that each call returned a success.

Read more: QA and test automationLink to this question

Yes. Right-to-left design is more than flipping the screen. Navigation, progress indicators, charts and icons that imply direction need mirroring, while numbers, logos and media controls usually do not. Arabic text needs its own typeface, size and line height. We design both directions together and review them with native readers.

Read more: UX and UI designLink to this question

A design system is a shared set of colours, type, spacing and components, with guidance on when to use each, kept in step between design files and code. You need one when several teams or products must look and behave consistently, or when a product will grow for years. For a single small tool, a lighter component library is often enough.

Read more: UX and UI designLink to this question

When the old core is stable and correct but hard to reach. Modern APIs in front of it let new channels, partners and products use its functions without touching its internals, at far lower risk than replacing it. We recommend replacement when the system blocks change, cannot be secured or can no longer be staffed.

Read more: Legacy modernisationLink to this question

We work with the stacks many business systems were built on, including older versions of Java and .NET, relational databases such as Oracle Database and SQL Server, SOAP services and file-based interfaces. For rarer platforms we assess the code first and tell you plainly whether we have the skills, or whether a specialist should join the team.

Read more: Legacy modernisationLink to this question