First usable version
by Adam RinghedeAfter 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.
-
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?