What I build
- In developmentMezgebOffline mobile-money ledger for Ethiopian shops
- In developmentSuqOffline-first point of sale and inventory
- In developmentDocSearch → Not AloneCited answers from documents, now pivoting to a scripture app
- In developmentNullChatPeer-to-peer messaging with no network
- In developmentMeretOffline maps and GPS logging for field teams
- Shippedethiopic-textSearch and normalization for Ethiopic script
- ShippedHU NewsHaramaya University news app
- CompletedSecurity ScannerAutomated web vulnerability scanner, similar to online pentesting platforms
- CompletedAlpha CoinToken dashboard on the Internet Computer
How I work
Plan in writing
Work starts from a written roadmap with priorities. Each change is scoped before it is built: what changes, why, and how to test it.
Document the rules
Each repo records its architecture, its commands, and the rules that must never break, so the next change starts from the same written context.
Test every change
Changes ship with the tests that prove them. A change is done when the tests pass, not when it looks right.
CI as the gatekeeper
A GitHub Actions workflow runs the checks. The latest result on each repo's default branch is shown on its project page, passing or failing.
The evidence, from the repos
Counted from the GitHub sync of 21 Oct 2026, not typed in.
5 of 9 listed projects keep a written roadmap
6 of 9 listed projects have CI on GitHub Actions
A worked example: this site
This portfolio is built the same way. A scheduled job reads my public repos read-only and updates the project data; a CI check fails the build when any claim on this site has no matching quote in the repo it describes. The site's own repo is private, so this is a description rather than a link.