Company
Technology Stack
We choose tools based on what they enable in regulated, production-grade software — not familiarity or hype. Here is what we use and why.
How We Evaluate Technology
Every tool in our stack was chosen to answer a specific requirement: security boundary control, compliance auditability, operational manageability, or developer reliability. We prefer managed services over self-managed infrastructure when it reduces attack surface and maintenance burden without sacrificing control.
For regulated industries — healthcare, legal, compliance-driven organizations — technology decisions have compliance implications. Where a service lands in a HIPAA BAA matters. What a database logs by default matters. Whether a framework exposes data server-side or client-side matters. Our stack choices reflect those constraints.
We are not dogmatic about stack. If a project requires different tools, we use the right ones and document why. What follows is what we reach for by default and what has earned that position.
Next.js 16
Web FrameworkWhy we use it
Next.js 16 ships with React 19, the App Router, and React Server Components — which means rendering logic, data fetching, and sensitive operations happen on the server by default. For regulated applications, this matters: PHI and confidential data never reach the browser unless explicitly passed. Server-side rendering also improves performance and SEO without client-side data exposure.
Trade-offs and constraints
Next.js introduces deployment constraints — it requires a Node.js runtime, which limits some edge deployment options. We run it on AWS Amplify and Lambda-backed environments where full SSR control is preserved.
React 19
UI LibraryWhy we use it
React 19 brings native support for async components, improved Suspense boundaries, and the Actions API for form handling. These primitives simplify building complex, data-driven interfaces without additional state management libraries. For regulated industries, React's component model also makes it straightforward to enforce access-conditioned rendering — components receive only the data they are permitted to render.
Trade-offs and constraints
React 19 is newer and some third-party libraries haven't fully adopted it yet. We evaluate library compatibility carefully on each project and maintain conservative upgrade cycles for production systems.
TypeScript
LanguageWhy we use it
TypeScript catches entire categories of bugs at compile time — wrong data shapes, missing fields, incorrect function signatures. For regulated industries where data integrity matters, this is not a preference but a standard. TypeScript also makes codebases more maintainable across team boundaries: types document intent, IDE tooling surfaces errors immediately, and refactoring is safer when the compiler validates changes.
Trade-offs and constraints
TypeScript adds upfront overhead to project setup and requires discipline to use correctly — `any` usage undermines its benefits. We enforce strict mode and review type usage in code review.
Tailwind CSS 4
StylingWhy we use it
Tailwind CSS eliminates the complexity of managing CSS files across large applications. Styles are co-located with components, making it easy to understand what a component looks like without switching files. Tailwind v4's native CSS-based configuration removes the need for a separate config file and integrates cleanly with Next.js's build pipeline.
Trade-offs and constraints
Tailwind produces verbose class names in JSX. For teams unfamiliar with utility-first CSS, there is a learning curve. We use consistent patterns (component extraction, Tailwind's @apply where appropriate) to keep markup readable.
AWS (Amazon Web Services)
Cloud InfrastructureWhy we use it
AWS is the dominant cloud provider for regulated industries — it publishes HIPAA-eligible service lists, maintains SOC 2 and ISO certifications, and signs BAAs for healthcare workloads. The breadth of HIPAA-eligible services (S3, DynamoDB, Lambda, Bedrock, SES, and more) means we can build full-stack regulated applications without leaving the AWS perimeter. AWS also provides the most mature tooling for compliance logging (CloudTrail, CloudWatch, AWS Config) and identity management (IAM, Cognito).
Trade-offs and constraints
AWS has significant surface area and complexity. We use managed services where possible to reduce the operational burden and lean on Infrastructure as Code (CDK, Amplify) to keep environments reproducible and auditable.
AWS Bedrock
AI / Machine LearningWhy we use it
Bedrock provides access to foundation models — including Anthropic's Claude — through a managed AWS API. Critically for regulated industries, Bedrock does not train on your data, keeps inference within AWS's security boundary, and is covered under AWS's HIPAA BAA. This allows AI capabilities to be deployed in HIPAA-compliant architectures without routing sensitive data to third-party AI providers. Bedrock also supports Knowledge Bases for RAG (retrieval-augmented generation), enabling document Q&A systems that keep data within your control.
Trade-offs and constraints
Bedrock's model selection is limited compared to using provider APIs directly. Latency can be higher than direct API calls. For use cases requiring the very latest models or specialized capabilities, we evaluate direct integrations with appropriate security controls.
Amazon DynamoDB
DatabaseWhy we use it
DynamoDB is a fully managed, serverless NoSQL database with predictable single-digit millisecond performance at any scale. For regulated applications, DynamoDB's managed nature means no database infrastructure to patch, no server maintenance, and encryption at rest enabled by default. DynamoDB's fine-grained access control via IAM policies supports least-privilege data access at the record level — useful for multi-tenant systems where tenant isolation is a compliance requirement.
Trade-offs and constraints
DynamoDB requires careful access pattern planning upfront — it does not support ad-hoc queries well. Applications with complex reporting requirements or frequently changing query patterns often need a complementary data store (S3 + Athena, Aurora) for analytics workloads.
AWS Lambda
ComputeWhy we use it
Lambda's serverless execution model eliminates server management overhead and provides automatic scaling without capacity planning. For regulated workloads, Lambda's execution isolation (each invocation is an isolated environment) reduces the blast radius of potential compromises. Lambda integrates natively with IAM for fine-grained permissions and with CloudTrail for invocation logging — both relevant to SOC 2 and HIPAA technical safeguard requirements.
Trade-offs and constraints
Lambda cold starts can impact latency-sensitive applications. Execution time limits (15 minutes) and memory constraints require architectural consideration for long-running processes. We use provisioned concurrency for latency-sensitive paths and step functions for workflows that exceed execution limits.
AWS Cognito
AuthenticationWhy we use it
Cognito provides managed authentication and user management with HIPAA BAA coverage. It handles the security-critical elements of authentication — secure token issuance, MFA, password policy enforcement, and session management — without requiring custom implementation of these mechanisms. For regulated applications, using a managed, audited authentication system reduces the attack surface compared to custom auth.
Trade-offs and constraints
Cognito has UX limitations — its hosted UI is functional but not highly customizable. For applications requiring complex auth flows or highly branded login experiences, we use Cognito as the underlying token authority while building custom UI flows.
AWS Amplify
Deployment PlatformWhy we use it
Amplify Gen 2 provides a managed CI/CD and hosting platform for Next.js applications with full SSR support. It integrates with AWS services natively and supports environment-based configuration for dev/staging/production workflows. For teams without dedicated DevOps, Amplify significantly reduces the infrastructure management burden while maintaining access to the full AWS service ecosystem.
Trade-offs and constraints
Amplify adds a layer of abstraction over underlying AWS services, which can obscure what's running when issues arise. Environment variable handling has platform-specific requirements (no AWS_ prefix variables in Amplify SSR runtime). We document these constraints and test deployment configurations carefully.
Questions About Our Architecture Approach?
If you are evaluating vendors or want to understand how these technology choices apply to your specific requirements, we are glad to discuss it.
Request an Architecture Review