Comment by pimterry

The nice bit of running a project for a long time is that eventually your old answers accumulate and save you time like this :-).

That said, one point there is outdated: HTTP Toolkit does now fully support websockets too. There's more I'd like to do there, but as far as I'm aware it's equally capable to mitmproxy in that sense today.

Awesome, thanks! Glad it's working well for you :D

> What did the first iteration of this product look like? Was it more or less similar, or substantially different from the spirit of httptoolkit today?

Technically, the first iteration was https://github.com/httptoolkit/mockttp - an HTTP integration testing library for JS. Not a desktop app at all! I'd originally built that for testing uses, but as it matured I realised that with a UI and automated setup tools it'd be useful as a complete product (but Mockttp still powers all the internals today, and you can use it directly to build your own custom intercepting proxies too).

For the first real product, the very first public 'launch' was literally a landing page with some demos of the potential UI and a signup form, just to test interest and check it wasn't a terrible idea. The results looked promising, so that was followed a few months later by a very basic but usable free version (entirely read-only, and only supporting Chrome interception) with the freemium features on top appearing a few months after that. From this stage it was all very much the same spirit as today, just less feature complete.

> How did you go from (some semblance of a product) to first sale? / acquiring first customer?

Once I announced the paid version (a blog post to my tiny set of newsletter signups, plus a little response on HN/Reddit/Product Hunt etc) I got a handful of paying customers (but certainly less than 10) within 24 hours. Nice but not a meaningful income, and from that wild peak it dropped back down to maybe one new customer per week or so afterwards, so it was quite slow going at the start.

However, those paying customers (and the mere fact of offering a paid service generally) resulted in _much_ better feedback. Rather than "this is cool" all of a sudden I had real demands for specific features, from people with concrete use cases and money in their hands. The initial paid features were just made up off the top of my head, and honestly didn't create a particularly compelling paid feature set. It's very hard to really know what people will pay for! That feedback was incredibly unbelievably useful to fix that.

From there, building out the key features people asked for over the following 6 months boosted things very significantly, and started to get things moving for real, and then you get into a virtuous circle, where more users => more feedback => better product => more users => ...

> did you spend anything on marketing/distribution?

I tested advertising at a small scale for a few months, but it didn't really work great. I think largely because it's very very freemium - 99% of users pay nothing - so the acquisition cost for a paying user doesn't make sense, and also honestly I don't have much experience with ads and I'm not sure I'm any good at writing them.

Content marketing meanwhile has worked great, keeps passively returning dividends, and cost nothing. I've tried to fill the blog (https://httptoolkit.com/blog/) exclusively with detailed & high-value original content (detailed breakdowns of a recent HTTP security vulnerability, not "top 10 HTTP libraries for Python") which shares well on social networks for an immediate burst of traffic, and then (in most cases) provides both a long-term SEO boost and constant incoming traffic on related topics that converts into users. That starts slow, but again steadily builds up over years, if you keep working at it. Content marketing + SEO are pretty much the only marketing channels I work on right now.

Thanks! Yes, I found that a huge percentage of visitors to the site were on mobile (especially for HN/reddit/etc traffic) and when your product is a desktop app there's not much you can do with that, so for a long time I effectively didn't have a call to action for most visitors at all, which isn't great for anybody.

Under the hood it's just a tiny automated email flow set up via Mailchimp that sends out the download link when you sign up. Nothing fancy, but it's easy and it does the job.

Yes: ease of use, lots of additional power (for starters, you can modify traffic, not just view it) and being able to intercept anything (multiple tabs, multiple browsers, mobile, docker, CLI tools, backend services, you name) all in the same interface.

For the web dev case, for example, if you're debugging some interaction that means you can intercept your browser <-> server traffic and your server <-> upstream API traffic all in the same place, and see the full flow, and you can modify server responses or backend API responses in flight, to test out different edge cases.

There's a Chrome dev tools vs HTTP Toolkit comparison page here with a little more detail: https://httptoolkit.com/chrome-devtools-alternative/

> Do you mean that improving documentation helped get customers?

It probably did, but no that's not what I mean, sorry :-). By "rewriting support" I mean adding features that allowed you to rewrite arbitrary network traffic, rather than just viewing it (as in the very first PoC).

Does it work for apps with pinned certs?

You can proxy anything, it's just the "intercept the entire system" isn't automated here (because targeted interception is usually preferable).

For system-wide setup, you'll just need to configure that manually - setting your system proxy and trusting the CA certificate. The settings you need are on the Intercept page, in the 'Anything' section. For portable browsers, you may also be able to configure proxy & CA settings within the browser itself, which might be more convenient, depending on your setup.

Not really! To be honest it's a bit of a hassle and I don't have good tooling or a proper setup. I write a little script, then just record myself manually clicking through it (which is boring, and takes a bunch of tries to do smoothly) and then load it into iMovie and trim it down and speed up any awkward slow bits. It's not a perfect solution at all, but it does the job and I only update it once a year or so.

In a perfect world, I'd kill for a tool where I could define a script (something similar to a Playwright test) and it'd automatically run and record everything, so I could redo the video much more frequently and accurately. I think you probably can do that for a normal web app already (?) but the challenge here is that HTTP Toolkit is launching other apps that also pop up over the top, and so I need to record them all together.

If you're looking for inspiration around this sort of thing, the Android demo video is different and also worth looking at: https://httptoolkit.com/android/

It depends :-). If it's Android (like a Fire stick) then in some cases, but all the Android caveats apply, e.g. you'll need root access to access traffic from apps that don't opt-in to debugging. For testing your own apps that's fine, but for reverse engineering HTTPS traffic you'll generally need a rooted device. In practice, if you don't already have a rooted phone on hand it's usually best to use an Android emulator on your computer, since most of those provide root access out of the box.

Even with root, certificate pinning can cause problems (as the sibling comment points out) but you can usually defeat that fairly easily: https://httptoolkit.com/blog/frida-certificate-pinning/.

For non-Android, HTTP Toolkit can't set it up for you automatically, but you can absolutely intercept _anything_ manually if you can configure it with your own HTTP proxy setting (fairly common) and add a trusted CA certificate (less common).

Not him, but probably not. They likely use HTTPS with certificate pinning