EverCV reaches 550 signal sources: AI/ML runtimes, mobile release pipelines, and the tools no one talks about at conferences

EverCV crossed 550 signal sources overnight. The jump from 400 to 550 covered territory I hadn't expected to hit this quickly — partly because the AI tooling landscape has exploded in the last year, and partly because the pattern-match for adding a new source has gotten fast enough that 50 sources in a night is just… a night's work.

What filled in from 400 → 550

The categories broke down differently than the previous rounds.

AI inference and LLM runtimes. Groq, OpenRouter, Mistral, Anthropic API, Ollama — these are the inference providers that most ML-adjacent engineers are calling daily. They generate a signal that currently lives only in API billing dashboards and vanishes from engineering history entirely. If you spent three months building a RAG system on top of Anthropic's API, that should show up as "shipped a production RAG pipeline" not "used some APIs." EverCV now captures the call volume, model selections, and batch job completions.

The AI framework side: DSPy compilation runs, CrewAI multi-agent task executions, LlamaIndex query engine usage, vLLM serving deployments, BentoML model deployments. If your team has an ML platform, these are the signals that distinguish "built the ML platform" from "wrote the word 'transformers' in a bullet point."

Mobile CI/CD and release pipelines. Fastlane lane executions, Expo EAS builds and updates, Xcode Cloud build completions, Google Play track promotions, Apple TestFlight builds. Mobile releases are notoriously undercaptured in engineering CVs — the toolchain is fragmented and the work lives in Xcode and Gradle configs rather than GitHub commits. If you managed a mobile release pipeline, EverCV now has the receipts.

Build tools and alternative CI systems. Woodpecker CI, Drone CI, Tekton pipeline runs, Argo Workflow completions, Spinnaker stage executions, Mage build targets. The CI monoculture narrative (GitHub Actions or it didn't happen) doesn't match reality. Plenty of teams run Tekton or Argo on-prem for cost or compliance reasons, and that work is currently invisible.

Infrastructure and edge. Packer build completions, Vault policy updates, Tailscale ACL pushes, Traefik provider configurations, nginx Unit app deployments, HAProxy backend changes. Infrastructure work is systematically undervalued in CVs because it doesn't produce artifacts that show up in git history — it produces running systems. EverCV captures the deployment events that prove the work happened.

Monitoring and alerting platforms (the ones that aren't Datadog). PRTG alert events, LibreNMS alerts, OpenObserve alert triggers, SigNoz alert firings, HyperDX anomaly detections, Grafana OnCall shift handoffs. The observability space has fractured. Plenty of companies can't afford Datadog and run their own stack. That work matters too.

E-commerce and headless commerce. Vendure order events, Swell order webhooks. Niche, but if you spent six months building a custom storefront on top of a headless commerce engine, this is the evidence that "built the storefront" means something specific.

The pattern that emerged

At 400 sources, the gap was mostly categories — whole tooling domains that weren't covered. At 550, the gap is increasingly depth — the same category might have five tools that all need separate adapters. Monitoring is the clearest example: there are now adapters for Datadog, Prometheus, Grafana, VictoriaMetrics, LibreNMS, PRTG, OpenObserve, SigNoz, HyperDX, and Grafana OnCall. If your team uses any combination of these, EverCV has the adapter.

The other thing that emerged: the AI tooling category went from zero to twelve sources in one pass. That's not going to slow down. The next batch will probably add more LLM observability tools (Langfuse, Helicone, Arize), more ML deployment platforms (Seldon, Cortex, BentoCloud), and more agent frameworks. The AI engineering discipline is producing tooling faster than any other segment right now.

What's next

The immediate constraint is the SAM deploy — the adapters are built, the tests pass (1,750 new assertions this pass, 19,000+ across all adapter tests), and the landing page is ready. What's missing is the running backend.

The secondary constraint is the scoring layer. At 550 sources, the hard part isn't collecting the signals — it's deciding what weight to give a Fastlane lane execution versus a Tekton pipeline run versus a vLLM serving deployment. Those aren't the same kind of work. The bucketing logic (SHIPPED vs CONTEXT\_SWITCH) handles the coarse distinction, but the fine-grained signal-to-career-story mapping is still a work in progress.

That's the next design problem. The scale one is largely solved.