Engineering at Next Olive
Deep dives written by the engineers who build our systems: how we design RAG pipelines, agents that take real actions, multi-tenant data layers, cloud infrastructure and delivery pipelines — including the trade-offs and the cases where we choose differently.
How we engineer software
Next Olive has been building software since 2012 and has delivered more than 2,000 products for clients in over 25 countries. Over that time the thing that separates projects that stay healthy from projects that decay has rarely been the framework choice. It has been a small set of habits applied consistently from the first sprint. These are the defaults every team of our 100+ engineers works to, and the articles in this section show what they look like in specific systems.
- Architecture decision records. Every significant choice — database, tenancy model, queueing, model provider — gets a short ADR in the repository: context, options considered, decision, consequences. When someone asks in two years why the system works this way, the answer is in version control, not in a departed engineer's head.
- Security by default. Least-privilege roles, secrets in a managed vault, tenant isolation enforced in the data layer rather than only in application code, dependency scanning in CI, and threat modelling for anything that touches payments, personal data or autonomous AI actions.
- Automated testing. Unit and integration tests run on every pull request; contract tests guard integrations; AI features get evaluation sets alongside their code. A change that is not covered by an automated check is treated as unfinished.
- Observability. Structured logs, metrics and traces are part of the first deployment, not the first incident. For LLM features we also trace prompts, retrieved context, tool calls and cost per request.
- Documentation that ships with the code. Runbooks, environment setup, API references and on-call notes live next to the code and are reviewed in the same pull requests that change behaviour.
- Clean IP handover. We build in your repositories and cloud accounts wherever possible, so handover is a permissions change rather than a migration project.
The deep dives below are opinionated on purpose. Each one states our default approach, explains why, and names the conditions under which we deviate from it. None of them are client case studies, and none contain performance claims about specific projects; where numbers appear they are indicative industry ranges you should validate against your own workload. If you want to see how these practices fit into a delivery engagement, read how we work.
Engineering deep dives
Production RAG architecture
Ingestion, chunking, embeddings, pgvector vs dedicated vector DBs, hybrid search, reranking, tenant ACLs and evaluation.
Read deep dive → AI · AgentsAI agents with tool calling and human approval
Tool schemas, server-side validation, idempotency, risk-tiered tools and an approval queue state machine.
Read deep dive → SaaS · DataMulti-tenant data isolation in PostgreSQL
Row-Level Security, schema and database per tenant, pooling pitfalls, partitioning and moving large tenants out.
Read deep dive → Cloud · AWSAWS architecture for high-traffic SaaS
A reference architecture covering edge, compute, data, caching, queues, multi-AZ resilience and cost controls.
Read deep dive → MobileFlutter vs React Native architecture
Rendering models, state management, native interop, performance profiles and long-term maintenance cost.
Read deep dive → Modernisation.NET Framework to modern .NET migration
Assessing a legacy estate, strangler-fig sequencing, dependency blockers and keeping production running throughout.
Read deep dive → DevOps · QAOur CI/CD and automated testing pipeline
The stages, gates and test layers we run for web and mobile, from pull request checks to staged releases.
Read deep dive →Related guides
For broader, less implementation-heavy reading, start with these:
Frequently asked questions
Who writes the articles in the Engineering section?
They are written by the Next Olive engineering team and reviewed by our solution architects. They describe our default approach to recurring problems and the situations where we deviate from it, not stories about specific clients.
Do we get architecture decision records and documentation at handover?
Yes. Architecture decision records, runbooks, environment setup notes, API documentation and infrastructure-as-code live in your repository from the first sprint, so they transfer with the code rather than being written at the end.
Who owns the code and intellectual property?
In our standard engagements the delivered code and IP belong to the client, with the exact terms set out in your contract, and we build in your source control, cloud accounts and third-party accounts wherever possible so nothing needs to be migrated at the end.
Can we reuse these patterns with our own in-house team?
Yes. The articles are written to be usable by any competent team. If you want a second opinion on how they apply to your system, we also run short architecture reviews before any build commitment.
Want engineers who work this way on your product?
Tell us what you are building. We will walk through the architecture decisions that matter for it and give you a scoped, honest estimate.
Talk to our engineers