Capabilities
Written for the engineer who has to assess us, not the committee that has to approve us.
Every practice below names its stack and one position we will defend. A capability page without a tradeoff is a brochure.
Product engineering
Long-lived application development for systems that carry revenue and cannot be rewritten every eighteen months.
We build transactional web and API systems in TypeScript, Go and Python, with a bias toward boring, inspectable architecture: explicit domain boundaries, database-level constraints, and idempotent write paths. Test strategy is weighted toward integration coverage against real dependencies rather than unit tests around mocks, because the failures that reach enterprise production are almost always in the seams.
The tradeoff we argue for
We push back on premature microservice decomposition. A well-bounded modular monolith is cheaper to operate at the scale most enterprise teams actually run, and we would rather split a service when the seam is proven than ship a distributed system nobody can debug.
Stack
- TypeScript
- Next.js
- Go
- Python
- PostgreSQL
- gRPC
- OpenAPI
Cloud infrastructure
Provisioned as code, reproducible from an empty account, and documented so your team can operate it without us.
Infrastructure is defined in Terraform with per-environment state isolation and no manual console changes permitted. We build for regional data residency from the first commit rather than retrofitting it under procurement pressure, and we hand over runbooks alongside the modules. Observability is treated as part of delivery scope, not a follow-up phase.
The tradeoff we argue for
We will not build a multi-cloud abstraction layer unless you have a contractual reason to need one. It doubles the surface area and halves the depth you can use in any single provider.
Stack
- Terraform
- AWS
- Kubernetes
- Docker
- OpenTelemetry
- Grafana
Data & AI systems
Pipelines and model integrations that hold up under audit — versioned, evaluated, and explainable to a regulator.
We design ingestion and transformation pipelines with lineage tracking and reproducible batch runs, and we integrate language models behind evaluation harnesses so behaviour changes are measured rather than discovered by users. Retrieval systems are built with permission-aware indexing, because an enterprise knowledge base is only useful if it respects the access rules of the source system.
The tradeoff we argue for
We are candid about where a model is the wrong tool. A deterministic rules engine is often more defensible than a probabilistic one, and we will say so before you have paid us to build the second thing.
Stack
- dbt
- Airflow
- Python
- pgvector
- Evaluation harnesses
Mobile development
Applications built for the network conditions and device profiles that African users actually have.
Offline-first data layers, aggressive payload discipline, and graceful degradation on intermittent connectivity are defaults rather than optimisations. We test against low-end Android hardware and throttled networks as part of CI, and we treat install size as a product metric because it is a real acquisition constraint in this market.
The tradeoff we argue for
We recommend React Native for most enterprise internal tooling and native for anything with heavy device-hardware coupling. We will not pretend one choice is universally correct.
Stack
- React Native
- Swift
- Kotlin
- SQLite
- Detox
Design systems
Component libraries with accessibility and token governance built in, so consistency survives your next five hires.
We build token-driven systems documented in a living reference, with WCAG 2.2 AA conformance verified in automated tests rather than asserted in a slide. Governance is part of the deliverable: who may add a token, how a component gets deprecated, and how design and engineering stay reconciled once we are gone.
The tradeoff we argue for
A design system is an operating cost, not a one-off project. If you do not have someone who will own it, we will tell you to buy a component library instead of commissioning one.
Stack
- Design tokens
- React
- Radix
- Storybook
- axe-core
DevOps & scaling
Delivery pipelines, load characterisation, and the unglamorous operational work that decides whether a launch holds.
We instrument before we optimise: load profiles are characterised against production-like data, capacity limits are found deliberately rather than discovered during a campaign, and rollback is rehearsed. Deployment pipelines are built with progressive rollout and automated gating so shipping stops being an event that requires a war room.
The tradeoff we argue for
We do not chase nine-nines by default. Each additional nine multiplies operational cost, and most systems need a frank conversation about what downtime actually costs the business first.
Stack
- GitHub Actions
- ArgoCD
- k6
- Prometheus
- Incident tooling
Delivery
Two-week increments, demoed against real data. If a demo needs a mock, the increment was not finished.
- 01
Discover
Constraints, existing systems, and what the business actually needs to move.
- 02
Design
Architecture position, interface design, and a written risk register.
- 03
Build
Two-week increments, demoed against real data, never against a mock.
- 04
Ship
Progressive rollout with rehearsed rollback and measured release gates.
- 05
Support
Runbooks, operator training, and handover your team can act on.
Novelty is a cost paid by whoever operates the system next.
Common questions
What technologies does Acorn Code Lab use?
Acorn Code Lab builds primarily in TypeScript, Go and Python, with PostgreSQL, Terraform, AWS and Kubernetes for infrastructure, React Native, Swift and Kotlin for mobile, and dbt and Airflow for data pipelines. Technology choices are made per engagement and the studio favours the least novel option that fully solves the problem.
Can Acorn Code Lab work alongside our in-house engineering team?
Yes. The embedded team model puts a cross-functional squad inside your organisation, working in your repositories, your process and your standups, with you directing priority. It is the most common arrangement for sustained roadmap work.
Does Acorn Code Lab build software for low-connectivity environments?
Yes, and it is a default rather than a specialism. Offline-first data layers, deterministic conflict resolution, payload discipline and testing against low-end Android hardware on throttled networks are standard practice, because they are the operating conditions across much of the continent.
Does Acorn Code Lab do AI and machine learning work?
Yes, with a bias toward measurability. Language model integrations are built behind evaluation harnesses so behaviour changes are graded rather than discovered by users, model versions are pinned, and every decision is recorded with the inputs that produced it — which is what regulated workflows require.