Hey Lyn and Colin,<p>Cool stuff! I worked on a very similar project for a small chunk of my life. I was a PM whose life was made a lot harder by not having a tool like this and when I joined a startup that had built a similar tool internally, I realized that it would be a great business. I want to provide some free (and unsolicited) advice:<p>Your number #1 challenge is going to be go to market strategy. There are actually a number of companies that have tried to solve this problem and either outright failed or seemingly hit some bumps. YC funded a few of them: Release, FeaturePeek, Dockup. There's also a company called Runnable that was acquihired by Mulesoft. Initially I was encouraged by the proliferation of companies in the space - we couldn't all be wrong. In hindsight I should have realized that it wasn't as rosy as I had thought since it doesn't seem like these companies have had gangbusters success.<p>In my experience, there are roughly three types of pushback you're going to get from potential customers:<p>1) We can build that better in a week. This one is very difficult to overcome because at the end of the day it's not really about the truth of the statement, it's more about the engineering skill of your prospect. Building this product is a unique and interesting engineering challenge, and I haven't met a DevOps person who wouldn't be excited to try to build it themselves. I tried a lot of different approaches but have never successfully convinced someone it would be a lot easier, faster and more efficient to buy an already existing solution from us. Your mileage may of course vary.<p>2) Our setup is too custom to work with any generic tool. This one is probably pretty frustrating to hear since you folks have clearly put in a lot of effort to make it work with a variety of build configurations. The interesting thing here is that this reason can often then turn into (1). Our solution required people to containerize their app if it was not already and most people replied that if they were going to do the work to containerize their app, they would just do a bit more work and build this internally.<p>3) My database is too big/too sensitive to work with this. Many startups have small databases that can easily be copied quickly. However, some have multihundred gigabyte ones that are too large to copy on demand. You either have to include that latency in the product which in my opinion makes it borderline useless, or figure out some way to work around it. You can use RDS snapshots but by our calculations those will be quite expensive. You can hope your customers have some test database (they don't) or you can try writing back to their shared staging (or more realistically) their production database. None of these options are realistically very attractive.<p>All of that said, it's clear you have some really cool technology here. One thing I'd suggest you'd look into is a related market: developer environments. Most companies I've worked at have software engineers putzing around for the few days/weeks getting their dev environment set up. This is a very expensive waste of time IMO. If you could provision a cloud development environment on demand, that doesn't require any scripts to set up or database migrations to run, that would be huge. The value of skipping that ~2 week setup time multiplied by the number of engineers a company hires really begins to add up. Just my 2c.<p>Happy to chat about this more if you're interested. I don't feel like sharing my contact info on HN but if you are determined enough I'm certain you can probably get in touch. Best of luck :)