Launched a tech stack detection API — $0 to build, looking for first users
Hey IH!
I just launched DetectZeStack — an API that detects what technologies any website is running. Give it a URL, get back the full stack.
The problem: I was building a lead enrichment pipeline and needed to filter prospects by technology (e.g., "find all sites running Shopify"). BuiltWith charges $295/month minimum. Wappalyzer's API is cheaper but only does HTML-level detection, missing CDNs and infrastructure tech.
What I built: A Go API that combines 4 detection methods (Wappalyzer fingerprinting, DNS analysis, TLS inspection, HTTP headers) in a single call. Runs on a $5/month Fly.io machine with SQLite.
Current state:
- Live and working: https://detectzestack.fly.dev (try the demo)
- Free tier: 100 requests/month
- 0 real users (being honest)
What I'm looking for:
- Early users who'd actually use this
- Feedback on pricing and features
- Ideas for use cases I haven't thought of
If you work with tech stack data (sales, security, market research), I'd love to hear what would make this useful for you. Happy to extend the free tier for anyone who gives real feedback.
Integrated the API last week and hit a wall on webhook signature validation. Header name and HMAC algorithm aren't documented. Built a reference doc covering that plus a Wappalyzer comparison. Happy to share if useful.
This is a really cool build — combining multiple detection layers in one API is solid.
Curious how you’re planning to validate real demand beyond interest, especially with 0 users so far?
Also, if you want to test actual willingness (not just feedback), there’s an interesting setup where you can put an idea into a live competition ($19 entry, winner gets a Tokyo trip, prize pool grows with entries). Could be a quick way to gauge real commitment.
Hey,
How's traction looking post-launch? Reason I'm asking is we might be able to help with that.
We run a marketplace for developers and technical teams to discover and try new SaaS tools. We bring the users. You focus on the product.
Here's exactly how it works:
We list DetectZeStack on our marketplace and handle all billing. For the first 3 months, we offer users an aggressive intro price ($1/month for Pro, $5/month for Ultra, $10/month for Mega) fully subsidized by us, so you don't lose anything during that window. These numbers are a starting point and we're open to working them out together. From month 4 onwards, users pay your full price ($9/month for Pro, $29/month for Ultra, $79/month for Mega) through us, and we remit 90% of every payment directly to you. We keep 10% as our cut.
For you: zero acquisition cost, zero billing overhead, and a recurring revenue stream from users you didn't have to find. For us: we own the customer relationship and take 10% for as long as they stay.
We don't onboard tools without agreeing on terms first, it keeps the program credible for everyone on the platform.
Would love to share more details. Do you have an email or somewhere easier to chat?
Congrats on the launch — tech stack detection APIs are becoming table stakes, but without clear positioning vs BuiltWith/StackShare and actual usage data, it’s hard to see why users would switch.
Right now it reads like “another API,” not a solution that solves a specific pain point (accuracy, cost, speed, SaaS integration).
If you want real traction instead of tinkering, it’s worth talking through your go-to-market messaging and use cases — happy to help sharpen that.
Thanks for the honest take. You're right that the positioning in this post could be sharper — listing features without tying them to a specific pain point makes it easy to gloss over.
To address the "why switch" question directly: cost and detection coverage are the two concrete differentiators. BuiltWith's API starts at $295/month — we're $29.99 for 25K requests. And most tools (including Wappalyzer) only do HTTP/HTML fingerprinting, so they miss a lot of infrastructure-level tech. We layer DNS CNAME analysis and TLS certificate inspection on top, which catches CDNs, hosting providers, and cloud services that never appear in page source.
The other angle we're leaning into is security — detected technologies include CPE identifiers when available, mapped to the NVD vulnerability database, so security teams can go from "what's this site running" to "which of those have known CVEs" in one call. That's a use case BuiltWith and Wappalyzer don't touch.
Fair point on usage data — we're early and not going to fake traction numbers. Appreciate the feedback on messaging.
Makes total sense — those differentiators (pricing, detection depth, security insights) are solid. The next step is really about making them pop immediately for potential users so they don’t gloss over it.
Even a few lines framing “why this matters for your workflow” above the fold can turn a curious click into real usage.
Once you pair that with early success stories, your positioning will go from “another API” to the obvious choice for anyone who cares about coverage and cost.
Good call on the above-the-fold framing. Right now the landing page leads with what the product does ("detect tech stacks") rather than why someone should care. Reframing around specific workflows — "audit your vendors for vulnerable dependencies," "see when competitors switch CDNs" — would make the value click faster.
On success stories — we're pre-traction and not going to fake it. But that's exactly why this kind of feedback is valuable — sharpening the messaging now means when those first users do come through, the experience matches the product's actual depth.
Thanks for following up — genuinely appreciate you taking the time.
Thank you, connect of you want to proceed for professional help 🙂 in future
Interesting tool! 👏 Detect Ze Stack has a clean starter interface and shows promise as a stack-detection utility. Users can clearly see what technologies are under the hood that’s a helpful insight for devs, recruiters, and product teams.
One thing I noticed is that the current experience focuses primarily on the detection part, but it’s not always clear what to do next after a detection result. Adding clear pathways after the result screen could help users move from “seeing the tech stack” to “acting on it.”
Curious, are you thinking about adding features like history logs, comparison tools, or actionable insights based on stack results? Those could significantly increase recurring usage.
Thanks for the feedback, codepro! Really appreciate you taking the time to look at it.
Great news — we actually already have both of those features built into the API:
GET /historyreturns all your past analyses with timestamps, so you can track how a site's stack changes over timePOST /compare— pass 2-10 URLs and it returns shared vs. unique technologies across them. Useful for competitive analysis or standardization auditsYou're spot on about the UX though — the landing page demo doesn't surface these features well enough. Right now they're API-only, so unless someone reads the docs they'd miss them. Making the "what's next" clearer after a detection result is solid feedback I'll act on.
For the "actionable insights" piece — detected technologies include CPE identifiers (when available) that map to the NVD vulnerability database. So security teams can go from "this site runs jQuery 3.5.1" to looking up known CVEs using the CPE string.
If you want to try any of the advanced endpoints, the free tier (100 req/month) covers everything. Happy to bump that if you want to test more.
That’s actually impressive especially the comparison endpoint and webhook alerts. The CPE + NVD mapping is a strong differentiator too, particularly for security teams. That adds a whole new layer of value beyond simple stack detection.
What stands out to me isn’t a feature gap it’s a visibility gap.
Right now, the product is more powerful than the landing experience communicates. If someone doesn’t read the docs, they might assume it’s just a basic detection tool, when in reality it’s closer to a monitoring and competitive analysis platform.
One thing that could make a big difference is surfacing those advanced capabilities immediately after a detection result. For example, once a stack is shown, a small contextual panel could say:
“Compare this stack with another site”
“Track changes over time”
“Monitor this domain for updates”
That bridges API power with user clarity.
You’ve already built the depth the opportunity now is making that depth obvious in the first interaction.
Also, positioning-wise, leaning slightly into the security and monitoring angle could open a stronger narrative than just detection alone.
Appreciate the free tier offer, I’ll definitely test some of the advanced endpoints. 🚀
"Visibility gap" — that's exactly the right framing. The product does more than the landing page communicates, and that's on us to fix.
The contextual panel idea is spot on. Right now after a detection result, there's no clear "what next." Showing "Compare with another site," "View history," or "Monitor this domain" right there would make the advanced features discoverable without someone having to dig through the API docs.
On the monitoring front — we actually just built a domain monitoring scheduler that automatically re-scans subscribed domains on a daily or weekly interval and sends webhook alerts when the tech stack changes (new tech added, tech removed, version changes). So the "Monitor this domain for updates" flow you described is exactly where we're headed.
Agreed on positioning — "tech stack detection" undersells what this is becoming. Detection + monitoring + security insights (via CPE/NVD) is a stronger narrative.
Looking forward to hearing what you think after testing. Offer still stands — happy to bump your free tier if you need more requests.
I love where this is heading.
Once you add monitoring + security context into the story, the product shifts from a “use it once” utility to an ongoing intelligence layer. That’s a completely different category psychologically.
“Tech stack detection” feels transactional.
“Stack monitoring + change alerts + vulnerability context” feels mission-critical.
The monitoring scheduler is especially powerful because now the value isn’t just discovering what a site runs today, but knowing when something changes. That’s where stickiness and retention naturally increase.
From a positioning standpoint, I’d almost experiment with language closer to:
“Monitor and analyze technology stacks in real time.”
That subtly reframes it from tool → system.
And once the post-detection UI surfaces those actions (Compare, Monitor, View History), the product depth becomes obvious immediately instead of hidden behind docs.
Really strong iteration here. I’ll test the advanced endpoints and share more structured thoughts after playing with the monitoring flow.
I can definitely help you with the before and after design
Just shipped it. The homepage now opens with "Monitor and analyze technology stacks in real time" — your exact framing. Felt right the moment we read it.
The post-demo experience is completely different now. After someone analyzes a site, three action buttons appear: "Compare this stack," "Track changes over time," and "Monitor this domain." Same flow you described — bridging API power with user clarity.
Features section now leads with monitoring and alerts instead of raw detection. The whole page tells the intelligence platform story instead of the "another detection tool" story.
Check it out: https://detectzestack.com — would genuinely love your take on whether it lands the way you envisioned. And still very open to the design help if you're up for it.
Really appreciate this — especially the "monitor and analyze in real time" framing. That's a much stronger hook than what we have now. The monitoring scheduler with webhook alerts is exactly that story, and you're right that it's buried.
Would love to take you up on the design feedback. If you want to kick the tires on the advanced endpoints, here's what's live:
All on the free tier (100 req/mo, no card). The docs are at https://detectzestack.com/launch — would be great to hear what clicks and what's confusing.