Technologies
Decided project by project. What settles it is the requirement, who will maintain the result, and who holds the code afterwards — not whatever is currently being written about.
The toolkit
What each one is actually used for. Nothing is listed that we do not work with, and nothing has been added to make the list look longer.
Native when the app leans hard on the device — camera, sensors, background work, tight animation. A shared codebase when both stores really do want the same product and the saving is real rather than a slide in a pitch.
The part people actually touch. Typed components, layouts that hold from a 320px phone to a wide monitor, and a rendering choice made per page instead of declared once and applied everywhere regardless.
Nobody notices it until it stops. Rules, sign-in and the interfaces your apps depend on — validated at the boundary, versioned, and documented well enough that integrating does not require booking a call.
Where it all settles. Schema, indexes and a migration path are argued about before the first row exists, because doing it after a table has grown is the expensive way to learn it.
Hosting, releases, and hearing that something broke from a monitor rather than a customer. Deliberately ordinary setups, so whoever inherits this does not need a specialist on retainer to read it.
Version control and release discipline. Git from the first commit — that is what makes it possible to see what changed, undo it, and hand the whole thing over without gaps.
Selection
A stack decision outlives the project that made it. It decides who can work on this in two years, what the next upgrade costs, and how long a new developer takes to become useful.
A marketing site, an app that has to keep working in a basement with no signal, and an internal reporting tool have almost nothing in common. Picking the stack before understanding which of those you have is how projects end up fighting their own tooling.
Code gets read far more than it gets written. We lean towards tools with real documentation, a boring release history, and enough users that whatever breaks has already broken for somebody who wrote up the fix.
A project is only really delivered when somebody else could take it over. That means a stack you can hire for locally, a repository in your name from the first commit, and no arrangement that quietly makes us the only people who can change it.
Every dependency needs a version bump eventually and some need replacing outright. We take well-supported over newest, keep the moving parts few, and point out the upgrades that will hurt 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.
Every trademark, product name and company name that appears on this website belongs to whoever owns it. None of them is mentioned to suggest a partnership, an endorsement or an affiliation, and no such relationship exists unless this site says so explicitly.
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.
