> If you don't develop this culture of ownership you end up with longer feedback loops between customer support, QA and dev.
100%, that's great
583 karma · joined March 14, 2014
100%, that's great
At Jam, we're building a flight recorder for web apps so that anyone can report bugs to engineers in a way that's awesome, actionable and debuggable.
We've only been in beta for 7 months, but already we help 10,000+ people across thousands of companies from Fortune 500s like T-Mobile to startups like Ramp move fast and better serve their collectively millions of customers.
You can check out our product (it's free!) at https://jam.dev and if you like it, apply to join us on our mission to help one million teams ship better software faster.
More about the role: https://jamdotdev.notion.site/Careers-at-Jam-a7d631308fa84a9...
Apply here (we read and respond to every submission): https://8wvzuv0oszm.typeform.com/to/MNRVQWaa
But I think "startups can afford to have bugs" is bad advice. Startups need clarity to find product-market fit, and bugs obscure clarity.
Curious to hear – what are your experiences?
The way we used to do it before where we manually uploaded the extension was cumbersome and bug prone. This is much better. If you're building a Chrome extension like we are, I hope this helps you.
Hey HN! I’m Dani, the CEO of Jam (https://jam.dev), a new dev tools startup building a new way to capture and debug frontend bugs - here's a 90 sec video: https://youtu.be/iXjmUwZLzVs.
We have raised $10M+ from the CTO of GitHub, CTO of PagerDuty, CEO of Cloudflare, etc., and are growing quickly. We're a team of strong generalist engineers (mostly early ex-Cloudflare) and we're looking for someone with experience building highly performant front-end apps.
The stack is fullstack javascript - react/typescript front end, and node/graphql backend. Every engineer on the team works fullstack.
Would love to chat if that sounds interesting to you. You can reach out: dani@jam.dev.
Our first attempt was a product that let product teams leave feedback as annotations tied to DOM elements, but what we learned is that product teams have a hard time trusting those comments as the underlying DOM does change (screen & viewport size, os/browser, geo/language, recent deploys, logged in account).
From there we went on to build Jam (https://jam.dev) - letting people quickly comment on what they see in the DOM and send a perfect snapshot with way more context than a screenshot (with even console logs and network requests attached) to a link to share or even a Jira ticket.
If you give it a try, I hope you find it’s much faster than screenshots and feedback the old way (we used to do feedback in a spreadsheet as PMs ), and would love to hear what you think! :)
Hey HN! I’m Dani, the CEO of Jam (https://jam.dev), a new dev tools startup building a new way to capture and debug frontend bugs - here's a 90 sec video: https://youtu.be/iXjmUwZLzVs. We have raised $10M+ from the CTO of GitHub, CTO of PagerDuty, CEO of Cloudflare, etc., and are growing quickly. We're a team of strong generalist engineers (mostly early ex-Cloudflare) and we're looking for someone with experience building highly performant front-end apps. The stack is fullstack javascript - react/typescript front end, and node/graphql backend. Every engineer on the team works fullstack. Would love to chat if that sounds interesting to you. You can reach out: dani@jam.dev.
Spreadsheets and screenshots? That's what we used before we started Jam. :D
Cloudflare is running a firewall in thousands of nodes in over 100 data centers. As requests are proxied through Cloudflare to the devices, Cloudflare inspects the request and checks them against a list of known attack requests. Orbit customers can additionally create custom rules to detect and filter traffic based on any traffic pattern. When rules are added, they take less than 30 seconds to propagate to all data centers, and then will protect traffic to all devices.
-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.