First Light · a briefing for engineering leaders
Every delay has two dates.
The day the risk became knowable. The day you found out. Almost nobody measures the distance between them — and it is the most expensive number in the programme.
Six issues a year. Read the method first — it is on this page, and it is free.
The problem
Nobody misses the signal. They meet it late.
When a programme slips, the reason is rarely a surprise. The date is. Somewhere in the record there is a moment — a dependency quietly re-opened, a review comment nobody chased, a third ticket on the same component in a fortnight — when the outcome became knowable to the organisation. Weeks later, it becomes known.
Everything expensive happens in between. Senior engineers solve problems that were already solved. Decisions are taken on information that has aged. A milestone that could have been recovered in week two cannot be recovered in week seven. And by the time the programme review has the truth, the review is a meeting about a past nobody can change.
This is not a failure of competence, and it is certainly not a failure of individual engineers. It is a property of how information travels through an organisation running several programmes across several tools. It is measurable. And in most organisations it has never once been measured.
Our point of view
Foresight beats hindsight.
Every dashboard an engineering leader has ever owned answers one question: what already broke. That question has an industry built around it. The more useful question — what is about to — has almost nobody working on it, because answering it requires reading the operational signal an organisation generates while it works, and for a great many engineering organisations that signal is the one thing that cannot leave the building.
We think the distance between those two dates is the most under-examined number in engineering management. So before we ask you to believe anything about our software, we would rather you measured it yourself.
The method — free, ungated
Measure your own distance. It takes about twenty minutes.
Run this on a programme that has already finished, so nothing is at stake and nobody is being assessed. You will need read access to your own ticket history and your own team's channels. You will not need us.
01
Choose one slip
A milestone in the last twelve months that moved by two weeks or more. One is enough to start; three gives you a range.
02
Fix date two
The day the organisation acted — when the risk was formally raised, the plan changed, or the date was moved. This one is in the minutes.
03
Find date one
Work backwards from the cause to the first artefact in which it was visible to someone who knew what they were looking at. Be strict: the test is whether a competent person could have raised the risk, not whether anybody did.
04
Write down the distance
Date two minus date one, in calendar days. That is the number.
05
Price it, roughly
Count the engineer-days spent inside the distance on work the later decision changed or discarded, and multiply by your own blended cost. An order of magnitude is enough.
06
Repeat once more
Two reconstructions tell you whether the distance is a property of that programme or of your organisation. That distinction is the point of the exercise.
It is your number, produced from your own records, and it belongs to you. Nothing on this page asks you to register before reading it.
Why it has to happen inside the perimeter
The signal that carries the early warning is the most sensitive data you own.
You can measure the distance by hand, after the fact, on a programme that has finished. Shortening it while a programme is running is a different problem. It means reading the working record of your engineering organisation continuously — tickets, commits, review threads, the channels where the real conversation happens — and that record is a more complete description of your intellectual property than your source code is.
For a regulated, IP-sensitive engineering organisation, that rules out the obvious answer. This is why almost every platform in this category is unavailable to you: not because of a policy you could get an exception for, but because their architecture assumes your data comes to them.
Qeino is built the other way round. It deploys inside your perimeter — on-premises or air-gapped — reads your tools read-only, and sends nothing out. The deployment model is the security model. See the deployment model.
What we are building
Enough for credibility. No more than that.
Qeino is a Software Engineering Intelligence Platform for regulated, engineering-led organisations whose IP cannot leave their perimeter. It connects read-only to Jira, GitHub, Azure DevOps, Slack and your documents, learns how your programmes actually deliver, and surfaces critical-path risk while a correction still costs days rather than months.
Inside your perimeter
On-premises or air-gapped, by architecture rather than as a retrofit. No engineering data and no telemetry leave your boundary.
Programme-level, not people-level
The unit of value is recovered programme capacity. Qeino does not score individual engineers, and is not built to.
Measured, not asserted
The Foresight Ledger records every catch and the action taken, traceable to the signal that earned it. See the Ledger.
Qeino is in private testing and is not yet generally available. We are not asking you to buy anything.
Built for
- Engineering-led organisations of roughly 200–1,500 people, with 30–200 engineers
- Several concurrent programmes across a multi-tool stack
- Semiconductor, embedded and IoT, deeptech, regulated medtech, European defence-adjacent
- IP or regulatory constraints that make cloud telemetry a problem rather than a preference
- Headquartered in Europe or Israel
Not built for
- Cloud-native software teams with no residency constraint — that market is well served, and not by us
- Teams below thirty engineers, where the signal is too thin to be worth measuring
- Anyone whose first question is what their individual engineers are doing all day
- Agencies and consultancies delivering project work
The subscription
First Light. Six issues a year.
Each issue carries three things. One delivery failure reconstructed from the dates. One method you can run yourself, without buying anything. One architectural note from our CTO on building intelligence inside a perimeter that cannot be crossed. No product news. No release notes. If we never ship, it should still be worth receiving.
Already running a programme you would rather not be surprised by? Talk to us about a Foresight Pilot.
Security or architecture questions go straight to our CTO.