01
Odoo vs Dynamics 365, from a studio that implements both
No sales deck: where each platform wins, the costs nobody puts in proposals, and when the answer is neither.
Ravindu Withana
9 min read
Odoo · Dynamics 365 · ERP
Insights
Notes from thework.
Written when we learn something worth passing on. No drip sequences, no content calendar — if there is nothing interesting, we do not write.
Latest · 20 October 2026 · 8 min read
RAG or fine-tuning? How to tell which problem you have
Retrieval grounds answers in your documents; fine-tuning changes behaviour. The sequence that works, and what each one costs.
By Ravindu WithanaAI · RAG · Fine-tuning
01 / Technical notes
- 02
Five ways Salesforce implementations fail (and the fixes)
Fields nobody owns, integrations deferred to phase two, activity metrics as targets — all preventable, none in the sales deck.
Ravindu Withana
7 min read
Salesforce · CRM · Implementation
- 03
The Odoo implementation guide we wish every project started with
Data before modules, rehearsed migrations, and training the users instead of the approvers.
Ravindu Withana
9 min read
Odoo · ERP · Implementation
- 04
Migrate, do not rewrite
Why we have spent seven years talking clients out of full rewrites, and what we do instead.
Ravindu Withana
7 min read
Engineering · Architecture
- 05
The RAG evaluation checklist we run before anything ships
Seven checks — labelled sets, decline thresholds, shadow mode — that separate a measured system from a promising demo.
Ravindu Withana
8 min read
AI · RAG · Evaluation
- 06
Measure the phone in your pocket
Lab scores are useful and they are not the same thing as fast. How we baseline and fix real-user performance.
Bhashana Bogoda
6 min read
Performance · Front-end
- 07
You cannot ship an AI feature you have not measured
Evaluation harnesses, confidence thresholds and shadow mode — how we keep retrieval systems from failing quietly.
Ravindu Withana
8 min read
AI · Evaluation
- 08
Design systems that actually got adopted
Most design systems fail for organisational reasons. What we learned getting one to 94% adoption.
Kalindu Gayanjith
6 min read
Design systems · Process
02 / How we build AI systems
The commitments we make on AI work, stated as practices you can hold us to rather than as claims about capability.
01
Evaluation before features
The evaluation harness ships before the feature does. If you cannot measure whether an answer got better, you have changed the system, not improved it.
02
Shadow mode first
The system runs against live traffic silently for at least a week before it answers a single real question.
03
Ability to decline
Confidence thresholds that escalate to a human instead of guessing. A refusal costs seconds; a confident wrong answer costs a customer.
04
Full traceability
Every answer stores the retrieved documents, their scores, the prompt and the model version.
05
Cost treated as a first-class metric
Cost per resolved task is tracked from week one, alongside accuracy, in the same dashboard.
06
Boring retrieval over clever prompts
Most retrieval failures are data problems, not prompt problems. We fix chunking and metadata before reaching for prompt engineering.
Retrieval architectures
Baseline RAG
Embed, retrieve top-k, generate. The honest starting point.
Fails quietly on the questions you care most about. It has no way to say "I do not know", so it will confabulate a confident answer from three loosely related passages.
Hybrid retrieval
Semantic and lexical search fused with reciprocal rank fusion.
Roughly doubles the retrieval budget and adds a fusion parameter that needs tuning against a real query set.
Agentic retrieval
A model plans queries, calls tools, and iterates until it can answer or gives up.
Cost and latency both multiply per hop, and it is much harder to evaluate. We cap it at a fixed number of iterations for this reason.
Entity-aware RAG
Retrieval anchored to a knowledge graph of real entities and their relations.
Requires reliable entity data to start with, and graph upkeep becomes an ongoing cost rather than a one-off.
Self-correcting RAG
The answer is retrieved, checked against its sources, and revised if the check fails.
Doubles inference cost for a measurable accuracy gain, but the checker needs its own evaluation or you are just adding confidence.
03 / Model selection, in brief
Our shortlist, with the honest caveat each time. We are not model-agnostic in the unhelpful sense — these are the ones we have measured against client workloads.
OpenAI
- GPT-4.1
- GPT-4o mini
Strongest general tool-calling and instruction following, plus the most reliable structured output we have measured.
Anthropic
- Claude Sonnet
- Claude Opus
Long-context work where most of the document actually matters, and careful, low-hallucination analysis.
Google
- Gemini 2.5 Pro
- Gemini 2.5 Flash
Very large context windows, multimodal input, and competitive cost on high-volume tasks.
Meta (self-hosted)
- Llama 3.3 70B
- Llama 3.1 8B
Data that cannot leave your infrastructure, or predictable high-volume cost after the hardware is bought.
Mistral
- Mistral Large
- Mistral Small
Strong European-hosted options and efficient small models for classification workloads.
Open models (via a provider)
- DeepSeek
- Qwen 2.5
Cost-sensitive workloads where a hosted open-weight model clears your quality bar.
04 / Measured outcomes
Every engagement we publish numbers for. If a metric did not move, the case study says so and explains why — which is rarer than it should be.
Case studies
Product and platform work, reported against a baseline we captured in week one.
All case studies →AI systems
Retrieval and extraction work, each gated behind an accuracy number before launch.
- Heliostat
- Ashgrove Group
- Precision Components
Enterprise systems
ERP and automation implementations, reported the same way.
- Precision Components
- Halden Retail
- Ashgrove Group
Platforms we implement
Stay in the loop
One email a quarter, when we have something worth sending.
No drip sequences. If there is nothing interesting, we do not write.