Technologies
It is easy to assume a modern-looking stack means modern-quality software. Often it means more upgrades and fewer people able to maintain it. We use well-documented, widely understood tools, and on this page we explain where each one fits and where it does not.
Common assumptions
Most stack decisions are steered by a handful of beliefs. Here is what tends to happen instead.
01 · Belief
In practice: New tools change quickly, document thinly and lose maintainers without warning. We prefer the version with a dull release history and plenty of answered questions online.
02 · Belief
In practice: Each extra piece is another thing to upgrade, secure and explain to the next developer. We add one only when it removes more work than it creates.
03 · Belief
In practice: It decides who you can hire later, what hosting costs, and how hard it is to leave us. So we explain the choice in writing and expect you to question it.
04 · Belief
In practice: The language can sometimes be swapped. The data model and the habits built around it rarely can. Those get the most care at the start.
Inventory
If a tool is missing from this list, we do not offer it. We have not padded the list to look longer.
A shared codebase is not automatically cheaper. It saves money when both stores need the same app, and it costs money when the app leans on device features each platform handles differently. We decide per project and write down why.
What a visitor sees is assembled from typed components and checked from narrow phones to wide monitors. Whether a page is rendered on the server or in the browser is decided by how fast it has to appear, not by habit.
The rules of the business sit here: sign-in, permissions and the endpoints apps and websites call. Inputs are validated where they arrive, endpoints are versioned, and each one is documented for whoever connects next.
Data outlives every interface built on top of it. The structure, the indexes and the way changes will be applied are agreed while the tables are still empty, when changing them is cheap.
The aim is the least complicated hosting that does the job, plus alerts that reach us when something fails. A setup that only one specialist understands is a risk we would be handing to you.
All work lives in Git from the first commit. That history shows what changed and when, allows a bad change to be reversed, and is handed to you complete.
Trade-offs
A choice that suits one project can be wrong for the next. Here is when we would reach for each option, and when we would talk you out of it.
Reach for it when
The app relies on the camera, background work, Bluetooth or anything else close to the hardware.
Leave it out when
Both platforms need the same forms and lists, and the budget would be split across two codebases for little gain.
Reach for it when
One set of screens serves both stores and most features are ordinary interface work.
Leave it out when
The app depends on platform features the shared layer handles poorly, leaving most of the work in custom bridges.
Reach for it when
An early product needs sign-in, storage and notifications without running its own server yet.
Leave it out when
Reporting, complex queries or strict data residency matter, which point to a database we control directly.
Reach for it when
Records relate to each other, totals must reconcile and history has to be kept. In business software, that covers most cases.
Leave it out when
The data is mostly loose documents synced to phones, where a managed document store is simpler.
Reach for it when
Hosting has to be inexpensive and widely available, or an existing PHP system is being extended.
Leave it out when
The same people will maintain a TypeScript front end and would gain from one language throughout.
Trademarks
Seeing a well-known product named on a developer’s site can suggest some kind of relationship with the company behind it. Here it does not. We list these tools only because we build with them. We hold no partner status, endorsement, sponsorship, affiliation or certification from any of their owners.
Every trademark, product name and company name on this website is owned by its holder. We use them to identify tools and platforms, and their use here signals no partnership, endorsement or affiliation.
Owners of the marks named here
Start here
Describe what you need built and any constraints you already have, such as existing systems, hosting rules or who will maintain it. We will set out the options and their downsides in writing before anything is chosen.
