Technologies
You should be able to see what your software will be built with before you commit to it. This page explains the questions that decide which tools your project gets, lists every one we work with, and shows where each fits among our services.
Before a tool is chosen
A technology choice outlives the project that made it. It decides who can work on the code later, what upgrades will cost and how quickly a new developer finds their feet, so these questions come first.
We start from the hardest case rather than the typical one: a large volume of records, a dropped connection, many people editing at once. A content site, an app that has to work offline and an internal reporting tool each fail in different ways, so the right tools differ too.
Widely used, well-documented tools mean a large pool of developers who already know them. We would rather build on something ordinary that many people can maintain than on something novel that only a handful can.
Every additional service is one more thing to host, update and keep an eye on. We keep the architecture as plain as the requirement permits, so whoever inherits it can follow it without calling in a specialist.
Each dependency needs updating sooner or later, and a few need replacing altogether. Choosing versions with long support and active maintenance, and flagging the upgrades we can see coming, keeps that work small and planned rather than urgent.
It should not. Your code lives in a repository you control from the first commit, the tools are ones any capable team can pick up, and nothing is arranged so that only we are able to change what you paid for.
By purpose
Each group says what it is for and names the tools inside it. If a tool is listed, we work with it, and nothing has been added simply to make the list longer.
Should the app be written twice, once per platform, or once for both? Native code is the better answer when the app depends heavily on the camera, sensors or background work. A shared Flutter or React Native codebase is the better answer when both stores need essentially the same app, and we will tell you which case yours is.
Everything a visitor sees and taps. Pages are built from typed components, checked on small and large screens, and rendered on the server or in the browser according to what each page needs to load quickly.
Where the business rules live: who may sign in, what they may change, and how the app and website exchange data. Every interface is validated, versioned and written up so another developer can connect to it without asking us.
Your records are the part of the system that outlasts every redesign. Tables, indexes and the method for changing them later are settled before real data arrives, because restructuring a large table afterwards is slow and risky.
Where the software runs and how new versions reach it. We choose the plainest arrangement that meets the requirement and add monitoring so that a failure reaches us before it reaches your customers.
Every change is recorded in Git from the first day. That record is what lets anyone see what changed and why, undo a mistake, and receive the complete project at handover.
Where they are used
Most projects use only part of the list. Here is which groups usually come into play for each kind of build, with a link to the page describing that service.
Trademarks
No. A tool appears on this page because we build with it, and that is all its name here tells you. We hold no partnership, endorsement, sponsorship, affiliation or certification with any of the companies listed alongside, and nothing on this site should be read as suggesting we do.
Owners of marks mentioned on this site
Unsure where to begin
Describe what you want to build and the limits you are working within, whether that is existing systems, the people who will maintain it or the devices it must run on. We will talk you through the options and their trade-offs before anything is written.
