Technologies
The toolchain is chosen per project. We start from the requirement, from how the system will have to be maintained and from who will own the code afterwards, rather than from whichever framework happens to be in fashion this year.
The toolkit
Six groups, and what each one is genuinely used for. Nothing appears on this list that we do not work with, and the list is not padded to look longer than it is.
Native and cross-platform toolchains for Android and iOS. The choice between them is made per project: native where platform behaviour and performance matter most, cross-platform where a shared codebase serves the requirement better.
The interface layer: component architecture, typed application code, responsive layout and rendering strategies chosen for the page in question rather than applied uniformly.
Application servers, business logic and the APIs that mobile apps and web clients consume. Endpoints are versioned, validated at the boundary and documented for the teams that integrate with them.
Relational and hosted data stores. Schema design, indexing and migration strategy are treated as part of the build, not as an afterthought once the data has grown.
Where applications run, how they are deployed and how they are observed once live. Infrastructure is kept as simple as the requirement allows so it stays maintainable by the people who own it.
Version control, code review and release practice. Every project is tracked in Git from the first commit so history, rollback and handover are always possible.
Selection
Choosing a technology is a decision with a long tail. It settles who can work on the project in two years, what an upgrade will cost and how quickly a new developer becomes useful. Four questions come before the choice.
The starting point is the problem, not the framework. A content-led website, an application that has to work without a signal and an internal reporting tool have very little in common, and a stack that answers one of them well can be the wrong answer for the next.
Code is read far more often than it is written. We favour technologies with clear documentation, a stable release history and a community large enough that most problems have already been met and written up by somebody else.
A build is only finished when somebody else can pick it up. That means a stack you can reasonably hire for, a repository you control from the first commit, and no arrangement that quietly makes us the only people able to change the software.
Every dependency eventually needs a version bump and some eventually need replacing. We prefer well-supported versions over the newest release, keep the number of moving parts small, and flag the upgrades that will matter later while they are still inexpensive.
Trademarks
Every technology named on this page is named because it is part of the toolkit, and for no other reason. A name here tells you what we can build with and support. It is not a claim of partnership, endorsement, affiliation, sponsorship or certification, and no such status is held with any of the owners listed below.
All trademarks, product names and company names mentioned on this website are the property of their respective owners. Their mention does not imply any partnership, endorsement or affiliation unless expressly stated.
Marks referenced on this site
Next step
Tell us what you are building and the constraints around it. We will talk through the options and the trade-offs with you before any code is written.