Technology

Technical decisions that keep data, integrations and releases under control.

The stack should serve the work the system will do after launch: backend logic, frontend and mobile interfaces, API contracts, linked data, background jobs, infrastructure, observability and safer future changes.

Discuss architecture Talk about scope

Stack

Tools chosen for the production job

We balance durable open-source ecosystems with modern delivery tools across backend, frontend, mobile, APIs, data, infrastructure and delivery: Rails, Go, Python, JavaScript, TypeScript, React, Solid.js, SolidStart, Astro, Elixir/OTP, PostgreSQL, Redis, Docker, Linux, cloud infrastructure, REST, GraphQL, tRPC, JSON, linked data and OpenAPI.

Standards

Code that can be operated

Tests, background job visibility, deployment, monitoring, documentation, workflow clarity and failure handling are part of the build from the start.

Architecture

Boundaries named early

Architecture should reduce risk and make change easier. We surface data ownership, API contracts, integration boundaries and migration constraints before they disappear into code.

Backend and APIs
Frontend and mobile
Data and linked data
Docker, Linux and cloud
AI/LLM workflows

Technical calm

Technology decisions should make production easier to live with.

A stack only makes sense if it can be understood, tested, maintained, monitored and changed. The work is not getting data through an API once; it is keeping the flow reliable when volume, failures and edge cases arrive.

Readable architecture

Boundaries, dependencies, data contracts and tradeoffs are named in plain language, not buried in implementation detail.

Production habits

Testing, queues, monitoring, deployment and failure handling are part of the build, not an afterthought.

Room to change

We prefer systems that can evolve through migrations and small releases instead of turning every new need into a rewrite.

We lean on mature ecosystems like Ruby on Rails when that maturity lowers risk, and on modern tools when they solve the problem clearly. The choice follows the production job, not fashion.

Capability map

A capability map organized by the layer that carries the risk.

Each layer names the pressure it tends to carry and the move that resolves it: workflow, UX, API contract, data model, queue, deploy path, infrastructure or AI pipeline.

Backend

Business logic, APIs and distributed systems

Operational symptomProduct logic, permissions or distributed work become hard to reason about.

Risk layerBackend

Production moveName boundaries, simplify flows and make backend ownership explicit.

Ruby on Rails, Go, Python, Elixir/OTP, background jobs, domain boundaries, permissions and production workflows that have to stay understandable.

Rails
Go
Python
Elixir/OTP
Background jobs

Frontend and mobile

Interfaces people can actually operate

Operational symptomPeople avoid the tool, repeat work by hand or lose context in the interface.

Risk layerFrontend and mobile

Production moveTurn repeated work into clear screens, states and operating paths.

JavaScript, TypeScript, React, Solid.js, SolidStart, Astro, mobile-facing flows, admin panels, forms, UX and design systems shaped around repeated work.

JavaScript
TypeScript
React
Solid.js
SolidStart
Astro

API and integration

Contracts between systems

Operational symptomSystems exchange data, but nobody can see what changed, failed or drifted.

Risk layerAPI and integration

Production moveMake contracts, failures and reconciliation visible.

REST, OpenAPI, GraphQL, tRPC, JSON, webhooks, API clients, adapters, marketplace integrations and visible failure handling.

REST
OpenAPI
GraphQL
tRPC

Data and messaging

State, search, queues and synchronization

Operational symptomData moves asynchronously and the business needs trust, replayability and reconciliation.

Risk layerData and messaging

Production moveDesign state, queues and replay paths that production can trust.

PostgreSQL, Redis, NoSQL shapes, Kafka-style event flows, ETL, reconciliation, background processing and data consistency.

PostgreSQL
Redis
Kafka-style events
ETL

Infrastructure

Cloud, Docker and bare-metal Linux

Operational symptomDeploys feel risky, environments drift and production has no calm operating path.

Risk layerInfrastructure

Production moveStabilize deploys, environments, monitoring and rollback paths.

Docker, Linux, NGINX, Puma, SSL, cloud infrastructure, bare-metal servers, deploy paths, monitoring and repeatable releases.

Docker
Linux
Cloud
Monitoring

Knowledge and AI

Structured knowledge, linked data and LLM workflows

Operational symptomExpert knowledge exists, but it is hard to search, reuse, translate, verify or automate.

Risk layerKnowledge and AI

Production moveStructure knowledge so AI, search and QA can reuse it safely.

JSON-LD, Turtle, ontology-shaped content, search metadata, SEO surfaces, AI/ML/LLM pipelines, QA and agentic maintenance.

JSON-LD
Turtle
LLM
SEO

Delivery

Business analysis, documentation and workflow ownership

Operational symptomThe team has activity, but scope, acceptance, risk and ownership are not visible enough.

Risk layerDelivery

Production moveMap workflow, acceptance and ownership close to implementation.

Business analysis, documentation, Scrum or Kanban collaboration, workflow mapping, acceptance paths and communication close to the code.

Analysis
Docs
Scrum/Kanban
Workflow

From layer to delivery

Once the risky layer is visible, the work needs a safe production path.

Technology choices only matter when they become a delivery sequence: map the workflow, validate the risky slice, ship in useful increments, document the decisions and keep production observable after release.

Once the risky layer is visible, the work needs a safe production path.

See the delivery process

Validated slice
Small release
Observable rollout