Every choice here was made so that someone other than us could maintain the result. That rules out a lot of interesting technology, which is the point.
Which of these we reach for depends on the problem. Python where data and AI are central, Java where a system has to run hot for years, native mobile where the device is doing real work. The constant is that we choose things you could hire someone else to maintain.
Long-term supported, extremely well documented, and you can hire for it in any South African city. Unfashionable, which in a system meant to last five years is a feature. Most of what we build with it falls under web application development.
Spring Boot · Spring Data · Spring Security
Where data work, automation and AI sit at the centre of the problem. Django when the application needs a full framework around it, FastAPI when it is a service that should stay small and fast. This is the stack behind our AI and automation work.
Python · Django · FastAPI
Native Android in Kotlin and native iOS in Swift where the app leans on the device. Flutter or React Native where one codebase across both platforms is the better trade-off, with the choice usually coming down to what the rest of your team already knows. More on what that looks like on the mobile app development page.
Kotlin · Swift · Flutter · React Native
For interfaces that genuinely need to be applications. Anything that should be found by search is server-rendered instead, because a page that needs JavaScript to show its content is a page search engines struggle with. The same web application development work as the backend above.
React · TypeScript · Vite
One relational database, with every schema change applied as a numbered migration so it can be rebuilt from scratch and arrive in the right shape. Boring, reliable, and free.
PostgreSQL · Flyway migrations
Application, database and proxy as containers, so the environment is defined in configuration rather than assembled by hand on a server nobody wants to touch.
Docker · Docker Compose
Whichever suits the workload and what you already run. The founder holds the Microsoft Certified: Azure Solutions Architect Expert certification (AZ-305), and our own platform runs on AWS.
AWS · Azure · Caddy · automatic HTTPS
Where systems need to react to events rather than poll each other. Used when the problem calls for it, not by default, because it adds operational weight.
Apache Kafka · JMS
For services and APIs where the team is already working in TypeScript end to end, and for real-time features where an event loop is the natural fit.
Node.js · TypeScript · Express
Where a business already runs on Microsoft and the sensible thing is to build with the grain of what their people support rather than against it.
.NET · C# · ASP.NET Core
For small, fast services that need to start instantly and use very little memory. Deliberately narrow language, which is the point when a service should be boring.
Go
Infrastructure written down as code rather than clicked together in a console, so an environment can be reviewed, recreated and torn down predictably. Same territory as cloud and infrastructure work generally.
Terraform · infrastructure as code
Automated tests that block a release when they fail, wired into a pipeline that builds, deploys and smoke-checks on every change. The standard we hold for software testing and QA engagements too.
JUnit · GitHub Actions · Playwright
Where a language model is genuinely the right tool. The assistant on this site runs on it, with conversations logged to our dashboard as records.
Anthropic Claude API
We will tell you when an app is the wrong answer. If a product is mostly screens and forms, a well-built mobile web experience reaches more people with no install, no app store review and one codebase to maintain. We build apps when the device is doing real work, not because an app was assumed.
We avoid frameworks and platforms with small communities or uncertain futures, however elegant. If you would struggle to hire a second person who knows it, it is the wrong choice for a system you have to live with.
We do not use no-code platforms for core business systems. They are excellent for prototypes and genuinely useful for simple internal tools, but they tend to become the thing you cannot change or leave.
And we are not tied to any vendor. Samloryx holds no vendor partner accreditation, which means no commercial incentive to steer you toward a particular cloud or product. See the partners page for exactly where that stands.