Technologies
Chosen per project. The starting points are the requirement, how the system will have to be maintained, and who owns the code afterwards, rather than whichever framework is having a good year.
The toolkit
Six groups, and what each is genuinely for. Nothing is listed that we do not actually work with, and nothing has been added to make the list look longer.
Toolchains for Android and iOS, native and cross-platform. We go native when the app leans on the platform itself — background work, hardware, tight performance — and cross-platform when one codebase genuinely serves both stores without compromise.
Everything the visitor actually touches. Typed components, layouts that hold from a 320px phone to a wide monitor, and a rendering strategy decided page by page rather than imposed across the whole site.
The part nobody sees and everybody depends on. Business rules, authentication, and the APIs your apps and websites call — validated at the edge, versioned, and documented so an integration does not need a phone call.
Where the data lives. Schema, indexes and a migration path are decided before the first row is written, because retrofitting them once a table has a million rows is the expensive way to learn.
Hosting, deployment and knowing when something has broken. We keep infrastructure as plain as the requirement allows, so the people who own it afterwards can reason about it without a specialist.
Version control and release discipline. Every project is in Git from the first commit, which is what makes it possible to see what changed, undo it, and hand the whole thing over cleanly.
Selection
A technology choice has a long tail. It decides 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 it.
We start from the problem, not the framework. A content site, an app that must keep working where there is no signal, and an internal reporting tool have almost nothing in common, and the stack that answers one of them well is often the wrong answer for the next.
Code gets read far more than it gets written. We lean towards tools with real documentation, a calm release history and a community large enough that whatever goes wrong has already gone wrong for somebody who wrote it up.
A build is only finished when someone else could pick it up. That means a stack you can actually hire for, a repository you control from the first commit, and nothing that quietly leaves us the only people able to change what you paid for.
Every dependency eventually wants a version bump, and a few eventually want replacing. We take well-supported over newest, keep the number of moving parts down, and point out the upgrades that will matter later while they are still cheap.
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 what constrains it. We will walk through the options and the trade-offs with you before anyone writes code.