Technologies
Everything we build with, in one list.
The rule for being on this page is that we have shipped something with it. Not evaluated it, not read about it. Under each group is a note on what we actually do with it, including the parts we would not claim.
- 180
- tools and techniques
- 15
- areas of the stack
- In production
- not on a wishlist
What we live in
A long list invites one question.
Which of these do you actually work in every day? These six, and each one is named with the systems it is running in right now.
TypeScript
Web, API and mobile in one language, with types generated from the schema and shared across all three. One person can hold a whole feature rather than handing it across a boundary.
Running in Charten, InvtoryX, Larder, Eshop, Sill
Next.js & React
Every web application we have built in the last three years, including this site. Server rendering that is not an afterthought, and a hiring pool that will still exist when somebody else inherits the code.
Running in Charten, InvtoryX, Larder, Eshop, Sill
NestJS
The API layer under our platform. Structure the next person can follow, background work as a first-class thing, and authorisation written as guards you can test.
Running in Charten, InvtoryX, Larder, Sill
PostgreSQL & Prisma
The database under everything we operate. Ledgers rather than counts, row-level security for tenant isolation, and migrations rehearsed against real data before they run.
Running in Charten, InvtoryX, Larder, Eshop, Sill
React Native & Expo
iOS and Android from one codebase, sharing types with the web application. Offline-first where the work happens somewhere with no signal.
Running in InvtoryX, Larder, Sill
Payments & POS
Gateway routing across two processors, card-present terminals, delta sync against a point of sale, and reconciliation that names what disagrees rather than counting it.
Running in Eshop, Sill
Each of those links through to a case study on the work page, where the decision that was genuinely hard to get right is written up alongside what we would do differently.
The full stack
Boring on purpose.
Large hiring pools and long support horizons beat elegance for software that has to be maintained for years by people who are not in the room yet. The interesting choice is enjoyable for us and expensive for whoever inherits it.
Languages & runtimes
One language across web, API and mobile, and the others where they genuinely fit.
TypeScript end to end is the decision that does most to let a small team ship like a larger one: shared types, shared validation, and an integration break that becomes a compile error rather than a customer's Tuesday. Python where the libraries are, which in practice means data and machine learning.
9 in this group
- TypeScript
- JavaScript
- Node.js
- Python
- SQL
- Bash
- HTML
- CSS
- Dart
Web
The framework and the interface layer behind every application we ship.
Next.js on the App Router, server components by default, client components only where interactivity requires them. The markup arrives complete, which matters for search and matters far more for answer engines that never run JavaScript.
14 in this group
- React
- Next.js
- App Router
- React Server Components
- Vite
- Tailwind CSS
- shadcn/ui
- Radix UI
- Framer Motion
- TanStack Query
- React Hook Form
- Zod
- Astro
- Remix
Mobile & devices
iOS and Android from one codebase, plus the hardware a counter actually has on it.
React Native with Expo, so a mobile app shares real code with the web application in front of the same API. Offline-first where staff work in stockrooms and vans, which is a decision made on day one rather than a feature added later.
12 in this group
- React Native
- Expo
- EAS Build
- App Store Connect
- Google Play
- Offline-first sync
- SQLite on device
- Push notifications
- Barcode scanning
- ESC/POS printers
- Card readers
- Kiosk mode
APIs & backend
Where the business rules live, and anything that has to outlive a request.
NestJS for domain logic, background work and integrations, with the client generated from OpenAPI so a renamed field breaks the build instead of production. REST by default because it is simpler to cache, debug and hand to a third party.
13 in this group
- NestJS
- Express
- REST
- OpenAPI
- GraphQL
- WebSockets
- Server-Sent Events
- BullMQ
- Cron & scheduled jobs
- Webhooks
- Idempotency keys
- Rate limiting
- FastAPI
Data & storage
One database engine under everything, with the rest reserved for real reasons.
PostgreSQL, with row-level security so a forgotten filter in application code still cannot return another tenant's rows. Redis for the things a cache is actually for. Migrations rehearsed against a copy of production before they touch it.
12 in this group
- PostgreSQL
- Prisma
- Drizzle
- SQLite
- Redis
- pgvector
- Row-level security
- Database migrations
- Read replicas
- Event sourcing
- S3 & object storage
- Backups & PITR
Analytics & reporting
Agreed definitions first, then dashboards built around a decision.
Most reporting problems are definition problems: three teams with three meanings of the same word. We settle that before building anything, then keep reporting off a read model so a heavy query cannot slow down the people taking orders.
10 in this group
- dbt
- BigQuery
- DuckDB
- Metabase
- Looker Studio
- Materialised views
- Read models
- GA4
- PostHog
- Scheduled exports
AI & automation
Where it removes real work, and only where a user can tell it got something wrong.
Retrieval over documents you own, and extraction with a confidence threshold and a review queue. We do not ship a feature where a wrong answer is invisible, which rules out most of what gets demonstrated.
11 in this group
- Claude
- OpenAI
- Llama
- Embeddings & vector search
- Retrieval-augmented generation
- Structured output
- Confidence scoring
- Human review queues
- Document extraction
- Speech to text
- Prompt evaluation sets
Payments & commerce
Taking money reliably, and being able to prove afterwards where it went.
The common serious bug in payment code is not fraud. It is a retry that creates a second charge. Idempotency keys generated before sending, webhooks treated as hints rather than guarantees, and daily reconciliation that names the specific transactions that disagree.
16 in this group
- Stripe
- Stripe Terminal
- Stripe Billing
- Adyen
- NMI
- Dejavoo
- Authorize.net
- Square
- Toast
- Clover
- Lightspeed
- OneHubPOS
- Shopify
- WooCommerce
- Tax & VAT handling
- Reconciliation jobs
Identity & access
Who someone is, and precisely what they cannot do.
Permissions resolved per request rather than assumed from a single global role, and covered by tests asserting the negative case. Permission bugs never throw an error; they quietly return the wrong rows, which is why the tests matter more here than almost anywhere.
13 in this group
- Auth.js
- Auth0
- Okta
- Microsoft Entra ID
- Keycloak
- SAML
- OIDC
- SCIM
- Passkeys
- Multi-factor authentication
- Magic-link SSO
- Role & attribute-based access
- Audit logging
Business systems
Making the software you already pay for agree with the software we build.
Integration work fails on assumptions about the other system, so mapping what it emits, how often and what it does on a delete comes before any code. Every write is idempotent and every integration gets a reconciliation report.
13 in this group
- QuickBooks
- Xero
- NetSuite
- HubSpot
- Salesforce
- Pipedrive
- WordPress
- Zapier
- Make
- SFTP & flat-file feeds
- EDI
- Google Workspace
- Microsoft 365
Cloud & delivery
Infrastructure defined in code, and a pipeline that stops a bad merge.
Anything created by hand in a console exists nowhere and is known to nobody, and will be discovered during an outage. Managed services by default: they cost more per month and far less per year once you count the hours.
14 in this group
- AWS
- Vercel
- Cloudflare
- Fly.io
- Neon
- Supabase
- Docker
- Kubernetes
- Terraform
- SST
- GitHub Actions
- Preview environments
- Blue-green deploys
- CDN & edge caching
Quality & observability
Knowing it works before a customer tells you that it does not.
Tests concentrated where things have actually broken, because your incident history is a better prioritised list than any coverage target. Alerting tied to symptoms a user would notice rather than to every metric available.
14 in this group
- Playwright
- Vitest
- Jest
- Testing Library
- k6
- axe-core
- OpenTelemetry
- Sentry
- Storybook
- ESLint
- Prettier
- Dependabot
- CodeQL
- Uptime & synthetic checks
Messaging & notifications
Email, SMS and in-app messages that arrive, and can be proven to have arrived.
Deliverability is configuration rather than luck: SPF, DKIM and DMARC set up properly, bounces handled, and a log of what was sent to whom. Most complaints about email landing in spam turn out to be DNS records nobody finished.
9 in this group
- Twilio
- Resend
- Postmark
- Customer.io
- SendGrid
- Web push
- SPF / DKIM / DMARC
- Transactional templates
- Delivery logging
Search & visibility
Being found by search engines, and being cited by answer engines.
Two different jobs. Ranking rewards authority; being quoted rewards being parseable and complete. This site runs everything we would put on yours, including structured data on every page and an llms.txt.
12 in this group
- Schema.org
- JSON-LD
- Google Search Console
- Bing Webmaster
- Core Web Vitals
- XML sitemaps
- Canonical URLs
- robots.txt
- llms.txt
- Open Graph
- Server-side rendering
- Redirect mapping
Design
Interfaces people can use on the tenth hour, not just in the first minute.
Software that demos beautifully and software that is pleasant to use all day pull in opposite directions. If your users live in the tool, we optimise for the second, which usually means fewer animations and more keyboard paths.
8 in this group
- Figma
- Design tokens
- Component libraries
- Dark mode
- WCAG 2.2 AA
- Keyboard navigation
- Responsive layout
- Print & receipt layouts
Defaults, not requirements
This is our stack. It does not have to be yours.
If you already run something else and have a team who know it, we work in yours. A rewrite to suit a supplier’s preference is a cost with no return, and we would say so before quoting one.
Where we genuinely cannot help — a language we do not write, an architecture our platform does not support, a hosting arrangement we do not run — you would be paying us to learn on your money. You hear that on the first call.
Every choice traces to a requirement
If we cannot point at the constraint that forced a decision, it is a preference and we will call it that rather than dress it up as architecture.
You own it, in standard form
Conventional frameworks, conventional structure, your repository from the first commit. Another firm should be able to pick it up without learning anything we invented.
We say when a product would be cheaper
Sometimes the answer is Shopify, or WordPress, or something you could buy this afternoon. That costs us the engagement and it is the reason the advice is worth having.
New things earn their way in
Nothing reaches a client project until it has run on ours first. Our own systems are where a technology gets to fail without anybody else paying for it.
Tell us what you’re running today.
Including what you are being sold by somebody else. We’ll give you a straight read on both within one business day.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits