Tools & Infrastructure

The tools listed are the ones we typically use internally and pay for.

Internal Communication & Collaboration

Slack

Purpose: Primary communication platform

Security Configuration:

• Project channels restricted to squad members only
• Private channels for sensitive discussions
• SSO integration with MFA required
• Guest access disabled for project channels
• Message retention configured per compliance needs
• Integrations limited to approved applications

Notion

Purpose: Internal documentation and knowledge management

Security Configuration:

• Workspace access restricted via RBAC
• Project spaces segmented by client engagement
• Sensitive information in encrypted, access-controlled sections
• SSO with MFA enforced
• Export and sharing controls enabled
• Audit logging active

Linear

Purpose: Project management and issue tracking

Security Configuration:

• Project spaces locked to assigned team members
• No cross-project visibility
• SSO with MFA required
• Audit trail for all changes

Figma

Purpose: Design, diagramming, and prototyping

Security Configuration:

• Project access restricted to assigned team members
• SSO with MFA required
• Sharing limited to team members
• No public link sharing for client work

GitHub

Purpose: Source control (for internal projects; client work uses client repos)

For client engagements, we use client-owned repositories. For internal tools:

Security Configuration:

• Private repositories only
• Branch protection rules enforced
• Required code reviews before merge
• Signed commits where applicable
• SSO with MFA required
• Dependabot for vulnerability scanning

Secure Development Practices

We follow a structured software development lifecycle (SDLC) with security integrated at every stage.

Development Workflow

• Feature branches: All work happens in isolated branches, not directly on main
• Pull requests: Changes require a PR before merging
• Peer review: At least one other engineer reviews every change before it’s merged
• Approval gates: PRs cannot be merged without required approvals

Code Quality

Our CI pipeline enforces quality standards on every pull request:

• Linting: Automated style and formatting checks
• Static analysis: Detection of code smells, complexity issues, and potential bugs
• Type checking: Where applicable, type errors caught before merge
• Test execution: Automated tests must pass before merge

Security in CI/CD

Security checks are automated throughout the pipeline:

Deployment Gates

Code doesn’t reach production without passing through gates:

• All CI checks pass: No deployments with failing tests or security issues
• Required reviews: Human approval before production deployment
• Environment progression: Changes deploy to staging before production
• Rollback capability: Quick rollback if issues are detected post-deployment

Documentation

• Code changes include relevant documentation updates
• Architecture decisions are recorded
• Runbooks maintained for operational procedures

Security & Device Management

JumpCloud

Purpose: Identity provider and MDM

What It Does:

• Centralized identity management
• Device enrollment and compliance verification
• Conditional access policies
• Directory services

SentinelOne

Purpose: Endpoint detection and response (EDR)

What It Does:

• Real-time threat detection
• Behavioral analysis
• Automated response and remediation
• Continuous monitoring

Note: We can use Microsoft Defender for Endpoint or CrowdStrike as alternatives per client preference.

Infrastructure

Cloud Providers

We work in client cloud environments. When we host infrastructure ourselves:

Azure

• Primary cloud provider for internal infrastructure
• Used for Azure Virtual Desktop deployments as well

AWS

• Used for specific client requirements

VPN

Purpose: Secure network connectivity

Options:

• Site-to-site VPN for persistent client network access
• Client VPN for individual connections
• AES-256 encryption
• MFA required for authentication

Infrastructure as Code (IaC)

Purpose: Reproducible, documented, version-controlled infrastructure

We define infrastructure through code rather than manual configuration:

How we use IaC:

• Terraform / cloud-native tools: Infrastructure defined in declarative configuration files
• Version control: All infrastructure code stored in Git with full change history
• Code review: Infrastructure changes go through the same review process as application code
• Automated deployment: Infrastructure provisioned through CI/CD pipelines

Benefits for reliability and recovery:

• Reproducibility: Environments can be rebuilt identically from code
• Documentation: Infrastructure definitions serve as living documentation
• Drift detection: Differences between defined and actual state can be identified
• Rapid recovery: If infrastructure is deleted or corrupted, it can be recreated quickly from the IaC definitions
• Consistency: Development, staging, and production environments stay aligned

Transparency: Architecture diagrams accompany IaC definitions, providing clear visibility into deployed resources and configurations. These can be shared with clients upon request.

Tool Selection Criteria

When we adopt tools, we evaluate:

Working in Client Environments

We can work within your infrastructure using your tools and systems. See Client Environments for details.

Common platforms we’ve worked with: Microsoft 365, Google Workspace, Okta, AWS, Azure, GCP, GitHub Enterprise, GitLab, Jira, Confluence, Snowflake, Databricks.