Technologies
Conventional tools, chosen deliberately
The stack
What we build with
Languages & runtimes
- TypeScript
- JavaScript
- Python
- Swift
- Kotlin
- PHP
- Go
- SQL
Frontend
- React
- Next.js
- Vue
- Tailwind CSS
- React Native
- SwiftUI
- Jetpack Compose
- Astro
Backend & data
- Node.js
- PostgreSQL
- Redis
- MySQL
- Prisma
- GraphQL
- Kafka
- Temporal
AI & machine learning
- Claude
- OpenAI
- AWS Bedrock
- Azure OpenAI
- LangGraph
- PyTorch
- pgvector
- Pinecone
Cloud & infrastructure
- AWS
- Azure
- Google Cloud
- Vercel
- Terraform
- Docker
- Kubernetes
- Cloudflare
Content & commerce
- WordPress
- Shopify
- Sanity
- Contentful
- WooCommerce
- Strapi
- Payload
Data & analytics
- Snowflake
- BigQuery
- dbt
- Airflow
- GA4
- Looker Studio
- Power BI
- PostHog
Marketing & CRM
- HubSpot
- Salesforce
- Klaviyo
- Google Ads
- Meta Ads
- Semrush
- Ahrefs
- Segment
Design & creative
- Figma
- Adobe Creative Cloud
- After Effects
- Blender
- Cinema 4D
- Lottie
- Storybook
How we choose
Six principles behind every technology decision
Boring is a feature
We choose well-supported technology with deep hiring pools. Novelty is a cost you pay every year afterward in maintenance and recruitment.
Match the team, not the trend
If your team knows Python, we do not deliver a Go service because we prefer it. Maintainability by your people outranks our preferences.
Managed services first
Running your own database, queue or search cluster is a real operational cost. We reach for managed options unless there is a specific reason not to.
Avoid one-way doors
Some decisions are hard to reverse — tenancy models, domain architecture, primary datastore. Those get disproportionate scrutiny. The rest can be changed later.
No proprietary lock-in from us
We do not build on internal frameworks that only we understand. Everything we deliver uses technology you could hire for tomorrow.
Justify on request
Any technology choice we make should survive the question 'why this one?'. If it cannot, it was probably habit rather than judgment.
One-way doors
The five decisions that are expensive to reverse
- 01Primary datastore
- Changing it later means a migration with downtime, a dual-write period, or both. We default to Postgres and only deviate when the access pattern genuinely does not fit a relational model — not because a document store is faster to start with.
- 02Tenancy model
- Whether customers share a database, a schema or nothing at all decides your isolation guarantees, your per-customer cost and what you can promise in a security review. Retrofitting isolation onto a shared-row design is close to a rewrite.
- 03Identity and permissions
- Authentication can be swapped. The permission model — what a role means, whether it is per-record or per-resource — leaks into every query and every screen, so it earns design time before the first endpoint is written.
- 04Public API and data contracts
- Once an integration partner depends on a field, removing it is their outage. We version deliberately from the first external consumer rather than after the first breaking change.
- 05Hosting boundary
- Which cloud, which region and what may leave it are usually decided by your compliance surface, not by preference. It is worth being explicit early, because it constrains every managed service available to us afterwards.
Spend the argument where the door only opens one way. Everything else is a preference, and preferences should not cost you a week.
What we avoid
Four things we will not do to your codebase
Frameworks only we understand
An internal abstraction makes the second project faster and every future vendor slower. You should be able to hire someone off the open market who recognizes what they are looking at.
Infrastructure configured by hand
If the environment cannot be rebuilt from a definition in the repository, nobody actually knows what is running. Click-configured infrastructure is a documentation problem disguised as a working system.
Rewrites offered as a first answer
A rewrite trades a system with known flaws for one with unknown flaws and no users. We propose one when the cost of change is provably rising, and we say what would change our view.
Single-vendor lock-in without a reason
Managed services are worth their price; a proprietary runtime that cannot be exercised locally is a different trade. We take that trade only when the alternative is materially worse and we say so in writing.
Working with what you have
We do not require a clean slate
Next step
Wondering whether your stack is holding you back?
An architecture review takes two to four weeks and produces a prioritized list of what to fix, keep and replace — with the reasoning attached.
No pitch deck. A 30-minute conversation about what you are trying to achieve.