Rezden

First off just want to say nice work on building something and getting it out there!

I've spent a couple of years consulting on Kubernetes to many different companies and honestly don't fully see the use case here. In general, the hosting and managing of Kubernetes is the hard part, rather than the deploying apps onto it. Now if you want to tackle the continuous delivery/continuous deployment space on Kubernetes that would be a target that I think makes a lot more sense. Managing releases and complex deployments is hard for everyone and as a result that space is $$$$$.

More food for thought is that in general the people using Kubernetes in their organizations are not the little guys. I love Kubernetes, but it is a pain to manage if you don't have dedicated resources for it, which most smaller organizations don't. If you are correctly able to target these bigger orgs, then kudos to you, that is big money. But things like security and compliance become very important, and having basic auth as your security offering is not going to fly there, you'll need integrations with their SAML/SSO.

Then there is the matter of trust. How can I trust you with access to my internal Kubernetes cluster? That will set off alarms with any sort of security teams if your product gets proposed.

And letting the customer use any Kubernetes cluster is going to be a serious nightmare for you to support. Every Kubernetes cluster that isn't an OOTB one spun up by GKE, EKS, AKS, etc. is going to be different and there will be a thousand ways that your PaaS will break due to their weird environment and they will need you to spend lots of time figuring it out and fixing it.

Also, in general, people who use Heroku are not the same people who are running Kubernetes clusters. Kubernetes is expensive to use. Sure you can spin up a cluster on some VMs on the cheap, but for an organization to actually use it they need to pay for someone to support it, or to have someone spending time supporting it, either of which ends up costing way more than Heroku.

I haven't tried out your tool yet, so I don't know if this is a part of it. But I think it is poor practice for devs to use a PaaS and skip the actual CI process. Heroku has its own pipeline concept and CI tool, you'll either need your own CI tool or to integrate with popular ones like Jenkins, Drone.io, etc. Code should always get tested and have to pass gates before it gets deployed.

Lastly, the price point is way too low. If you are actually going to be supporting people using this, that price point of $49/month should be $49/user/month, but likely that should still be higher. I'm not joking when I say that the level of support Kubernetes customers need in general is very high.

I hope this is useful and is not discouraging. Kubernetes is a huge space right now and the money is out there for the taking. I think if you refocus your offering to the enterprise space you could come away rich. But I think the low-price market for Kubernetes is a waste of time, it is a market that for the most part doesn't exist, and even if it was a big market the time and effort supporting it would way outweigh your current price tag (or what they would be willing to pay). I could go on for hours about this topic, but really I hope you don't see this as me bashing your service, I just want you to be successful and think your current offering will give you a big uphill battle.

In any case, I wish you the best of luck! These are exciting times.

Cool David. I've also been enjoying learning about Kubernetes these last 4 years, and I'm continually amazed at what it can be used for.

I think one thing that's tricky about making things for Kubernetes devs is I think if you know enough about Kubernetes to understand how to get a cluster going, authed, etc., you probably also know enough to get your app deployed. What do you think the TAM is for the set of people that know how to "Just bring a Kubernetes cluster, and nothing else." but aren't willing or able to host their apps themselves?

As a data point, my usual alternative to this is to helm install gitlab-ce and then use GitLab CI and/or (for 'automatic-ness') GitLab Auto Devops. With that said, running GitLab in a way that isn't sloooooowww requires more than just tiny-cheap VMs in your cluster.

I'm not saying this isn't a worthwhile idea. But I wonder if it would be better marketed to people who are either non-devs or developers who haven't done much devops/infra, e.g. frontend devs. Maybe people who have never even heard of Kubernetes. In that case, your messaging might be better off just focusing on the value prop of "Automatically deploy your app to your servers" without focusing too much on the jargon of "Kubernetes". This might make the set of people you can market too much bigger, because you can actually be a way of teaching people what kubernetes is and how to use it. Or you could even abstract it away entirely and just say "Log in with your Digital Ocean OAuth and Rezden will set everything up for you".

I wanted to see if after signing in maybe you already do that?
I tried to sign up with GitHub (u: gobengo) but got a "We're sorry, but something went wrong." once redirected back to app.rezden.io after oauthing. (No sweat, it's early, but wanted to let you know in case you don't have error reporting up yet)

Some other thoughts

• In your post here you compare cost savings to Heroku: Can you play that out with some back of the napkin math? If so, and the savings are meaningful, that could make for a good argument on the landing page ("If you use Heroku now, we can save you money!"). Probably a really low-scale app on Heroku isn't cheaper to move onto k8s, but after some amount of traffic and compute requirements, Heroku probably does get more expensive. It'd be helpful for you to advise on where those lines cross.
• I wonder if less k8s-savvy folks might be dissuaded by "Just bring a Kubernetes cluster, and nothing else.". It might help to let those people know right around then that you can can help them set these up using AWS/GCP/DO hosted options. That way people don't get scared off and keep scrolling to see the "No Kubernetes knowledge needed" which is a bit farther down and off to the right.

Best of luck with this. I'll try again in a few days to log in and click around.

Looks promising and could be a success, if framed and communicated properly.

Overall its clean and you can easily read and skim the copy. I won't comment on the copy just the overall UI/UX of the page.

Hero: I would move the logo to top left, Sign Up button move under the copy, (div content).
Keep the login button on the top right where it is now. To the left of the button I would add text that says About, Pricing and Subscribe - that will bring quickly you to those sections of the page. (People always go to the pricing section pretty quickly when they land on product page, having that at the top helps them navigate quicker.)

Blade 1 (content under the hero): the third image (Extremely easy application configuration) you need a better simpler image here to be consistent with other too.

Blades 4 - 6 : You need to reconfigure the images (by which I mean fake it a bit) to make it bigger and clearer. Some text in the images are cropped you want to fake it move them over for the screen shots. You want this as clear as possible for the users.

Blade 7 (Simple, predictable pricing): Right now the FREE stands out to me on first glance. Add different blue values for each price boxes - I would make the middle price box text $9.99 a darker shade of blue so it stands out - just to draw the users eye to something other than FREE.

It's a good landing page and relatively thorough. However, the initial landing feels a bit empty. Also, I'd toy with the contrast a bit.

Other than that, nice work.

The questions I'm left asking are generally technical:

• What are the supported platforms? Node? Dotnet Core? Java?
• Why choose this over Pipelines, Appveyor, Jenkins etc. ('Simplicity' is the correct answer here!)
• How do I configure dependencies. I currently lean heavily on docker compose.

A description of a typical deployment would be useful to have.

Hey - I would say the most important thing is that you are missing a few CTAs in the hero and the other sections of your landing page. And you also should think about adding some social proof.

I invite you to read this: https://www.julian.com/guide/growth/landing-pages