Skip to main content
Our engineering process is designed to be calm, clear, and sustainable.
We optimize for steady momentum, thoughtful decisions, and a premium developer experience that reflects the same principles as our products.

​
1. Guiding principles

  • Clarity first
    Write code, comments, and documentation that a future you can understand without stress.
  • Small, meaningful steps
    We prioritize incremental progress over large, risky batches of work.
  • Predictability over speed
    Reliable pacing beats rushed execution.
  • Empathy in collaboration
    Reviews and discussions are always kind, respectful, and constructive.
  • DRY, not forced abstraction
    Reuse thoughtfully. Avoid premature abstraction that increases complexity.

​
2. Workflow overview

​
Step 1: Define the work

Every task begins with a simple, shared understanding:
  • What problem are we solving?
  • Who benefits from this?
  • What does success look like?
This is documented in a GitHub Issue using the official template.

​
Step 2: Plan the approach

Before writing code:
  • Outline the intended solution (short text or diagram)
  • Confirm reuse opportunities in packages/*
  • Verify consistent design patterns with the design system
  • Validate feasibility for both web and future mobile paths

​
Step 3: Create a feature branch

git checkout -b feat/short-description
Use:
  • feat/ for new features
  • fix/ for bugs
  • chore/ for cleanup
  • refactor/ for structural changes
  • docs/ for documentation updates

​
Step 4: Implement calmly

  • Use TypeScript everywhere
  • Keep files small and focused
  • Use absolute imports
  • Reuse UI + utilities from packages
  • Add comments where clarity matters
  • Keep PRs minimal and cohesive

​
Step 5: Test

  • Write lightweight unit tests for utilities
  • Add simple integration tests for core flows
  • Avoid excessive mocking
  • Ensure UI does not break on common screen sizes
  • Verify ingestion or parsing code against sample real-world inputs

​
Step 6: Submit a pull request

A great PR includes:
  • A clear summary
  • Screenshots or screen recordings for UI changes
  • Notes on decisions made
  • Any follow-up tasks (if needed)
Reviewers focus on:
  • Clarity
  • Maintainability
  • Alignment with conventions
Not nitpicking.

​
Step 7: Review & merge

Once approved:
  • Squash merge into main
  • Ensure CI passes
  • Confirm that documentation stays accurate

​
8. Linear: Tracking & planning

Linear is the primary tool for planning and tracking engineering work at Ignition Labs.
It provides a calm, structured workflow that aligns with our engineering values.

​
How we use Linear

  • All engineering tasks are created and tracked in Linear
  • Each issue includes a clear title, summary, motivation, and acceptance criteria
  • Issues are categorized as Feature, Improvement, Bug, Chore, or Research
  • Labels remain minimal (web, mobile, ui, ingestion, backend) to avoid clutter
  • Sprints represent focused 1–2 week periods of progress
  • Projects are used only for multi-step or multi-sprint initiatives

​
Connecting to GitHub

  • Every pull request should link to a Linear issue
  • Linear automatically updates issue status as PRs open, review, and merge
Linear keeps work organized, visible, and steady, without pressure or noise.

​
3. Release & deployment

​
Preview environments

Every PR deploys automatically to Vercel for preview.
This helps reviewers understand changes in context.

​
Production deploys

  • Only merged PRs deploy
  • Documentation updates must accompany relevant feature changes
  • Keep releases frequent and small to reduce risk

​
4. Documentation standards

Documentation should be:
  • Clear and minimal
  • Updated alongside features
  • Written in calm, human language
  • DRY across the monorepo
Types of documentation:
  • Product behavior docs (in /docs/apps/*)
  • Engineering docs (in /docs)
  • Package-level docs (in /packages/*/README.md)
  • Architecture docs (in /docs/architecture)

​
5. Quality & maintenance

​
Code quality

  • Prefer composition over deep inheritance
  • Favor pure functions where possible
  • Keep components lean and readable

​
Refactoring

Refactor when:
  • Code becomes difficult to understand
  • A feature requires restructuring
  • Repeated patterns emerge organically

​
Tech debt

We track tech debt in GitHub Issues and review monthly.
It should never accumulate to the point of creating anxiety or instability.

​
6. Communication

Communication at Ignition Labs values:
  • Clarity
  • Kindness
  • Calm consistency
  • Respect for each other’s time
Async updates are preferred:
  • GitHub issues
  • Pull request descriptions
  • Roadmap updates
Synchronous calls are used only when needed.

​
7. Final note

The goal of this process is simple:
Build high-quality products without burnout, chaos, or confusion.
A calm engineering environment creates calm, trustworthy financial tools. Ignition Labs builds with intention, one clear step at a time.