
Valist
On-demand staging evironments for agile web development
I knew from the start that to sell my product, I need to write compelling content to try to explain more deeply why the product is needed; a landing page would be difficult to provide enough context to sell something most probably never considered even looking for.
The first and so far only content I've published is on my website.
https://www.valist.dev/blog/why-you-need-a-staging-environment-for-every-change/
It has not gone viral or generated any huge amount of traffic and not even a single sign up. However, I've seen 100+ new users daily the last 2 days on my website which is a significant increase from before.
I will continue writing and publishing more content in hopes that it will continue to drive traffic to my website and hopefully one day entice somebody to sign up and try my product.

So about a month ago I submitted my app Valist to BetaList to try to attract potential customers.
Although it has been on the front page for almost an entire day now, it has not generated a single sign up and the number of visitors is less than 100 according to Google Analytics.

Comment
Until now, it has been possible to use Valist for free. Now, you will instead be met with a paywall after the trial ends, and deployments will no longer be possible to start until a payment method is added.
Although stripe just added their hosted portal to manage subscriptions, I chose to integrate their API directly in my application to provide a more cohesive user experience. It took me about one day to implement this so maybe I could have saved some time using their portal. However, getting the experience of using their API forced me to learn more about how their platform works and getting experience I am sure will benefit me in the future.
This was the last major piece in developing my service. Now I can worry less about having an unfinished product and continue to iterate.

Comment
Having no previous experience in sales, I knew that this is the greatest obstacle I have to be able to get this working. I am confident that I can create a product that fits a market having worked both as a software developer and product manager. However, selling a product requires skills I need to acquire.
So the last week I've been reading up on a lot of articles about cold emailing to understand how to succeed with this.
I am starting small with a few companies. The way I am doing it now if fairly inefficient and I definitely need to create better automation for this.

Comment
For the last few months, it has been hard to switch focus from adding new features to my product to focus on marketing. So far I have not had a single person sign up to my product or even newsletter so the need for better marketing is clear. The product is now at a state where it is working and can definitely add value to teams developing web applications even though I can think of many features I would like to add.
I wanted to reduce the effort required to understand how to use the product. My audience is broad, ranging from programmers to product managers. I know that for a product manager, it would be difficult to see how my product works without integrating it into the development process. So I did a few things.
First, I started by trying to more clearly describe my value proposition on the homepage. I want to convey that it requires little effort to set up and that it can add value by solving a problem I think a lot of product teams have.
Second, I added a way to book a demo with a simple tool that's free called Appointlet. I can't say yet how effective this is but it should help me get in contact with users. The demo is not just to show how the product works but also a way for me to better learn from potential customers about their circumstances and how I can add value.
The website is available at https://www.valist.dev

Comment
After about 3 months of working on the first release of Valist, I finally have something functional to show for it.
What's interesting with this project finally at this state is that as I build the product, I can use it myself to aid my development. The product enables product teams to see and test every incremental update to a product with automated deployment of staging environments. So every time I make a change, I will automatically try the product myself. So as I now can easily force myself to use the product while developing it, I can learn a lot about everything that may annoy a user so that I can make a better product without long feedback cycles.

6 Comments
6 Comments
-
1
Hey Adam, I can relate to this problem somewhat as a developer. I thought to leave my 2 cents here, in case it might be useful to you.
The problem is probably not too much a problem in small teams where there's little chance of clashing with a colleague over environments.
I remember it was enough of a problem at a bigger company I worked at, which had DevOps develop a homegrown solution to automate the deployment of Dockerised apps via ECS for PR testing. There were more engineers (20+) who could potentially step on each others' toes without enough testing envs. Devs waiting for builds, waiting for others to finish testing and getting blocked is a bottleneck that I'd hope most CTOs want to solve.
Whether a company will adopt an external solution I can't answer (I hope your customers will!) but I like to go by the mantra of "don't give them a reason to say no": have you considered CORS issues with a different domain, need for multiple seats/instances for bigger teams, etc?
I hope this might help with your assessment of audiences to target. Of course, you may already considered the above and I may be adding little to nothing to the discussion! π
-
1
Hi! Thanks for your input. I've seen this be a problem in teams with ~5 developers working on the same front end application but on different features or bug fixes that need to be validated by a product owner before going to production.
Depending on how the application is built, CORS could be problematic if the front end needs to talk to a backend on a different domain which is very restrictive in which domains it can accept. If the backend is part of the application like for applications that are partly serverside rendered like Express.js, Rails, etc, the backend will be on the same domain. Every build has a unique subdomain so the frontend can connect to the backend on the same domain.
The product is built with teams in mind so there is functionality to invite people to join your "organization" like most other SaaS applications.
Bigger instances should not really be a problem. It is running on AWS. The current price plan contains 1 GB RAM which should be enough for most applications. I tried to not make things more complicated to start with but I can easily create new pricing plans with higher resource limits if needed.
I have tried to reach out to CTOs via cold emails without much luck so far. Not sure if I need to work on my marketing, product or just continue with cold outreach.
-
1
Will mail you a couple of other thoughts! π
-
-
-
1
Hi Adam, I recently wrote to you in a thread somewhere, and didn't receive a reply. Our products seem to be very similar, and even compete a bit.
I also made an app that does the exact same thing, called Pull Dog: https://github.com/apps/pull-dog
Would you be interested in a quick chat or talk in regards to a business proposal?
About
Create more successful web projects by creating tooling that lets developers, designers, product managers and other stakeholders get access to versions still in active development to provide valuable feedback early.



Comment