Workflows, stack choices, guardrails, and design decisions behind Diversio Engineering.
The technologies and foundations we rely on, organized by the part of the engineering system they support.
The core application stack favors mature backend ergonomics, typed frontend workflows, and a relational data model that holds up under product complexity.
Why it fits: This combination gives us a practical balance of shipping speed, reviewability, and long-lived application maintainability across backend and frontend work.
Django 
Python 
React 
TypeScript 
PostgreSQL Frontend work sits on top of a shared design system, with design exploration and implementation moving through the same reusable component language instead of one-off page decisions.
Why it fits: A durable UI layer improves consistency, keeps review conversations focused on behavior instead of re-litigating presentation from scratch, and lowers the cost of iteration across multiple product surfaces.
Diversio Design System 
Figma React TypeScript Infrastructure is treated as part of the engineering system, with managed cloud primitives, infrastructure as code, and orchestration that stays legible across many stacks and environments.
Why it fits: The goal is not novelty. It is repeatability, safer change management, and infrastructure work that can be reasoned about with the same care as product code.
AWS 
Terraform 
Terragrunt CI and release automation are part of the operating model, not afterthoughts. Different repositories lean on different automation surfaces depending on how they deploy and what they need to validate.
Why it fits: Keeping build, packaging, and deployment paths explicit makes change safer, easier to audit, and easier to recover when something drifts.
GitHub Actions 
CircleCI Analytics work is treated as a real engineering surface, not a bolt-on. Events, data flow, and implementation patterns need to stay clear enough that teams can trust what gets measured.
Why it fits: Instrumentation is only useful when it stays close to the product behavior it describes and when engineers can evolve it without turning the data model into folklore.
Mixpanel PostgreSQL Daily engineering work depends on more than the application stack. Editors, terminals, local containers, remote sandboxes, and quick connectivity tools all affect how quickly an engineer can understand a problem and move through it.
Why it fits: We embrace open tools that reduce friction in the daily loop: editor choices that stay fast, terminal workflows that make session handoff easier, sandboxes that isolate risky work, and connectivity tools that help expose or test systems without heavyweight setup. cmux has become the primary daily driver in that environment, with Ghostty still very much in the mix.
cmux 
Zed 
Pi 
Docker 
sandboxes.cloud 
ngrok We invest in tools that improve context recovery, review quality, API visibility, and the speed at which repeated engineering work becomes reusable instead of staying trapped in local setup.
Why it fits: Open-source tooling earns its place when it makes daily engineering work simpler, easier to review, and easier to share across the team. Docs, request definitions, local workflow tools, and agentic helpers all benefit from staying close to the code they support.
Bruno 
Astro 
uv 
Ruff Agentic Tools Not every useful engineering task starts as product code. We also lean on notebooks and interactive Python workflows for one-off analysis, data shaping, exploratory debugging, and validating ideas before they harden into more permanent tooling.
Why it fits: These tools reduce friction when the job is to inspect, experiment, or explain a problem clearly. We treat them as practical companions to the main stack, not as second-class workflows.
Google Colab 
Jupyter 
IPython Python 2 highlights in this area.
A unified local workspace, branch-aware worktrees, and shared tooling make it easier to move across product, platform, and tooling work without losing context.
The monolith story and the open tooling docs both reflect the same principle: engineering context should be cheap to recover.
CI and workflow improvements are treated as engineering changes that should be baselined, measured, and explained rather than justified by instinct alone.
Writing and utility docs already reflect a measurement-first posture for CI, delivery, and developer-experience changes.
1 highlight in this area.
GitHub Actions are reviewed as executable infrastructure, with dedicated guardrails that keep workflow changes pinned, auditable, and easier to trust.
The workflow-security docs make the operating model easy to inspect, discuss, and reuse.
1 highlight in this area.
Agentic review tools, wrapper commands, and review memory help reviewers focus on what changed instead of re-reading the same history from scratch.
Marketplace plugins already expose the reusable pieces of this workflow, including review orchestration and structured review memory.
1 highlight in this area.
Short routing docs, deeper runbooks, and first-principles explanations turn repeated engineering pain into reusable system knowledge.
The tools repo already uses repo-local docs, generated deep-doc pages, and a strong “why this exists” style.
1 highlight in this area.
Request collections, docs generation, and reviewable API workflows are kept close to the code so interfaces can evolve with better visibility and less drift.
The Bruno API plugin and related writing show the shape of this approach in the open.
