Having trouble converting traffic for Developer Tool MVP

Thanks for taking the time to go through the site! Will definitely take this to heart and work on updating the landing page.

I think our ideal client is a developer or team of developers building applications that do some sort of data processing -- data processing that is too intense or too long-running for a web server (you wouldn't want to make your users wait for it during a web request).

I think it's easier to explain with an example: e.g. if you wanted to get the weather using a weather API for 1,000 separate locations and wanted to periodically update the weather on a schedule of 5 minutes or so. You could do this using Lambda or Azure functions and some queues and whatnot. A competent developer could make that work with some engineering effort. We are trying to make a scenario like that trivial to implement. You would create a job that does the meat of the work -- hit the weather API and update your datasource that your frontend uses. You then upload that job to Runly and we manage the deploying and scaling to your nodes (which could be in the cloud or on your own hardware) as well as the scheduling for you.

Besides the devops stuff, the value-add that I find most compelling (which I'm realizing we don't mention anywhere on the landing page - it is buried in the docs) is the ability to then easily integrate feedback on that long-running job in your frontend. We provide a bunch of JS components that you can drop on your page to show progress bars, retry buttons, and more.

So, the gist is, it's nothing you can't already do with some development know-how. It's more about making it easier and helping developers fall into the pit of success when it comes to scaling and best practices for usability of long-running jobs.

The idea we are trying to sell that maybe we aren't making it clear on the landing page is that we are making it easier and seamless to do things as a developer that you are probably already doing. e.g. easy to integrate feedback into your webapp on long-running jobs. easier to do deployments of background jobs than something like Azure Functions or AWS lambda.

I'm thinking we need to get to more of that on the landing page instead of burying it in the docs.

Conversion rate is 7%. Most traffic is coming from a Google Ads campaign we recently started. I gave myself a crash course on Google Ads last week and kicked off a search & display campaign at $10/day. It hasn't really generated the traffic I was expecting.

I'm realizing we don't really talk about the unique value proposition on the landing page. I feel like we make a lot of points in the documentation, but it doesn't seem like people are getting that far.

Thanks for the feedback!

Yes, we chose to launch with .NET/C# as that is what I have worked with the longest and am most familiar with. Although we have grand plans to support JS/Python/Ruby if we can get some traction. Maybe that should be clearer.

We aren't trying to compete with lambda or other serverless function platforms. It's more of a way to run background jobs using your existing infrastructure and cloud assets allowing them to play nice with each other.

And it is prescriptive in the way it allows jobs to be run so that you can do things like standardize on output and provide pre-built frontend components to give the user feedback.

I think the biggest hurdle I was having before launching was trying to distill what this is and what it can do into a quick little blurb. I feel like it is nuanced and I guess we haven't gotten there yet.