8 Things New SaaS Developers Need To Know on DAY 1

if you're a software developer it's almost inevitable that you've heard of software as a service or SAS and something that most developers don't quite understand from the start I know that I didn't back in the day when I was writing code and building software for other people is that SAS is its own animal it's so different than building client projects it's different than building websites SAS is challenging and it's complicated there's a lot of things that you're going to want to learn before you dive in and build your first SAS product and that's what I'm going to cover in today's video it's eight things new SAS developers need to know on day one so whether you're a new developer with only a few months of experience or whether you're a senior developer who's just never built their own SAS this video is going to dig into the things you should know before you get started I'm Rob Walling I've started six companies five of them bootstrap I've written four books on entrepreneurship and I've invested in more than 125 startups in order to create this video I Enlisted the help of a few friends the first is Derek Reimer you may know him as the founder of savvycal he also so was my co-founder with drip he's built SAS apps that have generated tens of millions of dollars in revenue and have processed billions literally billions of database records and emails sent pretty much any metric you could look at so Derek is a very experienced SAS founder and I wanted to bring him in to help with today's video he's going to give us four of the eight the other four I pulled from a Twitter thread that's filled with Incredible suggestions I had several of my own they were echoed by many of these folks and then there were some additional suggestions that I wouldn't have thought of and with that I'm going to kick it over to Derek to hear his first thing that he thinks new SAS developers need to know my first tip is continuous delivery is the key to shipping fast the worst case is when you take on a large project and it stays on a feature branch that runs for weeks or months and you have many thousands of lines of changes it's hard to reason about merge conflicts Stack Up and worst of all you lose momentum on the project so it's much better to break projects up into the smallest shippable units possible and deploy those to production as early as you can and if it's something user facing then throw it behind a feature flag this comes with a number of benefits one it's just easier to reason about small code changes and two shipping just feels good right there are psychological benefits with the momentum of feeling increasingly confident in the bones of a feature and finally I've found that projects often wrap up earlier than I expected because as we're shipping these small parts we find that the feature is actually usable as is and we don't need to do those extra 10 tasks that we thought we were going to need to do and so my first tip continuous delivery is the key to shipping fast for the second thing new SAS developers need to know I head to Twitter and Phil Frio weighs in with think through your users team organization slash account slash billing model really well getting it right can save you a lot of time later on building SAS is like putting software into production and then having to rearrange things constantly as customer needs progress if you've only Built software for internal teams oftentimes you have a user base of 5 or 50 and you can have downtime you can change data models it's not the end of the world to do so with SAS you hit 500 a thousand ten thousand customers or users and it's really hard to make these fundamental changes so I like Phil's advice to really think through the data model and probably get some advice on using a lot of one-to-many relationships for example instead of oh I'm sure it'll be one to one Forever Until users ask us to make it one to many so I tend to think about data models in SAS as needing to be much more flexible and a bit more gold plated than in traditional software development and for the third thing new SAS developers need to know I'm going to kick it back to Derek my next tip is that onboarding should not be an afterthought from day one of architecting the flows of your application you should be thinking about what Journey the user is walking through each step of the way and you should start with the assumption that they know almost nothing about your product unlike you right and so you want to make sure that they are getting educated and getting to the point where they feel like they have superpowers because of your product as quickly as possible there's not really a one-size-fits-all solution for this but I generally see it happen in two separate ways one is the in-app product experience so for example I run a scheduling tool and the user connecting their calendar is really really important for them to get any value out of my product so that's part of an initial onboarding wizard that I have where I ask the user hey at this next step please connect your calendar before continuing so then when they make it into the product they can see a scheduling link with their calendars already connected and also there's the more passive element of email onboarding sequence right you don't have to over complicate this initially but you want to at least welcome the user thank them for signing up for the product provide some education about how to get the most out of it and provide some touch points for some subsequent days after they sign up to remind them that they signed up for your product and hopefully nudge them back into your in-app experience to get them activated Point number four comes to us from Casey Allen on Twitter he says never take advice from someone that has not built from scratch working software that people actually paid for if they haven't the advice is usually the opposite of what you need to follow and will cause you to fail I couldn't agree more there are so many people on social media and on the internet in general who talk about things that they really haven't done they aspire to have done and they embellish on their resume a bit and those folks can easily maybe mistakenly maybe accidentally give you really bad advice so pick who you listen to who has done this at least once maybe twice exactly what you want to do and I don't mean I built a SAS app to 20 or 30 grand a month when you want to build a SAS app to 500 000 a month those are very different animals so I like Casey's sentiment of choosing well who you listen to and for our next point back to Derek my next tip is to choose a boring Tech stack I see folks fall into this trap all the time you're breaking ground on your new project you've been reading about a bunch of hot new technologies services on Hacker News and you figured now is a good time to try out all the new stuff and wrong I think you're only going to make your life more difficult because ultimately your customers don't care what tech stack you're using and if you're adopting a bunch of new things you're probably going to build slower you're going to be delivering value slower to your customers you're going to be hampering your ability to validate your product quickly and potentially you're setting yourself up for building on a foundation that falls out of favor maybe it's no longer the new hotness maybe it's it doesn't catch on and now you're using a bunch of technologies that not many people know down the line when maybe you're more successful and you're trying to build out a team so my recommendation is to just stick to the battle tested tried and true Technologies and web Frameworks to get your SAS off the ground and let you keep focusing on what's most important which is delivering value to your customers 0.6 comes to us from Twitter from Gerard Broad and he writes it's important to know basic definitions I think I met you at SAS Fest and paticus was there as well I had no idea what sass meant what mrr ARR MVP especially MVP met and that would have saved me a lot of money and time I need acronyms for sass dummies this is one of the reasons I'm glad I went to Twitter for these because I wouldn't have thought of these I'm too deep in the SAS world now to think of things like this but he's right there are a ton of acronyms ACV LTV mrr we shrink all of our metrics to these tlas three-letter acronyms if you really want to dig into these acronyms I recommend a podcast episode I recorded in the last six months with my 12 year old son it's called teaching SAS metrics to a child and we start all the way at the beginning of what is revenue and profit and income and then we dive into recurring Revenue we look at mrr and ARR we go all the way through I believe expansion revenue and net negative churn I think is where we end so pretty much we go through all all the 101 version of SAS metrics that you should know my final tip is don't skip the tests now I've seen some debate among Indie hackers about this some advocating that you shouldn't write unit tests or functional tests or system tests at all because you're just trying to get a product to Market as quickly as possible I think there's some Merit to that but I mostly don't agree because I think it's worth giving some consideration to what if this product does actually work and then you find yourself in the position of having code base that's riddled with technical debt and bugs slipping in left and right because you haven't bothered to look after your future self and write some tests to make sure that the core functionality in your application is actually Rock Solid and so I would say it lies somewhere in the middle you shouldn't test every single nook and cranny of your code base and spend 50 more time doing that but you also shouldn't write no tests at all I think it's most important to focus on functional or system tests that kind of test entire portions of your staff unit tests are a little bit less vital in the grand scheme of things but I would say at least at a bare minimum write tests for the core pieces of functionality that would be really bad if they broke or if bugs slipped into them and your future self will thank you when you are not having to rewrite your code base because it's become unmaintainable right when you're starting to gain traction thanks again for that Derek and for contributing to this video and making it a lot better than if it was just me sitting here talking to the camera for our eighth and final point I got a lot of folks talking about learning marketing and valuing customer communication we as developers think that product is the most important that features are the most important but in fact it's marketing and talking to customers in my first book start small stay small I kept repeating this Mantra product last marketing first this was a book aimed at software developers and I was trying to drill that into their heads and I heard it from several folks on Twitter like Kristoff who said building software is fun but marketing is the blood of a SAS business so easy to get caught in the endless feature building Loop also heard from Dennis who said build it and they will come never works John Moody said if you build it they won't come Field of Dreams does not apply to SAS marketing is key Jack Ellis the co-founder of fathom weighs in with talk to potential customers not just your friends and John and dege weighs in with nothing is more valuable people than speaking to customers I'm not sure how much more I have to add to that I think every developer comes into SAS not understanding that marketing and talking to customers are two critical elements of building a successful company if you've seen from the outside someone build an incredible SAS business you know that they were doing these two things no one gets lucky enough that they don't have to Market and don't have to talk to their customers thanks again to everyone who weighed in on Twitter and to Derek grimer for joining me in today's video If you like this video hit the like button and subscribe to the channel I'm putting out a video like this every week for Developers for SAS Founders for people who want to build incredible businesses where they bootstrap or mostly bootstrap I'll see you in the next video [Music] thank you [Music]

Channel: MicroConf

Views: 17,593

Keywords: MicroConf, Saas, startups, startups 101, software developer, saas developer, saas business, saas startup, programmer, app developer, saas founder, building saas, building an app., developing an app, saas product, b2b saas, saas dev, app dev, app development, saas development, web developers, ai developers, ai development, web development

Id: GvQC5BHBkoM

Length: 11min 25sec (685 seconds)

Published: Sun Apr 16 2023