Our Engineering Culture

Welcome aboard! We’re excited to have you join our team. We’re a small, focused development team building production-grade SaaS applications and Shopify apps. Our engineering culture is built on four core principles:

The Four Rules

  1. Predictability - Every endpoint follows the same pattern, every component has the same structure. When you’ve seen one, you’ve seen them all.
  2. Readability - Code should tell a story. Anyone should be able to understand what’s happening without being an expert.
  3. Simplicity - We favour minimal dependencies and clear separation of concerns over clever abstractions.
  4. Upgradability - We version our APIs, keep business logic in services, and design for change.

We prioritise shipping reliable features quickly over perfect architecture. Our users depend on us, so we emphasise testing, monitoring, and clear documentation.

Tech Stack Overview

We support two common stacks depending on the project:

  1. Python + React: FastAPI backend, React/Next.js + TypeScript frontend with Tailwind CSS.
  2. Full TypeScript/JavaScript: Node.js backend (NestJS/Fastify/Express), React/Next.js + TypeScript frontend with Tailwind CSS.

Typical components:

  • Backend: FastAPI (Python 3.14) or Node.js (NestJS/Fastify/Express)
  • Frontend: React 18+ with TypeScript (often Next.js) and Tailwind CSS
  • Database: PostgreSQL 15+
  • Caching/Queues: Redis
  • Background Jobs: Celery (Python) or queue workers such as BullMQ (Node.js)
  • Infrastructure: Docker + Docker Compose (local), Railway/Cloud66 (production)
  • Cloud: AWS services where needed (S3, SES, etc.)

Key documentation:

Essential Reading: Style Guides & Best Practices

These guides will help you ask better questions, write better code, and collaborate more effectively:

Communication & Collaboration

General Coding Philosophy

Python Style Guides

JavaScript/TypeScript Style Guides

Code Review & Quality

Security Best Practices

These resources complement our internal standards and will help you grow as a developer. We especially recommend reading “How To Ask Questions The Smart Way” as it will help you get better support from the team and the wider developer community.

First Day Checklist

Accounts & Access

  • GitHub account added to organisation
  • Slack workspace invitation accepted
  • AWS console access (if needed)
  • Railway/Cloud66 dashboard access
  • pgAdmin or database GUI tool installed
  • Postman account created and team workspace joined
  • Added to relevant email groups

Slack Channels to Join

Please ask HR to Add you to our Slack Channels (if not already)

  • Use threads to keep conversations organised
  • Don’t hesitate to ask questions - we’re here to help!

Tools to Install

Complete setup instructions are in local-setup.md. You’ll need:

  • Python 3.14
  • Node 22.21.0
  • Docker Desktop
  • VS Code (or your preferred editor)
  • Git
  • pgAdmin or another PostgreSQL client
  • Postman (for API testing)

Repository Access

You should have access to:

  • Main application repository
  • Infrastructure repository (if separate)
  • Internal tools repository

Clone the main repo and follow the setup guide in local-setup.md.

First Day Goals

By end of day one, you should:

  • Have local development environment running
  • Successfully run the application locally
  • Run all tests successfully
  • Understand the system architecture (see architecture-overview.md)
  • Know where documentation lives

Editor & Tooling Setup

See ../06-tooling/editor-setup.md for:

  • VS Code recommended extensions
  • Linter configuration
  • Pre-commit hooks setup
  • Debugging configuration

Also review ../06-tooling/pre-commit-hooks.md for setting up automated code quality checks.

First Week Goals

By end of week one, you should:

  1. Environment Fully Working

    • Local dev environment runs smoothly
    • Can run tests and migrations
    • Pre-commit hooks installed and working
  2. First PR Merged

    • Pick up a “good first issue” from the backlog
    • Follow our development workflow (see ../03-workflows/feature-development.md)
    • Get code reviewed and merged
  3. Documentation Read

    • Read all of 01-getting-started/
    • Skim 02-standards/ (you’ll reference this constantly)
    • Understand our Git workflow (03-workflows/git-workflow.md)
    • Know our PR process (03-workflows/pr-process.md)
  4. First Pairing Session

    • Shadow a team member on a feature
    • Understand how we debug issues
    • Learn our deployment process

Where to Get Help

Team Members

  • Technical Lead - Architecture decisions, complex technical problems
  • Senior Developers - Code reviews, design discussions, best practices
  • DevOps/Infrastructure - Deployment, infrastructure, CI/CD issues
  • Product Manager - Feature requirements, priorities, user context

Documentation

  • This playbook (docs/) - Standards, workflows, runbooks
  • API Documentation (docs/api/endpoints.md) - API contracts
  • README - Project-specific setup and context
  • Code comments & docstrings - Inline documentation

Common Resources

Learning Path

Week 1-2: Foundations

  • Set up environment
  • Read core documentation
  • Make small PRs (bug fixes, minor features)
  • Learn our Git workflow and standards

Week 3-4: Contributing

  • Pick up medium-sized features
  • Write tests and documentation
  • Participate in code reviews
  • Understand deployment process

Month 2: Ownership

  • Own features end-to-end
  • Design database schemas
  • Make architectural suggestions
  • Help onboard the next new team member

Development Philosophy

We Value

  • Shipping early and often - Small, incremental improvements over big bang releases
  • Clear communication - Over-communicate in async environments
  • Testing - If it’s not tested, it’s broken
  • Documentation - Future you (and your teammates) will thank you
  • Code reviews - Learn from each other, maintain quality
  • Simplicity - Solve today’s problems, not hypothetical future ones

We Avoid

  • Premature optimisation - Make it work, make it right, then make it fast
  • Clever code - Prefer obvious over clever
  • Large PRs - Keep changes small and reviewable (<400 lines)
  • Undocumented decisions - Capture context in code comments and docs

Performance Standards

  • API Response Time: <500ms for all endpoints (see ../02-standards/api-patterns.md)
  • Test Coverage: 80% minimum
  • PR Review Time: Within 24 hours
  • Deployment Frequency: Multiple times per day to staging, daily to production

Next Steps

  1. Complete the setup in local-setup.md
  2. Read architecture-overview.md
  3. Review ../02-standards/code-standards.md
  4. Pick up your first issue!
  5. Set up your editor with linting and pre-commit hooks (see ../06-tooling/)

Welcome to the team! Let’s build something great together. 💪