We built a deployment SaaS from scratch, and recently got our first paying user (lessons learned + stats + UX evolution)
Hi Reddit!I’m Wouter Besems, co-founder of Launchdeck. I’d like to share with you our story and some of our key take-aways – outlining how me and my co-founder have spent time building our product and ultimately introducing a pricing model – and acquiring our first paying (“premium”) customer shortly after that.We’d love to get your feedback both on the product and our current strategy.tl;dr:https://launchdeck.ioLaunchdeck is an automated deployment service which lets you easily publish sites and applications from a Git repository to a server.Tech stackNode.js (express) back-endTypeScript (React.js) front-endLocal development environment runs directly on our machines “bare metal” – super fast integration and debugging workflow.Our staging- and production clusters are powered by a cloud provider and are based on a set of docker images with MongoDB and Redis providing our data layer.Stats7360 hours logged between the two foundersApproximately 35k lines of code23 internal repositories, of which 8 open source2100 signupsFirst paying customer on February 4, 2021Our storyLaunchdeck is founded, built by, and run by two people. My day job consists of front-end development and online marketing, and my co-founder is a full-stack developer. Even though we feel this is theoretically the perfect team for building and launching a SaaS product, a trajectory that was supposed to take one year ended up taking four (neither of us could work on the product full-time – my co-founder got his degree 2 years into the project and we are both still holding part-time positions, however we tried to take all this into account in our initial estimations).Where it beganLet’s backtrack a little bit. When I met my co-founder, we were both employed at a web agency and we ran into an issue where deploying code to a server wasn’t exactly straightforward.To deploy a small project, manually uploading using FTP seemed like the most obvious way. A huge hurdle was, however, keeping track of modified files that needed to be uploaded, and whenever something went awry, it was tricky to roll back to a previous version. On top of that, with all the build tooling entering the landscape, we would be forced to run a local build for every small adjustment made.At that point, existing deployment solutions were either overly complicated (especially for smaller projects) or were very expensive. We were looking for something well-suited for PHP-based and static applications (with or without a frontend bundle), and something that freelancers and small-to-medium size teams could understand without the need for a dedicated in-house DevOps – and we’ve mostly kept our focus there.Scratching our own itchIt wasn’t long before we had figured out our own solution: a CLI-based open source build automation toolkit that essentially just clones a repository, optionally runs some build commands, and uploads the resulting files to a server. Still, to this day, this core part of our build automation service remains open source: https://github.com/launchdeckioBecause a CLI tool can be somewhat limiting in user friendliness and visual appeal, we quickly realised we wanted to add a visual user interface and host the service in the cloud so that it didn’t have to run locally. 4 years and 7,360 hours of design- and programming work later, we’re now at the point of having a SaaS solution that allows web developers to quickly and easily ship their projects without needing to have the prerequisite knowledge of dev-ops or systems administration.Rolling out the pricing modelDuring this time, while we had beta users trying and testing our platform, we continued developing the product and eventually, earlier just this year, we introduced our premium pricing tiers.A lot of time has gone in the UI design, which throughout the years has been finetuned and most importantly: simplified. Screenshots of the various stages of this process have been included at the bottom of this post.Shortly after introducing our paid plans, we acquired our first paying customer: a great milestone! Currently we’re experimenting with various marketing campaigns and are still trying to find the optimal channels of communication. Advice would be really appreciated!Things we’ve learned along the wayPlanning: If there was one place where we were way off, it’s the amount of time it would take to build a solid deployment automation service. During most of the development process, we were both studying and/or working part-time on other projects, which meant time wasn’t always as abundant as we would have liked.Assumptions regarding functionality: over the years, we’ve made numerous assumptions regarding what we thought would make our service better. This caused us to, in at least a number of cases, focus on features that weren’t all that important to our end users. That is, in hindsight of course :)When working on new features, we iterated quickly and only once there was a functional version allowing us to actually test the feature, and we decided we actually wanted to move forward with this feature, we would go back in and clean up (or rewrite partly) the implementation to prevent build-up of ‘tech debt’ as much as possible. We’ve always been rather thorough with this – and it’s still paying off to this day.When picking the right technology we’ve tended to err on the side of safe and battle-tested frameworks, libraries and languages with a wide community backing. This has worked out very favorably in every single case although some luck may be involved there.Not a brand-new insight, of course, but splitting different parts of the codebase into individual modules or services forces you to think about abstractions (helpful) and means additional flexibility when you’d like to use a certain language or framework for a new feature or part of the ecosystem.As a first SaaS product, a deployment automation service isn’t exactly low hanging fruit. A lot had to be built from scratch (there’s no such thing as a “deployment SaaS starter kit”). Besides that, most similar competitors will have at least some 5 to 10 developers on their team. Only after 4 years of development, we’ve arrived at the point of being able to charge a fee for our product.Paid marketing: Costs for this tend to rise quickly when you’re still in the process of determining who exactly is your target audience, and what channel to use for optimal conversion. It seems to us that “conventional” channels such as AdWords, Facebook and LinkedIn are expensive but ineffective, or at least for the type of customer we’re trying to attract. We’re broadening our range now looking at sharing content to various communities such as Indie Hackers, Reddit and Hackernews.Mapping out the futureWe’re currently working to figure out the right marketing channels, and doing so with a limited budget. As our funnel becomes more profitable, we can afford to spend more time on building and expanding Lauchdeck. This is our current roadmap:Config file editor: Which lets users add and edit configuration files (such as wp-config.php or .env) without having to manually log into their server.Fully automated deployments for staging and test environments with an intelligent queue to deal with ongoing operations and starting new builds.More support for a variety of target servers or platforms such as DigitalOcean, AWS or even a proprietary hosting infrastructure so the user no longer has to bother with the server setup part of the configuration.Evolution of UXOur very first mockupFirst UI designUI redesignLaunchdeck UI 2021
