The Tools We Use — and Why

Why we use it: Our primary LLM for agentic systems. GPT-4o's function calling API and JSON mode make it the most reliable choice for multi-step AI agents that need to interact with external tools and APIs.

Caveats: API-hosted only. For data-sensitive deployments requiring on-premises processing, we evaluate alternatives or implement data filtering at the boundary.

Why we use it: Preferred for document analysis, long-context tasks and situations where constitutional alignment reduces guardrail complexity. The 200k context window handles entire document libraries in a single pass.

Caveats: Available via API. We use Claude 3.5 Sonnet for most workloads and Claude 3 Opus for highest-accuracy requirements.

Why we use it: Our framework for complex AI agent pipelines. LangGraph's state machine model handles branching logic, human-in-the-loop interrupts and parallel agent execution in a way that flat chains cannot.

Caveats: Requires Python runtime. For Node.js-native projects we evaluate Vercel AI SDK agent primitives or custom orchestration.

Why we use it: We choose pgvector for PostgreSQL-native deployments — it keeps vectors co-located with relational data, simplifies infrastructure and avoids an external dependency. Pinecone is preferred for large-scale standalone vector search where query performance at hundreds of millions of vectors is required.

Caveats: pgvector is sufficient for most enterprise RAG systems under 10M vectors. Pinecone becomes cost-effective above that threshold.

Why we use it: Used in voice AI pipelines and transcription systems. Whisper outperforms commercial alternatives on Arabic and French — both critical languages for our Morocco-focused client base — and can be self-hosted for data-sensitive deployments.

Caveats: Self-hosted requires GPU inference for real-time transcription. For lower-volume use cases, the OpenAI API is more economical.

Why we use it: Our primary web framework. One codebase handles all rendering strategies: static generation for marketing pages, server rendering for dynamic data, and React Server Components for performance. The App Router's colocation of data fetching and UI eliminates the waterfall patterns common in older architectures.

Caveats: Best deployed on Vercel for optimal edge functionality, though self-hosting on Docker or Node.js is fully supported.

Why we use it: The most mature component ecosystem available. React 19's concurrent features and Server Actions reduce the client-side JavaScript needed for interactive applications, improving performance and simplifying data mutation patterns.

Caveats: React 19 is in stable release. Some third-party library compatibility should be verified for new projects.

Why we use it: Non-negotiable on every project. Strict TypeScript catches entire categories of production bugs at compile time. It also makes codebase handovers significantly safer — every function, API response and component prop is documented by the type system.

Caveats: Requires TypeScript-literate developers. We enforce strict mode and no implicit any across all projects.

Why we use it: Utility classes eliminate style drift across large codebases. Combined with a design token system, Tailwind makes it possible to maintain visual consistency without a dedicated frontend designer on every sprint.

Caveats: Generates larger HTML attribute lists. Not suitable for projects with strict HTML byte-budget requirements, though purging keeps CSS payload minimal.

Why we use it: Prisma's schema-first approach generates a fully-typed database client. This means database queries have the same TypeScript safety as the rest of the application, and migrations are version-controlled alongside code.

Caveats: Not suitable for projects requiring fine-grained SQL control. For complex reporting queries we combine Prisma with raw SQL via its query engine.

Why we use it: One codebase, two platforms. The Expo managed workflow handles build infrastructure, over-the-air updates and device API access without requiring macOS build machines for every developer. Shared business logic with the web frontend reduces total code volume by 30–50%.

Caveats: Near-native but not pixel-identical to pure native. For apps requiring highly custom animation or platform-specific gestures, Flutter may be more appropriate.

Why we use it: When pixel-perfect custom UI is a requirement, or when cross-platform coverage extending to web and desktop is needed, Flutter's custom rendering engine delivers consistent results across all targets. The Dart language is type-safe and easy to onboard for TypeScript developers.

Caveats: Dart is a smaller ecosystem than JavaScript/TypeScript. Third-party integrations may require custom platform-channel implementations.

Why we use it: Push notifications, crash reporting and remote configuration are commoditised problems. Firebase handles them reliably without requiring custom infrastructure. We use Firebase as a peripheral service, not as a primary backend.

Caveats: Google-hosted only. For projects with data residency requirements, we implement push via APNs/FCM directly or use self-hosted alternatives.

Why we use it: Sharing a language across frontend and backend reduces context switching and enables code reuse for validation schemas, types and utilities. Node.js's event loop model handles I/O-intensive API workloads efficiently.

Caveats: CPU-intensive tasks (image processing, ML inference) are better served by Python or dedicated workers. We use task queues to offload heavy computation.

Why we use it: Our default database for every project. PostgreSQL's ACID guarantees, mature query planner, JSON support and extension ecosystem (pgvector for embeddings, PostGIS for geospatial) make it the safest choice for production data. It has been in active development for 30+ years.

Caveats: Requires thoughtful schema design upfront. For unstructured event streams at very high volume, we evaluate TimescaleDB or a dedicated event store alongside PostgreSQL.

Why we use it: API response caching, session storage and real-time pub/sub messaging all benefit from Redis's sub-millisecond latency. We use Upstash for serverless Redis on Vercel and self-hosted Redis for dedicated infrastructure.

Caveats: In-memory by default. Persistence must be explicitly configured. Not appropriate as a primary data store for compliance-sensitive data.

Why we use it: Docker ensures the development, staging and production environments are identical. GitHub Actions provides the CI/CD pipeline for automated testing, building and deployment — integrated with the repository where code already lives.

Caveats: Container image size requires management. Multi-stage builds keep production images lean.

Why we use it: Vercel's edge network, Incremental Static Regeneration and automatic preview deployments for every pull request reduce deployment complexity to near zero for Next.js projects. Preview URLs enable client review before merging to production.

Caveats: Vercel is optimised for Next.js. For non-Next.js backends or self-hosted requirements, we use Docker on Railway, Render or a dedicated VPS.

Why we use it: Self-hosted n8n means automation workflows run on client infrastructure — data never leaves the organisation's environment. Flat licensing (not per-execution) makes cost predictable at scale. Native LLM nodes for OpenAI and Anthropic are built in, not bolted on.

Caveats: Self-hosting requires infrastructure management. For clients without DevOps capacity, we host and manage n8n as part of the retainer.

Why we use it: The most developer-complete payment API available. Webhooks, subscription billing, payment links and the Customer Portal handle the full commercial lifecycle without custom code. For Moroccan market requirements, we also integrate CMI (Centre Monétique Interbancaire).

Caveats: Not available for Moroccan-domiciled merchants as the primary processor. CMI handles MAD payments; Stripe handles EUR/GBP/USD for international clients.

Why we use it: For projects requiring rapid backend provisioning, Supabase provides a PostgreSQL database, row-level security, auth, file storage and real-time subscriptions in one platform. It eliminates backend boilerplate for data-centric applications.

Caveats: Cloud-hosted by default. Self-hosting is supported but adds operational overhead. Not recommended as the primary backend for large-scale production systems without dedicated infrastructure.

Why we use it: REST for most integrations — its statelessness, cacheability and universal tooling support make it the safe default. GraphQL for data-graph-heavy frontends where clients need flexible querying. All APIs we build are documented with OpenAPI (REST) or GraphQL schema introspection.

Caveats: GraphQL adds query complexity and requires persisted query management at scale. We default to REST and add GraphQL only when the data graph justifies it.