Turn it into a product for corporate surveillance and you’ll have a much bigger market.
Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
221–230 of 240 posts
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#222Earlier quoted context omitted.
You don’t need 10 people to run this business in 2024. They could definitely do it with half that. They could probably do it with 2 people. If they do staff up (eg if they have raised capital) they will eventually go up market or into adjacent markets. That said, there are millions of software developers in the world. They can probably find 26k customers.
I used 10 as a nice round number. You can scale it up or down with linear effects on the rest of this napkin math. Their careers page by the way has 8 open positions as of the time of this writing. Don’t get me wrong, I’m not saying this isn’t viable, I’d just like to understand how.
The economics are very different though without the overhead of a large team.
If they have 8 openings they have raised a round and probably already have slides in the deck about their plans to go upmarket and sell giant licenses to large tech companies. They want to close deals that are 25-100k/year that cover big chunks of the org.
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#223Thank you all so much for all your feedback and support. The team and I are blown away by your ideas and thoughts — it means a lot and it’s been such a magic of the internet moment to get to talk to 150 of you about this project we’ve spent four years on so far. You’ve helped us decide on some next features and I hope when you see them ship they are what you hoped to see when you suggested them here in this thread. Thank you all, HN you are an awesome place. Have a great weekend, y’all!
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#224Earlier quoted context omitted.
That's all well and good, but even a halfway engaged PM is going to play with the product while it's in development, and they will tell you about what they discover along the way. It may not strictly be their job but they're going to do it. If a tool exists to help them capture more information that makes their inevitable reports more useful, is that a bad thing?
There is a nuance here: those reports from management should go to QA, not to developers. If QA can't transform manager report into a proper bug report, then it's not worth anything. Also, QA will have time to verify the fix, unlike managers.
That assumes a company that has dedicated QA staff. Most these days don't, and the above comment discusses engineers doing their own QA.
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#225Earlier quoted context omitted.
Agree, it's a debugging tool for what users see, and users see your app on WebKit in Safari. So agree, the PdM should not be using Chrome. I suggested the Kagi Orion path elsewhere in this comment page too, since that would give the PdM extensions, while still seeing what users see.
But with a fork of WebKit? I don’t think another fork is all that helpful in the context of trying to fix a bug.
It's not a fork of WebKit. It uses WebKit.
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#226Earlier quoted context omitted.
But with a fork of WebKit? I don’t think another fork is all that helpful in the context of trying to fix a bug.
It's not a fork of WebKit. It uses WebKit. https://blog.kagi.com/orion-features https://blog.kagi.com/orion-new-features
Ahhh.
Someone said Safari fork but not WebKit fork.
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#227Had a quick look. Seems like an interesting tool. I know there are many companies in Europe that, for regulations and compliance reasons, cannot have their data leave Europe. As far as I can see from the documentation, the data is stored in the US. Would be nice to have an option to store the data in Europe. Or not having to upload any data at all. But instead have the option export an artifact that can be processed…
I am building a version of this that lets you store the data on your computer, you can export it and send it to your team (manually) so you can use any data hosting you want. Let me know if you're interested!
I'd also be interested, at least for internal bug reports and such. From what I can see, jam.dev is collecting what I collect for dev-teams anyhow, just faster and more comprehensive.
But this would possibly move customer data in requests and screenshots out of our control, and the entire hassle of adding subcontractors and managing order data processing agreements have taken quite a few good monitoring and debugging tools out of discussions, sadly.
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#228Earlier quoted context omitted.
Yeah sure but this is tool for internal use
Agree, it's a debugging tool for what users see, and users see your app on WebKit in Safari. So agree, the PdM should not be using Chrome. I suggested the Kagi Orion path elsewhere in this comment page too, since that would give the PdM extensions, while still seeing what users see.
Man. It will literally never stop being funny to me when people try guilt-tripping developers into adding Safari support. It's the exact same shtick, every single time:
"Can we have Firefox support? It would really help promote the Open Web."
"Sure, it was on our roadmap already."
"AKTLY You need to rewrite your app for Safari support and WebKit coverage because if you ignore that then imagine how bad the iOS experience will be!!! People will blame you instead of themselves because they're simply too domesticated to fix technology issues, so do their work for them!"
...rinse and repeat for everything Apple refuses to support themselves. We wouldn't be begging people for Safari support if it was a successful browser or if people actually cared about it in the first place.
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#229Earlier quoted context omitted.
[I work at Jam] - Yep, your header would be scrubbed by our default definition. And also: yes definitely, configurable scrubbing is on our radar/an inevitability. Sensible defaults has been our goal, but we're definitely aware that any given keyword may be sensitive to one company but not be to another! (e.g, an address in the context of a healthcare org's patients may be sensitive, but likely wouldn't be considered…
Quick follow up on the integration with Linear: just confirmed that we do not need write scopes on the workspace. The fix will be in production by next week :)
Great, thanks!
I made a mistake in my comments above:
I meant to write "Would be neat if the *Linear* integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc."
Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
#230Earlier quoted context omitted.
[I work at Jam] We do have an internal build for Firefox.. it's coming :)
Awesome, I will check back regularly. This looks like one of those tools that is genuinely really useful. I would love be able to tell my users to just fireup a browser extension and record a bug, rather than having to step them through how to capture all that data manually. Well Done! Bookmarking this page for the futuere: https://jam.dev/docs/downloads-and-browsers/browser-support
[deleted]