Method / How We Build
Sprout's technology choices aren't a dogma. They're a curated default set. React and TypeScript for web. Next.js for most frontends. Kotlin and Swift for native mobile, Flutter where cross-platform compounds. Python, Node.js, and Go on the backend. PostgreSQL, Redis, and event-driven platforms for data. Python + frontier-model APIs (Anthropic, OpenAI) with ISO/IEC 42001-aligned governance for AI. AWS and GCP for infrastructure. The stack is chosen per product, but governed by the practice, so every engagement benefits from what we've learned across the last 200+.
Every services firm claims “we pick the right tool for the job.” Most then default to whatever their team happens to know best. Sprout has a curated default stack: the technologies we've shipped repeatedly, across 200+ engagements, with patterns our practice actually knows how to operate. When an engagement needs something outside the default (a client's existing platform, a niche requirement, a regulated-industry constraint), we scope in the new technology explicitly, and we're honest about our familiarity curve. The default is what scales; the exceptions are where we commit to learning quickly.
Signature Visual
A vertical stack diagram showing Sprout's defaults at each architectural layer (frontend, mobile, backend, data, AI/ML, infrastructure) with named tiles, version constraints, and a sidebar documenting the exception protocol for client-specific stack requirements. Engineering-documentation aesthetic. Coming soon.
Four principles that keep the stack a working tool rather than a dogma.
Every engagement starts with Sprout's default stack. When the product, the client's existing systems, or a regulatory requirement pushes us off the default, we document the exception and the rationale. Exception framework is part of the scope.
We're polyglot because different layers have different best tools. Node.js is excellent for product APIs; Python is better for data work; Go is better for performance-critical services. We pick per service, not per engagement.
We run small experiments with emerging technology (new frontier models, new frameworks, new architectures) in low-risk areas to calibrate our defaults. We update the core defaults only when the new tool has proven itself across multiple engagements.
Some stacks are outside Sprout's default: legacy Java enterprise monoliths, mainframe modernization, specific vendor ecosystems. We're honest when an engagement would push us into unfamiliar territory. The client needs to know the familiarity curve, not discover it mid-project.
The six layers and the technologies we default to at each.
React · Next.js (App Router preferred) · TypeScript · Tailwind CSS. Edge-runtime aware for performance-critical routes. Headless CMS integration via Payload / Sanity / Contentful depending on product.
Native iOS (Swift + SwiftUI) · Native Android (Kotlin + Jetpack Compose) · Flutter for cross-platform when shared logic compounds. Picked per product.
Node.js + TypeScript for product APIs · Python for data and ML · Go for performance-critical services. Frameworks: Express/Fastify for Node; FastAPI for Python. Polyglot per service.
PostgreSQL (OLTP default) · Redis (cache + queues) · Kafka or equivalent event bus · dbt + warehouse (BigQuery / Snowflake) for analytics. CDC where warranted.
Frontier models via API (Claude, OpenAI, Google) for most engagements · Python + PyTorch for bespoke models · pgvector / Pinecone / Weaviate for retrieval · internal eval-harness tooling for production AI.
AWS primary · GCP where specific services warrant · Terraform for IaC · Docker + Kubernetes for container workloads · OpenTelemetry + observability tooling (Grafana / Datadog-equivalent).
Stack choices that have held up across Sprout's public portfolio.
Sprout's default stack has been the baseline across public portfolio engagements including telecom decision intelligence, agritech platforms, digital health, fintech, maritime logistics, retail analytics, UMKM commerce, and smart agriculture. Ventures span multiple years of production operation with the underlying technology decisions still compounding.
Sprout's default stack (React/Next.js, native + Flutter mobile, polyglot backend, PostgreSQL-first, frontier AI APIs, AWS/GCP) aligns with the technology choices at leading product-engineering firms globally. This is deliberate. Engineering conservatism in stack choices is a quality signal, not a lack of ambition.
Each layer of Sprout's stack has documented compliance-architecture patterns: PostgreSQL with row-level access controls for UU PDP; event streaming with audit-log semantics for OJK; observability wired for BSSN incident reporting; AI-governance aligned to OJK April 2025 and ISO/IEC 42001. Compliance is a property of the stack, not a retrofit.
Lessons from running Next.js App Router in production across multiple engagements. Server components, streaming, edge-runtime boundaries: what held up, what we had to work around.
The decision framework for when to build on frontier-model APIs (Claude, OpenAI) vs. when a bespoke model earns its place. Cost, latency, specificity, and the evaluation harnesses that make both paths defensible.
Why Sprout is polyglot at the service level, not just the engagement level. The decision rules for when each language is the right default, and the pattern library that makes the polyglot model operationally sane.
Tell us what you're building: the product, the scale horizon, the integration surface, the regulatory context. We'll propose a stack, explain the reasoning, and flag any areas where the engagement would push us off Sprout's default. Transparent about familiarity curves. Written in the scope, not discovered in sprint two.
Start a project