How to choose a product's technology stack

Start with the domain, risk, and who will maintain the application. Familiar tools can reduce operational cost; a new tool needs to justify migration and learning.

Exercise: choose two options and compare integration with the current system, team availability, operational cost, and how easily they can be tested and recovered.

For a transactional system, compare validation, authentication, jobs, and maintenance before languages. Ruby on Rails provides web application conventions; Node.js and TypeScript can reuse a team's existing ecosystem knowledge.

REST, GraphQL, and gRPC are contract choices, not a modernity ranking. Consider consumers, query patterns, compatibility, and observability.

A public page needs suitable loading and indexing. An authenticated dashboard may prioritize forms, state, and queries. That difference guides frontend rendering and organization.

Choose state management for the problem: local interface state is different from remote data. Include keyboard navigation, validation, and journey tests in the decision.

Start with data shape and the guarantees the process needs. Relational databases support relationships and transactions; caching, search, and documents may need specialized components.

Before adding another database, check modeling, indexes, and queries. In BI, define the business question and metric provenance so data errors do not become convincing dashboards.

Separate responsibilities by domain and preserve module contracts. A modular monolith may be enough; distributed services introduce networks, partial failures, and operational work.

Record the reasoning in an architecture decision. DDD, CQRS, and other patterns help when solving a concrete problem, not when imposed on every application.

The platform needs repeatable deployment, observation, and recovery. Compare VPS and cloud based on operational capacity and product risk, not just server price.

Kubernetes is not a SaaS prerequisite. Containers, pipelines, tested backups, and access boundaries usually come first. The Harness CI/CD platform is different from Harness Engineering for agents.

Choose the engine for the experience, target devices, and content pipeline. A browser-based 2D experience may suit Phaser; web 3D may use Three.js. Unity, Unreal, and Godot address other runtime, tooling, and distribution needs.

Consider download size, memory, touch input, and accessibility from the prototype. Blender, spritesheets, and asset formats are part of the stack because they affect loading and final quality.

Existing platforms can reduce initial work on support, CRM, and automation. Deployment still requires process mapping, permissions, integrations, and maintenance ownership.

Before customizing, test a full flow with users: contact intake, assignment, lookup, reply, and closure. Confirm where data lives and how to export it.

The model is only one part of an agent. Compare tools, context retrieval, permissions, evaluations, and cost per completed task. A harness organizes these components for a specific domain.

n8n can coordinate a defined process; an agent can choose the next step when flexibility is necessary. Start with the simplest path and test before increasing autonomy.

Specifications define outcomes, tests protect rules, and evaluations check AI behavior. Use them to provide review evidence, not to increase document count.

The coding tool may change. Acceptance criteria, repeatable commands, and recorded decisions should stay available to the next person.

Finish with a small practical trial. Run the core flow, simulate a failure, and record what recovery required. That evidence is more useful than feature lists.

Exercise deliverable: a short decision covering context, alternatives, the chosen option, limitations, and a trigger for revisiting it. You do not need to master every technology in this reference to choose well.