Technologies
Tools we use
The tools, patterns, and platforms we use most often, with short notes on why we choose them. Most entries run in systems we ship or operate; the case studies and open-source work carry the receipts.
Application stack
The layer clients see first. Every entry here is running in something we shipped or operate ourselves, and each one has a boundary where it stops paying.
Next.js
Our default for product frontends. Server components, route-level data loading, and the React ecosystem cover most product surfaces, and the hiring pool is real. We pick something else when the problem is mostly content: this site is SvelteKit.
Pairs with: NestJS, Generated API contracts
React Native / Expo
One team ships iOS and Android from the React codebase it already knows. EAS handles builds and over-the-air updates, so app releases move at web speed. Heavy native modules and deep platform work are where the abstraction starts charging rent.
Pairs with: Next.js
NestJS
Convention-heavy backends for codebases that will grow and change hands. Modules, dependency injection, and guards give a large team one shape to write against. For small services and edge runtimes it is more ceremony than the problem needs.
Pairs with: Postgres + Prisma, Generated API contracts
Convex
A typed backend where the database, functions, scheduling, and realtime sync are one system. We build products we run ourselves on it: taktiko is roughly 132,000 lines of TypeScript against one Convex backend. The tradeoffs are real. Relational depth is limited, and self-hosting is not the model.
Pairs with: Next.js, Multi-tenancy
Postgres + Prisma
Postgres is our default datastore on client platforms, with Prisma as the typed boundary between the schema and the services. In our stacks it carries the job queue too. We reach for something else when the workload is really documents, streams, or sync.
Pairs with: pg-boss, NestJS
pg-boss
Postgres-backed job queues with scheduling, retries, and transactional enqueue. Because jobs go through Prisma’s transaction client, a job and the state change that caused it commit together, which deletes a whole failure class. It earns its place until throughput or durability requirements outgrow a Postgres-backed queue.
Pairs with: Postgres + Prisma, Durable execution
Generated API contracts
Our NestJS platforms commit an OpenAPI document and generate the client the frontend consumes. Contract drift fails in CI instead of surfacing as a runtime cast. It costs a generation step in the pipeline and pays back every time a person or an agent writes code against the API.
Pairs with: NestJS, Next.js
Rust
For problems below the application layer: daemons, filesystems, performance-sensitive paths. Our file-guard daemon gates credential files behind per-process consent at the FUSE layer. We do not use it where TypeScript would do. We use it where the safety model has to hold at the syscall boundary.
Pairs with: Supply-chain controls
AI systems
AI features are software with a probabilistic component. These tools keep the probabilistic part bounded, traced, and swappable.
Bounded agents
Models handle judgment while code owns execution. Our aipm bot detects what is owed deterministically and uses the model only for wording; a human approves anything it would send. Agent behavior you cannot bound is agent behavior you cannot ship.
Pairs with: Langfuse, Model gateways
Langfuse
LLM calls get the same treatment as any other dependency: traced prompts, completions, latency, and cost per call. Langfuse makes agent behavior reviewable instead of anecdotal.
Pairs with: Bounded agents, OpenTelemetry
Model gateways
We call models through adapters and gateways rather than SDK calls scattered through the codebase. aipm runs Workers AI behind AI Gateway; client platforms wrap Gemini the same way. Swapping a provider becomes a config change instead of a refactor.
Pairs with: Bounded agents, Cloudflare Workers
Platforms
Where the workloads run. Most of what we deploy lands on Google Cloud and Cloudflare, with Vercel hosting the frontends that benefit from it.
Cloud Run
Our default compute target on GCP. It scales to zero, keeps the previous revision alive during rollout, and keeps the platform small enough that infrastructure never becomes the product. Long-running workers and heavy stateful jobs push past what it wants to be.
Pairs with: GitHub Actions, Workload identity
Kubernetes
The standard for container orchestration when workloads outgrow serverless. We run GKE and EKS, but we are honest about when you need it: most teams are better served by Cloud Run until they hit the complexity threshold where Kubernetes earns its operational overhead.
Pairs with: ArgoCD, Scaling paths
Cloudflare Workers
Code at the edge with queues, cron, durable objects, and KV attached. aipm runs entirely on it: Workers handle ingress, Durable Objects serialize per-thread state, Queues bound the model work. It is our default for bots, webhooks, and integration glue.
Pairs with: Model gateways, Durable execution
Infrastructure as Code
Infrastructure as code keeps resources and changes reviewable, and makes environments easier to reproduce.
Terraform / OpenTofu
We manage the full sweep in Terraform, from GitHub organization and repository settings at one end to GCP projects, services, and IAM at the other. The provider ecosystem and shared knowledge make it our usual default, and OpenTofu offers the same HCL workflow under an open-source license. Once configurations span several environments, Terragrunt keeps shared configuration, remote state, and dependency order in one place; plain Terraform stays appropriate while the graph remains manageable.
Pairs with: Infracost, Ansible
Ansible
When you need to configure what’s inside the machine, not just provision it, Ansible is the pragmatic choice. Agentless, SSH-based, readable YAML playbooks. We reach for it when cloud-init isn’t enough and a full control plane would be overkill.
Pairs with: Terraform / OpenTofu
Infracost
Infracost adds estimated infrastructure changes to pull requests. It gives reviewers useful cost context before resources are provisioned.
Pairs with: Terraform / OpenTofu
Delivery
A reliable delivery pipeline reduces the routine work and uncertainty around testing, deployment, and rollback.
GitHub Actions
Our default when the code already lives on GitHub: tests, builds, and deployments close to the pull request, with short-lived OIDC identity instead of stored cloud keys. On GCP we also use Cloud Build when staying inside the cloud’s auth boundary matters more than the Actions ecosystem.
Pairs with: Turborepo, Preview environments
GitLab CI/CD
For teams already using GitLab, its integrated pipelines, container registry, environments, and review apps keep the delivery workflow in one platform.
Pairs with: ArgoCD
ArgoCD
ArgoCD reconciles Kubernetes state from a Git repository. It is how we implement GitOps on Kubernetes: desired state versioned, configuration drift visible, and rollbacks through the same reviewable workflow.
Pairs with: Kubernetes, GitOps
Turborepo
Our monorepos run on Turborepo and pnpm workspaces. The point is affected-only work: CI builds and tests what a change touches instead of the whole graph. The orchestration layer has to stay honest about cache keys. A fast result on the wrong inputs is worse than a slow one.
Pairs with: GitHub Actions
Preview environments
A deployment per pull request, provisioned and torn down with the PR lifecycle. They keep staging from becoming a queue where unrelated features wait for each other, and they give reviewers and agents a real environment to check. We trigger them by cost and need; not every change earns one.
Pairs with: GitHub Actions, Cloud Run
Dependency automation
Grouped Dependabot updates across application packages, workflow actions, and infrastructure providers, with actions pinned to SHA. An enabled bot that cannot update part of the system creates false coverage, so coverage is part of the review.
Pairs with: Supply-chain controls, GitHub Actions
Observability & incident response
Useful observability narrows the search during development and incidents by connecting service behavior to traces, metrics, and logs. This section also covers what happens after the alert fires.
OpenTelemetry
OpenTelemetry is the instrumentation layer we usually standardize on. Its vendor-neutral traces, metrics, and logs make it possible to change backends without rewriting application instrumentation.
Pairs with: Google Cloud Observability, Grafana + Prometheus
Google Cloud Observability
GCP’s operations suite (Trace, Logging, Monitoring) is the low-overhead starting point on Google Cloud: structured logs, log-based metrics, dashboards, SLO tracking, and uptime checks with native integrations for Cloud Run and GKE. We use it as the default until query or retention requirements justify a different backend.
Pairs with: OpenTelemetry, PagerDuty
Grafana + Prometheus
When dashboards need to pull from multiple data sources or you run multi-cloud, Grafana earns its place, usually with Prometheus as the metrics backend behind it. On single-cloud GCP, the native suite gets you there with less overhead.
Pairs with: OpenTelemetry, Datadog
Sentry
Sentry connects application exceptions with stack traces, breadcrumbs, and release information, which can make reproduction and triage more direct.
Pairs with: Datadog, Google Cloud Observability
Datadog
The right call when your observability needs outgrow native tooling, complex APM, cross-service dependency maps, and anomaly detection across hundreds of services. Powerful, but it’s a real line item. We scope it tightly and make sure you’re using what you’re paying for.
Pairs with: OpenTelemetry, Sentry
PagerDuty
PagerDuty handles escalation, on-call schedules, and incident routing when a team needs more structure than a shared notification channel. It answers who owns this now, not what is happening.
Pairs with: Google Cloud Observability, Datadog
Security & access
Security controls are easier to maintain when they are part of the normal delivery workflow and enabled by default.
Workload identity
Services authenticate to cloud APIs with their own identity, and CI gets short-lived credentials through OIDC instead of stored service-account keys. The credential that can’t leak is the one that never existed.
Pairs with: IAM as code, GitHub Actions
IAM as code
Defining IAM policies in Terraform keeps role and binding changes versioned, reviewable, and reproducible across environments.
Pairs with: Workload identity, Terraform / OpenTofu
Secrets management
Terraform manages secret containers and access policy while values arrive through a separate controlled path, so state never holds the payloads. On our own machines, our file-guard daemon gates the credential files that CLIs leave on disk.
Pairs with: Workload identity, Supply-chain controls
Supply-chain controls
Actions pinned to SHA, grouped dependency updates, and minimal token scope keep the build’s attack surface small. file-guard extends the same idea to the developer machine: a poisoned dependency goes from reading every secret on disk to touching one file, only if the authorized binary asks.
Pairs with: Dependency automation, Secrets management
Cloud IAP
Cloud IAP puts internal tools behind identity-aware access. It is useful when access policy should follow the user rather than depend only on a network perimeter.
Pairs with: Workload identity
Cloud Armor (WAF)
Rate limiting, geo-blocking, and OWASP rule sets applied at the edge before traffic hits your services. We codify the policies in Terraform so your WAF config is reviewed and versioned like everything else.
Pairs with: Cloud IAP
DMARC / SPF / DKIM
DMARC, SPF, and DKIM reduce domain spoofing when they are configured and monitored together. Our dns-auditer runs these checks daily across every domain in its config and opens or closes GitHub Issues as posture fails and recovers.
Pairs with: Supply-chain controls
Patterns
Ways of building rather than products you can buy. The entries in the other sections are how we implement them.
Event-driven architecture
Queues, topics, and asynchronous workers can isolate workloads and keep a spike in one path from cascading through the rest of the system. We introduce them where the operational tradeoff is justified.
Pairs with: Durable execution, Scaling paths
Durable execution
Idempotency, bounded retries, deduplication, and replay make important workflows safe to depend on. aipm’s Durable Objects serialize per-thread updates so it can never send the same nudge twice; a client platform’s workers run autonomous reconciliation sweeps on the same rules.
Pairs with: Event-driven architecture, pg-boss
Multi-tenancy
Tenant scope enforced on the server, not trusted from the client. taktiko maps subdomains to tenants and runs every mutation through a tenant-scoped layer that checks permissions and writes an audit row.
Pairs with: Convex, IAM as code
GitOps
A way of operating rather than a tool: desired state lives in version control and automation reconciles the running system to match. We implement it with ArgoCD on Kubernetes and with plan-and-apply workflows elsewhere.
Pairs with: ArgoCD, Terraform / OpenTofu
Scaling paths
Stateless services and autoscaling cover the app tier; read replicas, connection pooling, and carefully chosen consistency boundaries cover the data tier. We scale the bottleneck that exists, not the one a diagram imagines.
Pairs with: Kubernetes, Event-driven architecture
Caching & edge delivery
CDN caching, browser cache headers, Brotli for static assets, application caches, and prerendering where each layer has a clear invalidation strategy. The pattern earns its complexity only when the invalidation story is written down.
Pairs with: Cloudflare Workers, Cloud Run