Technologies
Chosen per project. The starting points are the requirement, how the system will be maintained, and who owns the code afterwards, rather than whichever framework is currently in fashion.
The toolkit
Six groups and what each is genuinely used for. Nothing appears here that we do not work with, and nothing has been added to lengthen the list.
Android and iOS, built natively or from a shared codebase. Native wins when the app leans hard on the device itself; a shared codebase wins when both stores want substantially the same product and the savings are real rather than theoretical.
The visible half. Typed components, layouts that survive everything from a narrow phone to a wide monitor, and a rendering approach decided page by page rather than declared once and applied everywhere regardless.
Invisible until it fails. Business rules, sign-in, and the interfaces your apps and sites depend on: checked at the boundary, versioned, and documented well enough that integrating does not require a meeting.
Where everything ends up. Schema, indexes and a migration route are agreed before the first record exists, because fixing that after a table has grown is the costly way to learn the lesson.
Hosting, releases, and finding out something broke before a customer tells you. We keep the setup as ordinary as the requirement allows, so whoever inherits it can understand it without a specialist on retainer.
Version control and release habits. Everything is in Git from commit one, which is what makes it possible to see what changed, put it back, and hand the whole thing across without gaps.
Selection
A technology decision has a long tail. It settles who can work on the project in two years, what an upgrade will cost, and how soon a new developer becomes productive. Four questions come first.
The problem comes first and the framework second. A content site, an application that must keep working without a signal, and an internal reporting tool share almost nothing, and the stack that suits one is frequently wrong for the next.
Code is read far more often than it is written. We favour tools with genuine documentation, an unexciting release history, and a community large enough that whatever breaks has already broken for somebody who wrote it down.
A build is only finished when somebody else could take it over. That means a stack you can realistically hire for, a repository you control from the first commit, and no arrangement that leaves us the only people able to change what you paid for.
Every dependency eventually needs a version bump and a few eventually need replacing. We choose well-supported over newest, keep the number of moving parts low, 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 what constrains it. We will go through the options and the trade-offs with you before any code is written.
