What job does this layer own?
Purpose and boundariesDefine the users, domain rules, system-of-record responsibilities, interfaces, and non-goals before choosing the product or framework.
Technology choices by the role they play in the system.
Most projects start with applications, data stores, vendor platforms, and cloud constraints already in place. We decide what to keep, connect, replace, or isolate by looking at the workflow, source of truth, failure behavior, recovery needs, and who will own the result.
01Applications and experience
Application work may use .NET, Python, Ruby, JavaScript, TypeScript, iOS, or Android for portals, dashboards, APIs, internal tools, and focused mobile workflows. The choice follows the users, domain rules, integration boundaries, and the team that will support it.
Explore web application engineering02Data and state
Operational databases, Databricks, Snowflake, lakehouses, and warehouses serve different purposes. We assign clear roles for transaction state, ingestion, analysis, reporting, access, provenance, and recovery before selecting the architecture.
Explore data platforms03Integrations and workflow
GraphQL, REST, SOAP, Azure Logic Apps, scheduled jobs, queues, and message buses have different coupling, timing, retry, ordering, and replay behavior. We choose the pattern around the business handoff rather than a preferred connector.
Explore systems integration04Enterprise platforms
Salesforce, Oracle NetSuite and custom RESTlets, SAP Fieldglass, and vendor APIs sit inside customer, finance, workforce, timesheet, approval, and reporting processes. We first establish which platform owns each record and how exceptions return to an operator.
Review enterprise integration work05Cloud and delivery
Azure, AWS, Google Cloud, Docker, self-hosted, and hybrid environments each change deployment, identity, observability, rollback, and recovery decisions. We design for portability when it improves operating fit and ownership.
Explore architecture and reliability06Distribution and ownership
Open source packages, containers, self-hosting, versioning, documentation, upgrades, backups, restoration, and contribution boundaries determine whether software can be operated and evolved outside its original project team.
Explore open source and self-hostingControl or relationshipRecord ownerConfirmed state
Read the steps for a complete explanation.
Start with constraints, not a preferred stack.
The decision should explain how the system will behave, how it will be changed, and how the receiving team will operate it—not simply which product is familiar.
What must stay correct when work is interrupted?
Data and failureChoose around integrity, timing, duplicates, retries, concurrency, reconciliation, replay, backfill, and recovery—not only the successful path.
How will the team see and change it?
Operation and releaseAccount for identity and access, secrets, observability, environment promotion, verification, rollback, restoration, and the people responsible for each action.
What happens after handoff?
Ownership and changeConsider team experience, licensing, portability, documentation, upgrade paths, replacement cost, and how architecture decisions will be revisited.
See the delivery approach