We built Buildpathio because we’ve been the on-call engineer at 3 AM.
Austin-based, bootstrapped, and obsessed with making dependency analysis a first-class engineering workflow.
Built from the same incident, repeated too many times
From 2016 to 2021, James Whitfield was a platform engineer at a growing Austin fintech — a 400-person company scaling from a monolith into a microservice architecture. Every few months, the same thing happened: a PR merged on a Friday afternoon, looked clean in review, and a downstream service failed overnight. By the time anyone understood the dependency chain, the on-call rotation had burned three hours.
In early 2021, James wrote a script that crawled import graphs and OpenAPI specs on every push and posted a Slack message with a list of downstream services before review started. It was crude — no scoring, just a reachability list. But it worked. His team stopped having the Friday-night incident. Other teams wanted it.
By mid-2021 that script had grown into a proper graph engine. In 2022, James left to build Buildpathio as a product — adding the risk scoring model, GitHub check integration, and CLI. The internal tool became the product. The core insight has not changed since the first commit: the incident does not start at 2 AM, it starts when a PR merges without anyone knowing what is downstream.
Buildpathio is bootstrapped — no outside capital, no investors, no growth-at-all-costs pressure. Every roadmap decision starts with one question: does this make the graph more accurate or the risk score more useful to the platform engineer who receives it?
Buildpathio is not a service catalog, an APM tool, or a deployment orchestrator. It is a pre-push change impact tool — it exists entirely in the window between "PR opened" and "PR merged." If you need a post-deploy observability platform, Datadog is the answer. If you need to know the blast radius of a change before it ships, that is what we do.
What we actually believe
The graph is built by scanning source imports, OpenAPI specs, and service mesh telemetry — not by asking someone to fill in a YAML template. A Backstage catalog that’s three months stale creates false confidence. Buildpathio shows only what the code and traffic currently prove is true.
The blast radius score exists in the PR check, before any reviewer opens the diff. The window between "PR opened" and "PR merged" is the cheapest point to change course in the entire software delivery cycle. That’s the only window we care about.
Platform engineers evaluate tooling by reading docs, running a scan, and checking whether the output is accurate — not by watching a demo. We optimize for that evaluation path: fast install, readable config, honest graph. No dashboard designed for a VP who will never look at a service dependency edge.
Built by people who ship platform tooling
Based in Austin, TX — the same city where the first version of Buildpathio was written.