LynchPine is a software engineering studio in Colombo. We build web platforms, mobile apps, enterprise and supply chain systems, and the AI layers on top of them, then prove each one works before you depend on it.
Five practices, one way of working. Whatever the work is, it is built to survive contact with production, and measured before you depend on it.
Marketing sites, customer portals and headless commerce that stay fast on a phone connection.
a deployed site or storefront, its content model, and the pipeline that ships changes to it
iOS and Android from one codebase, and the hardware that reports back to them.
signed iOS and Android builds, both store listings, and an automated release pipeline
The systems operations actually run on: stock, orders, logistics, and the internal tools around them.
connected workflows, role-based access, audit trails, and the dashboards operations run on
Pipelines, warehousing, access control, and the release machinery that puts a change live safely.
data pipelines, a warehouse, access controls, and deployments with monitoring attached
Assistants that cite their source, agents with a job description, document intelligence.
an evaluation set, the accuracy scores it produces, and the service deployed behind an interface
All twelve services in detail What each one includes, and what it does not.
A demo needs one good answer. A production system needs the ten thousandth, on the day the warehouse is behind, from someone who filled the form in wrong. The engineering between those two points is where projects stall: where the data comes from, what the system is allowed to touch, what happens when a run fails, and how you know six months later that it still works.
Those are the joins. They rarely show up in a demo, and they are most of the work.
agent playground
Pick a request below. It runs here.
A support system, running. Each request wakes the agents it needs, touches only what it is allowed to touch, and writes down what it did. The third one is refused.
Task: What are our termination rights on the supplier agreement?
run log
Take the queue yourself Ninety seconds, four agents, one budget.
Five stages, and a loop. The last one feeds the second, which is the difference between a system that degrades quietly and one that gets better on purpose.
sources
Contracts, tickets, SOPs, the spreadsheet one person maintains. We map it before deciding what a model may see.
retrieval
Hybrid keyword and vector search with reranking, tuned on your questions instead of a public benchmark.
orchestration
Routing, tool access, shared state, handoffs. Where most AI projects quietly come apart.
agents
Scoped and permissioned, so approving one is a decision someone can actually make.
evaluation
A test set from real queries, run on every change, then fed back so the system improves on purpose.
Ask a question of a thousand documents and this is what happens. Your material is placed by meaning rather than by folder; the question lands in that space, and the passages nearest it come back, each one still carrying the document it came from. That last part is why an answer can be checked.
retrieval
Keep scrolling to run the search.
Here is a question and six passages from a fictional company's documents. Choose up to three for the model to read, then see what it answers. The model is the same every time. Only what you hand it changes.
The questionWhat is the refund window for enterprise customers?
A model is a poor substitute for deterministic logic and roughly a thousand times the price. We put one in the path only where the work genuinely calls for judgement. If your problem is really a rules engine, we will say so, and the bill will be smaller for it.
Anything can be made to work once, on a question the vendor picked. We would rather build an evaluation set from your own queries first and show you how the system scores against it. That number is what you can take to a board.
The frontier moves every few months. We put the model behind an interface, so switching one out is a config change and a couple of eval runs. When a provider raises prices or retires the version you depend on, you get to decide what happens next, on your own timetable.
Two lines, eight builds. One is the query chosen for the demo. The other is a held-out set of real questions. Only one of them is evidence.
| Build | The query picked for the demo | A held-out set of your questions |
|---|---|---|
| 01 | 96% | 47% |
| 02 | 97% | 55% |
| 03 | 96% | 58% |
| 04 | 98% | 69% |
| 05 | 97% | 74% |
| 06 | 98% | 79% |
| 07 | 98% | 84% |
| 08 | 99% | 86% |
IllustrativeThe shape is what matters: a cherry-picked query is at the top from the first build and stays there, so it can tell you nothing about whether the system improved. The line that can is the one that does not reach it.
Per thousand decisions, at the point in the path where the choice is actually made.
USD per 1,000 decisions
IllustrativeRounded hard on purpose: the argument is the order of magnitude, not the third significant figure. Linear scale, so the first bar is a hairline, which is the point of it. Published rates move every few months; the ratio between a branch and a model call has not.
Based in Colombo, working with clients in Australia, Canada, India, Norway, Sri Lanka and the United Kingdom. Most of it is remote, and the timezone question is usually the real one, so the offsets are on the map.
Four phases, whatever the work is. The point of running it this way is to force the decisions into the open early, because the ones nobody makes are the ones an AI tool will quietly make for you, in code, where they are expensive to find.
01
Week 1
We find the decisions nobody has made yet, the ones an AI tool would otherwise make for you, silently, in code. You get a written scope and a fixed price before anything is built.
02
Weeks 2-3
Architecture, data flow, agent boundaries, and what counts as working. All of it agreed while it is still cheap to argue about, and written down so nobody relitigates it in week six.
03
Weeks 3-7
Small changes, each one run against the evaluation set. You get a live environment in the first week and watch it fill in, so nothing arrives as a surprise at handover.
04
Week 8 onward
Real use produces cases the plan missed. Those become new tests, the system improves against them, and the loop keeps running after handover, with your team or with ours.
Send a paragraph about the problem. We reply within two working days with questions, a rough shape, and an honest answer on whether we are the right people for it.
Ask about our work
Answers come from this site and cite the page. It will not know anything we have not published.
Questions are sent to Google Gemini, which uses them to improve its products. Do not type anything confidential. Email us instead.
