Hidden in plain sight
// My lab once found a gene that had been sitting in plain sight the whole time. It wasn't buried in some exotic organism nobody had sequenced. It was right there, in genomes people had already looked at, unremarked — because the standard searches simply hadn't looked hard enough to see it. Once you know a thing like that is possible, you can't un-know it. You start wondering how many other interesting gene families are out there, quietly overlooked, one better search away from being obvious.
That feeling is what this tool is built around. Not "run BLAST and move on," but: what would it take to reliably find the homologues everyone else misses, and to do it in a way I could actually stand behind six months later?
Because the honest problem isn't that the tools are bad. HMMER, MAFFT, Prodigal, IQ-TREE, clinker — these are excellent, battle-tested pieces of software. The problem is the seam between them. A remote-homologue search is a real workflow: build a profile, calibrate against controls, search a set of databases in six frames, reconstruct and validate every hit as a genuine ORF, deduplicate, re-seed, iterate to convergence. Stitch that together by hand and by the third round the pipeline lives in your shell history and your short-term memory — and both are lossy.
// the interesting stuff was hidden because the search stopped one frame too early.
This matters most in phage biology, where so much of the interesting stuff is genuinely hidden. Some of the proteins I care about are encoded antisense or out-of-frame to a predicted gene, so a search over annotated proteins never sees them at all. You have to translate the raw genome in all six frames to reach them. Do that by hand across a dozen databases and several iterations and the bookkeeping — not the biology — becomes the hard part. And bookkeeping is exactly where reproducibility goes to die.
So HMM Homologue Finder packages the whole loop into one command. You hand it a seed FASTA. It builds the HMM, calibrates the threshold against positive and negative controls, searches the catalog in six frames, reconstructs and validates each hit's ORF, deduplicates, re-seeds, and repeats — stopping automatically when the hit set and model stabilise. Then it characterises what it found: alignment, tree, synteny figures, GFF3 tracks, a written methods file, and a full manifest.
Two decisions mattered most. First, it gives the same answer every time for a fixed seed and pinned databases — the environment is locked, the stochastic steps are seeded, and a golden-file test snapshots the biological invariants so a refactor can't silently move the result. Second, a hit has to earn its place: reconstructed frame-correctly, no internal stops, sitting in a real coding locus, with an ROC curve to answer "it's just composition bias" with a number rather than a shrug. A validated hit is still only a candidate — function needs the bench — but it's one you can defend.
One honest note: I'm a scientist who got good at building tools with AI, not a career software engineer. I built this with Claude — the science and the decisions about what to validate are mine; the AI just made it real faster than I could alone. And building it forced me to understand the problem more deeply than using tools ever did. You cannot fudge in code what it means for a six-frame hit to be a "real" gene. The test suite makes you say exactly what you mean.