Engineering evidence
Scoped, dated, and methodologically qualified — not just numbers
A number on its own is a claim. The same number with its scope, its date boundary, and its method attached is evidence. Everything below is the second kind: what each figure covers, over what period, measured how — and, where it matters, what that measurement cannot show. Every row links to the case study that explains it in full.
The record
| Statistic | Value |
|---|---|
| Years in software engineering | 4+Software-developer and engineering roles since January 2022; the earlier IT-analyst and field period (Mar 2021 – Jan 2022, then a software-developer year at the same company) is stated separately, not added in — Counted from the first software-developer title on the CV (Jan 2022) to the present; rounded down, never up |
| Design specifications written | 255Cendra, tenure-scoped (Aug 2025 – Jul 2026) — Self-counted in private company repositories; consistent with the CV |
| Implementation plans written | 207Cendra, tenure-scoped (Aug 2025 – Jul 2026) — Self-counted in private company repositories; consistent with the CV |
| Production runbooks authored | 17Cendra, tenure-scoped (Aug 2025 – Jul 2026) — Self-counted; each one governs a coordinated release |
| Production releases coordinated | 377Cendra, across four repositories, tenure-scoped — Self-counted; roughly one release every 22 hours across the tenure |
| Languages shipped, including Arabic RTL | 13Cendra product surface, tenure-scoped — Self-reported product scope |
| LILA commits since founding | ~9,500LILA, solo project (Feb 2026 – present) — Approximate, self-counted via git on the main branch (9,550 on 4 September 2026); unverified by anyone else — it's a private repository I own |
| Archive Engineering commits | 257 of 289Archive Engineering, solo-author project — Self-counted; 31 of the 289 were made by an AI coding tool under my direction — stated here, not netted out of the total |
| GitHub contributions | 6,562GitHub profile, Aug 2025 – Jul 2026 window — Directly measured from GitHub's own contribution graph; covers LILA, Archive Engineering and ReadyFly only — Cendra's Azure DevOps history is not represented. A dated measurement: the graph below refreshes at build time and will drift past this figure |
| Surviving frontend authorship, Cendra | 84.7%Cendra frontend, sampled at tenure's end — git blame -w -M against origin/prod, a deterministic 1-in-7 file sample |
| Tenure-scoped frontend commits, Cendra | 80.7%Cendra frontend, production branch, tenure-scoped — Commit-count share, not surviving-code share — a different measurement from the row above |
| Surviving backend authorship, Cendra | 23.2%Cendra backend, sampled — joined roughly six months into an eighteen-month-old codebase — Sampled git blame; a substantial contributor to that codebase, not its architect |
| Cendra's seed round | $1MAnnounced 11 February 2026, led by Revo Capital with follow-on from Heartfelt Capital, Türkiye Development Fund and APY Ventures — Company-announced public record; the official announcement names me as founding engineer. Not a personal metric. |
| Unnecessary push notifications eliminated | ~19,000/dayCendra, production telemetry — Measured over a ten-minute observation window and extrapolated to a daily figure — not a directly observed 24-hour count |
| ReadyFly web application commits | 157 of 209ReadyFly web application (Jun 2025 – Jun 2026) — Self-counted, roughly three quarters; also a contributor to the API (31 of 209 commits), not its principal author |
How to read these numbers
Commit count is not surviving authorship
A commit count measures participation — how many times someone touched a repository. It says nothing about whether that code is still there. Surviving authorship measures what actually ships today, attributed to whoever last substantively wrote each line. The two disagree whenever code is rewritten, reformatted, or replaced, which is most of the time in a codebase more than a few months old. Where I have both figures for the same repository — Cendra’s frontend, at 84.7% surviving versus 80.7% of tenure-scoped commits — I show both, because they answer different questions and neither one alone is the honest answer.
The blame method, and why it is conservative
Surviving-authorship figures come from git blame -w -M against the production branch, sampled rather than run against every file for tractability. -w ignores whitespace-only changes, so a reformat by another engineer does not silently reassign lines that were never really theirs. -M detects moved and copied lines, so a file split or a component moved to a new path does not read as someone else’s new authorship. Both flags make the figure harder to inflate, not easier — which is the direction a claim like this should err.
Why there is no “verify live” button
LILA and Archive Engineering are private because they are mine to open; Cendra and ReadyFly are private because they belong to companies that have not agreed to publish their source, their infrastructure, or their customers’ data, and I would not ask them to just to make a portfolio more convincing. Confidentiality here is not a gap in the evidence — it is a constraint the evidence is built to work within: every figure states its method precisely enough that you can judge what it can and cannot prove without needing the repository itself.
Why Cendra does not appear on GitHub
Cendra’s repositories were hosted on Azure DevOps, not GitHub, for the whole of my tenure there. The 6,562 contributions recorded in the table above cover August 2025 – July 2026 and are real and directly measured, but they span only the three projects I hosted on GitHub — LILA, Archive Engineering, and ReadyFly. Cendra’s commit history, releases, and specifications are real too; they are simply invisible to a tool that only reads GitHub, which is why this page states each figure’s source rather than letting one graph stand in for all of it.
GitHub activity
Capability × ownership
| Capability | LILA | Archive Engineering | Cendra | ReadyFly |
|---|---|---|---|---|
| Product/UX | Owner | Owner | Owner | Owner |
| Frontend | Owner | Owner | Owner | Owner |
| Mobile | Owner | Owner | Owner | — |
| Backend | Owner | Owner | Contributor | Contributor |
| AI layer | Owner | Owner | Contributor (bounded) | Not owned |
| Release & ops | Owner | Owner | Owner | — |
“Owner” is sole or principal author of that capability on that project. “Contributor” means a real but partial share, stated precisely on each project’s case study. “Contributor (bounded)” marks Cendra’s AI layer specifically: I built the product surfaces and the transport around Cendra’s AI capabilities, not the underlying orchestration, which was owned by another engineer. “Not owned” marks ReadyFly’s semantic-matching and candidate-evaluation models, owned by its backend and ML engineers. An em dash marks a capability not exercised on that project.
This website’s codebase
| Statistic | Value |
|---|---|
| Lines of TypeScript powering this website | 7637 |