Technologies
Chosen per project. What settles it is the requirement, how the result will be maintained, and who holds the code afterwards \u2014 not whichever framework is being written about this month.
The toolkit
And what each is genuinely for. Nothing is listed that we do not use, and nothing has been added to make the list look longer than it is.
Native where the app leans on the hardware — camera, sensors, background work, anything that has to feel immediate. A shared codebase where both stores genuinely want the same product and the saving is real rather than rhetorical.
What people see and press. Typed components, layouts that survive a 320px phone and a wide monitor alike, and a rendering decision taken per page rather than declared once for the whole project.
The half that is invisible until it stops. Rules, authentication, and the interfaces everything else depends on — checked at the edge, versioned, and documented so that integrating does not start with a phone call.
Where it all ends up. Schema, indexes and a migration route are settled before the first row is written, because reshaping a table that already holds a million rows is the expensive way to learn that lesson.
Hosting, deployment and knowing something has broken before a customer explains it to you. The setups are deliberately unremarkable, so inheriting one does not require hiring a specialist.
Version control and the habits around it. Git from the first commit — it is what makes it possible to see what changed, put it back, and hand over the whole history rather than a folder.
Selection
A stack decision outlasts the project that made it \u2014 it settles 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 work with no signal in a warehouse, and an internal reporting tool share almost nothing. Choosing the stack before settling which of those you are building is how a project ends up at war with its own tooling.
Code is read far more often than written. We favour things with real documentation, an uneventful release history, and enough users that whatever breaks has already broken for somebody who published the fix.
A project is only delivered when somebody else could pick it up. That means a stack you can hire for without paying for rarity, a repository in your name from the first commit, and no arrangement that makes us quietly indispensable.
Every dependency needs a version bump eventually and a few need replacing entirely. We take well-supported over newest, keep the moving parts few, and flag the upgrades that will be painful 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.
Trademarks, product names and company names appearing on this website remain the property of their owners. They appear for identification only, and their appearance implies no partnership, endorsement or affiliation of any kind unless this site states one 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.
