The Amdahl Profiler idea is niche, technically sharp, and solvable in a weekend — with a few honest caveats.
There's a Reddit post from a few months ago that probably describes something you've done. Engineer builds a 2x faster lexer, ships it, runs the benchmarks. End-to-end time barely moves. Turns out I/O was eating 71% of the runtime the whole time. The 60 comments are a chorus of 'yes, this keeps happening to me.'
That's the problem Amdahl Profiler — Automated Bottleneck Analyzer is trying to solve. Not 'we need better flamegraphs.' The specific, embarrassing, sprint-wasting thing where you optimize the wrong subsystem because you had no easy way to see which bucket of time actually dominated.
Strip it down to the minimum thing someone would pay for, and you get three pieces.
First: a CLI you run against any binary or command that spits out an Amdahl-style breakdown in the terminal. Something like: `CPU: 12%, Blocking I/O: 71%, Kernel/syscalls: 14%, Other: 3%`. Ranked. With a one-line recommendation. Run it in 30 seconds.
Second: a static HTML report with a time-attribution chart, Amdahl ceiling estimates (if you zero out I/O entirely, what's the theoretical speedup?), and a few specific recommendations tied to the dominant bucket.
Third: a GitHub Actions integration that runs this on PRs, posts the report as a comment artifact, and fails the build if your 'optimization' didn't move the real bottleneck.
That third piece is where the money is. And it's also where the hardest problem lives.
eBPF is the right tool for cross-subsystem attribution. It's how you reliably distinguish block I/O wait from network wait at the kernel level. But GitHub Actions default runners block `CAP_SYS_ADMIN`, which means eBPF-full mode won't work in the most common CI environment your customers use.
You have two options and neither is perfect. You ship a `perf_event_open` fallback that works without root but loses some cross-subsystem precision. Or you document self-hosted runner setup and accept that only more sophisticated teams will get the full experience. The honest answer is you probably do both: fallback mode for the majority, eBPF mode as the power-user path.
What you can't do is pretend this isn't a problem. Your target audience is systems engineers. They will immediately notice if the I/O vs network distinction is fuzzy, and they will post about it on HN. One confidently wrong recommendation on a public codebase — 'use writev batching' on code that already does it — and you've poisoned the distribution channel you depend on.
The fix for that is transparency. Every recommendation should cite the raw data. 'Based on 4,217 write() calls averaging 4KB, batching to 64KB chunks reduces syscall count by ~16x — see syscall trace lines 44–89.' Ship a `--raw` flag. Position this as 'perf + awk, automated' not 'AI magic.'
This is the part most people skip. Here's what I'd actually do.
Spend a few hours doing a Amdahl breakdown manually — run `perf stat` on something, pipe it through some awk, make it look like CLI output, screenshot it. Post it as a Show HN or to r/rust with the question: 'Would you use a tool that produced this automatically? Waitlist link in comments.' Do this before writing Rust.
In parallel, find the 60 people who commented on that Reddit thread and DM 20 of them. Ask one question: 'Would you pay $79/month for CI integration that catches this automatically?' You need 3 people to say yes before you build anything. Not 'sounds cool,' not 'maybe.' A credit card intent.
If you get 50 waitlist signups in 72 hours or 3 engineers with payment intent, you have signal. If you get 8 signups and polite non-answers, the TAM problem is real and you should know that now.
I'll be straight with you: the addressable market here is small. Backend engineers who (a) work on performance-sensitive code, (b) use Linux CI, (c) have perf culture but would benefit from automation, and (d) aren't already covered by a Datadog contract is a narrow Venn diagram. Maybe 5,000-8,000 people globally who fit all four.
At $79/month with realistic conversion rates, getting to $1M ARR requires a level of open-source virality that you can't plan for. It can happen — ripgrep happened — but it's not a business model.
The more interesting expansion play is Python and ML pipeline teams. Their I/O bottleneck stories are even more common. They have lower systems expertise, so they're more willing to pay for 'tell me what to fix.' And the TAM is 10x larger. If the Rust/Go launch is a credibility play that gets you HN traction and a few hundred users, Python could be where the business actually lives.
Rust CLI with `libbpf-rs` bindings for the eBPF path and `perf_event_open` wrappers for the fallback. HTML report via embedded Tera templates — no server, just a static file you open in a browser. GitHub Actions YAML action. Baseline storage in a user-supplied S3 bucket so you don't need a backend for MVP. Stripe for the CI tier via a minimal Next.js + Supabase billing portal.
Realistic solo timeline: 3 weeks on the Linux attribution engine (this is the hard part, don't underestimate it), 2 weeks on the HTML report and recommendation layer, 2 weeks on the GitHub Actions integration, 1 week on billing. Eight weeks total if nothing goes sideways. Something will go sideways.
For the recommendation engine, use GPT-4o or Claude with the structured attribution JSON and top syscall stacks as input. Static rules will be brittle and wrong. An LLM with good systems context and a strict 'cite your sources' prompt will be more accurate and more defensible — and you can swap the model as better ones come out.
Grafana already has the eBPF pipeline. They have 500+ engineers. Pyroscope has 40,000 GitHub stars. If this idea gets traction on HN, Grafana can add an 'Amdahl summary' tab to Pyroscope in 6-8 weeks. They have all the underlying data. They just haven't built the aggregation layer.
The window is probably 12-18 months before a well-funded incumbent decides to care about this specific feature. That's not enough time to build a defensible business on technical moat alone. What might work: per-codebase baseline history creates real switching costs once teams have 6 months of trend data, and a growing library of recommendation patterns that gets more accurate with more profiles. That's the compounding asset that's hard to replicate quickly.
But you need to be fast. And you need to pick a segment narrow enough to own before expanding.
Free CLI, open-source on GitHub under MIT. $79/month for the CI tier (1 repo, GitHub Actions, 90-day baseline history). $249/month for team tier (unlimited repos, dashboard, custom thresholds).
Customers are in r/rust and r/golang, on HN, in CNCF Slack's #ebpf and #performance channels. The first 10 customers come from posting a real demo on a public Rust project — run it on ripgrep or rustc, show the Amdahl breakdown, let the output speak. Then DM the people who commented on that Reddit post. Then file GitHub issues on 3-5 popular Go or Rust repos offering to run a free report and publish the results.
The embarrassment angle in the pitch matters. This isn't 'better visualization.' It's 'don't ship a useless optimization again.' That framing lands with engineers who have been burned. And based on those 60 Reddit comments, most of them have.