My guess: Rapid prototyping of tools that use scraping as a source of data.
We actually have multiple tools that do realtime scraping as the primary data source. Many of these tools act as a simplified interface to features from another service.
For example, there is some webapp we've been using that we were using for a single feature, and that app doesnt have an API available. Using the app required many clicks, and page-loads were slow. By inspecting the HTTP requests, we figured out the minimum amount of HTTP requests required to perform our common task.
Using a simple GUI that focusses on that simple task, the user can initiate the task from a single form, and the server will perform the correct HTTP requests and notify the user whether the process was successful or not.
We have plenty of these "micro tools" that encapsulate / wrap around web apps to simplify the usage of that tool. Usually our micro tools are easier to use (because its focused around our use-case), add integrations with other tools and commonly are significantly faster as well.
They are easy to build (usually within 40 hours) and are a real time-saver, because the users don't have to keep track of all the logins, don't have to load slow web apps, and don't have to have a guide with screenshots where they need to click.
These web-apps sometimes change their request/response structure but after building a few of these tools, but it doesn't happen that often and the tools are updated within hours.
This tool generates APIs providing data, developers can make use of the API to build other tools. For example I build https://cloudfetch.info based on it. More strictly speaking, this tool is extracted from cloudfetch, because I think an API might have more use cases.
I noticed that lots of these founder interview sites (Indie Hackers, Starter Story, etc.) didn't have APIs or RSS feeds, so I put the MVP together in an afternoon. Really useful for myself even if I don't have a ton of other people subscribed yet.
We actually have multiple tools that do realtime scraping as the primary data source. Many of these tools act as a simplified interface to features from another service.
For example, there is some webapp we've been using that we were using for a single feature, and that app doesnt have an API available. Using the app required many clicks, and page-loads were slow. By inspecting the HTTP requests, we figured out the minimum amount of HTTP requests required to perform our common task.
Using a simple GUI that focusses on that simple task, the user can initiate the task from a single form, and the server will perform the correct HTTP requests and notify the user whether the process was successful or not.
We have plenty of these "micro tools" that encapsulate / wrap around web apps to simplify the usage of that tool. Usually our micro tools are easier to use (because its focused around our use-case), add integrations with other tools and commonly are significantly faster as well.
They are easy to build (usually within 40 hours) and are a real time-saver, because the users don't have to keep track of all the logins, don't have to load slow web apps, and don't have to have a guide with screenshots where they need to click.
These web-apps sometimes change their request/response structure but after building a few of these tools, but it doesn't happen that often and the tools are updated within hours.