launch.ist
Sign in Start free

Our Technology Stack

At launch.ist we use the right tool for the job rather than defaulting to what’s familiar. Our engineers work across the stack, so the architecture choices and the implementation choices stay coherent. Here is an overview of the technologies we work with, and when we reach for each.

Backend Development

  • Go: Our default for efficient, concurrent network services and microservices, where performance and low resource use matter.
  • Python: Used for rapid development with FastAPI, data work, and LLM integration. Python code we ship goes to production held to the same standard as everything else.
  • Node.js: We continue to support existing Node.js projects, including NestJS with TypeScript and GraphQL, though new backend work generally goes to Go or Python.

Databases

  • PostgreSQL: Our default for transactional applications that need data integrity, run under CNPG on our platform with streaming replication and backups. We also use its vector capabilities for AI-related work.
  • Valkey: For caching and ephemeral state.
  • FerretDB: Where a document-style interface is the better fit, backed by Postgres.

Platform & DevOps

  • Isolated Kubernetes: Every project runs in its own namespace, or a dedicated cluster where load or compliance requires it. No shared production infrastructure.
  • GitOps (Flux): Push to main and it deploys, with the test suite as the gate.
  • Containers: Services are containerized; we use dev containers so environments are reproducible across the team.
  • Platform catalogue: Postgres (CNPG), Valkey, MinIO, NATS, OpenBao for secrets, and Grafana for logs, metrics, and alerting — deployed from the catalogue, not improvised per project.

API Development

  • RESTful APIs: The default for most web service integrations.
  • GraphQL: When clients need flexible querying and want to avoid over-fetching.
  • gRPC: For low-latency service-to-service communication, particularly between Go and Python services.

LLM Integration

  • LLM vendor APIs (Anthropic, OpenAI): Integrated where a project needs them, with model versions pinned the same way we pin library versions.
  • Private / self-hosted models: Used where privacy or data-residency requirements call for keeping inference in-house.

Our priorities are flexibility to fit each project, efficient use of resources, and stable, well-supported choices that hold up over the long term rather than ones that are merely current.