How we choose
- Can we hire for it?
- Maintained down the line?
- Fits the problem?
The same questions, asked in that order. Boring technology wins most of these arguments, and we would rather win them early than explain a rewrite later.
Our stack
and channels.
The stack and the channels are chosen together. Tracking is easier when the app renders on the server. Ads are cheaper when pages load fast. One team makes those trade-offs in one conversation, and says plainly when a choice has stopped making sense.
- Hiring Can we staff it next year
- Lifespan Maintained down the line
- Fit The problem, not the fashion
- Daylight Changes costed and announced
Our choices
What we build with, and what we buy on.
We are not loyal to any tool. We are loyal to the outcome. Still, some choices repeat, because they keep working — here they are, with the reasoning behind each one.
Frontend
- TypeScript
- React
- Astro
- Design tokens
TypeScript with React or Astro, depending on the job. Server rendering when search matters, static output when nothing needs a server.
Design tokens instead of scattered styles, so the next redesign is a change of values rather than a rebuild.
Backend
- Node
- Python
- Go
- PostgreSQL
- Redis
Node, Python or Go, with PostgreSQL as the default database and Redis for queues and cache.
Clear module boundaries throughout, so parts can be replaced later without a negotiation.
Cloud and delivery
- AWS
- Google Cloud
- Containers
- Infrastructure as code
AWS or Google Cloud. Containers, infrastructure as code, and a pipeline that deploys on merge.
Staging mirrors production, so a surprise is rare and an incident is short.
Mobile
- Swift
- Kotlin
- React Native
- Flutter
- Mobile development
Swift and Kotlin for native. React Native or Flutter when screens are mostly forms and lists.
Data and AI
- Warehouse first
- Modelling second
- Machine learning
Warehouse first, then modelling. We add machine learning when a rule cannot do the job — and we say so plainly when a rule can.
Marketing channels
- Search ads
- Paid social
- Organic and content
- Email and lifecycle
- Analytics
Search ads for existing demand, paid social for demand you create, organic search and content for the long tail, and lifecycle email for the customers you already paid for.
Analytics across all of it, or none of the above is an argument you can win.
How we choose
The questions, asked in that order, plus the one that decides the pair. Boring technology wins most of these arguments.
Can we hire for it?
A tool few people on the market know is a tool you pay a premium to staff every year. We would rather settle that question at the start of a project.
Will it still be maintained?
An upstream project going quiet is a cost that arrives late. The question gets asked before the first commit, not after the first security advisory.
Does it fit the problem?
Not the fashion. A queue that handles your real volume is better than one built for a scale you will never reach.
Does it fit the other half?
Stack and channels are picked together. Server rendering makes tracking easier; fast pages make ads cheaper. One team makes both calls in one conversation.
See the full service mapWhen we change our minds
A tool leaves this list the same way it arrived: because of an outcome, not because something newer appeared.
See the full service map-
Notice
A hire we could not make. An upstream project going quiet. A bill that stopped making sense. The trigger is always something that happened, not a trend.
-
Say so
In the review you already sit in, while it is still a paragraph. Not as an unexpected line item in next quarter's sprint plan.
-
Cost it
The move gets an estimate and a build order before anyone starts. A migration you did not budget for is still a migration you pay for.
-
Do it in daylight
Switched behind a feature flag, on weekdays, in steps you can follow. Never bundled into an unplanned rewrite.
Before you ask
Answers as we would give them on a call.
Will you work in our stack instead of yours?
Yes, if it is reasonable and your team knows it. If it will slow the product down we say so in discovery and give you the cost of both roads, rather than quietly starting a rewrite.
Why so little on this list?
Because every extra tool is another thing to hire for, patch and document. A short list the whole team knows is easier to support than a long one.
Do you use AI in the build?
Where a rule cannot do the job. We say so plainly when a rule can, because a model you have to monitor is more expensive than an if statement you can read.
Who owns the accounts and the code?
You do, from the first commit. Repositories, cloud accounts and ad accounts sit in your name and we work inside them.
Tell us what you are running today
A list of the tools and the channels is enough. We reply with what we would keep, what we would move, what the move costs, and in which order.