Technologies
Chosen per project from the requirement, the maintenance burden, and who holds the code afterwards \u2014 not from whichever framework is being discussed this quarter.
The toolkit
What each is for. Nothing listed that we do not use, and nothing added to pad the list.
Native when the app depends on the device itself — camera, sensors, background work, anything that must feel immediate. A shared codebase when both stores want the same product and the saving is genuine.
Everything the user touches. Typed components, layouts that hold from 320px upward, and a rendering strategy chosen per page rather than imposed across the whole project.
Invisible until it fails. Rules, authentication, and the interfaces the rest depends on — validated at the edge, versioned, and documented well enough to integrate against without asking.
Schema, indexes and a migration path settled before the first row exists. Reshaping a table after it has grown is the costly way to discover that this mattered.
Hosting, deployment and alerting. Setups are kept ordinary on purpose, so inheriting one does not require a specialist on retainer.
Git from the first commit. It is what makes it possible to see what changed, revert it, and hand over a history rather than a folder of files.
Selection
A stack decision outlives the project. It settles who can work on this in two years, what upgrading costs, and how quickly a new developer becomes useful.
A marketing site, an app that must keep working without signal, and an internal reporting tool have almost nothing in common. Choosing the stack before settling which one you are building is how projects end up fighting their tooling.
Documentation that exists, an uneventful release history, and a large enough community that most breakages have already been solved and written up by somebody else.
Delivery is not complete until somebody else could take over. A stack you can hire for locally, a repository in your name from day one, and nothing that quietly makes us essential.
Dependencies need bumping and occasionally replacing. Well-supported beats newest, moving parts are kept few, and the upgrades that will hurt get flagged 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.
Any trademark, product name or company name on this website belongs to whoever owns it, and is used here for identification only. No partnership, endorsement or affiliation is implied by its presence, and none exists unless this site says so in as many words.
Marks referenced on this site
Next step
Tell us what you are building and what constrains it. We will go through the options and the trade-offs with you before any code is written.
