4 Critical Lessons While Building My ASP NET Core SaaS

hi I'm Nick centino and I'm a principal software engineering manager at Microsoft in this video I wanted to talk to you about lessons I've learned from trying to build my SAS company called brand G these lessons are based on experiences that I've had either at startups or from trying to do other things in the past for myself that have failed I think that it's really cool to talk about this kind of stuff because even if you have failures along the way there's so much that you can learn the other reason I wanted to talk about this is because I'm practicing what I preach which is building software and as an engineering manager these days I am not writing code at work but I still love to write code and I think that it's very important that I do so so that I can stay technical now if all of that sounds interesting just a reminder to subscribe to the channel and check out that pin comment for my courses on dome train before I dive into the four lessons that I want to share with you I just want to give you a little bit of background about brand ghost and why I'm building it in my case this is solving a problem that I currently have I've been trying to create more and more content on social media and brand ghost is my solution for that I've made video and I've written articles and stuff in the past on this kind of thing but I think that if you're trying to learn new technology and you want to practice building things that if you have something that is going to be very interesting to you that it's going to make it very easy it's not going to seem like work and that means that when you're encountering challenges and things like that it's going to feel exciting to go solve those problems if you've ever felt like it's really hard to learn new things and you're forcing yourself to do it it's probably because you're battling against this kind of thing right but when you have something that you're excited about it feels much easier to to go learn brand ghost for me has plenty of challenges but they're all inspiring they're all exciting and I'm very motivated to go tackle those challenges now the first thing that I want to talk about in terms of lessons is creating time and essentially we all have the same amount of time and we cannot create time out of nothing and I wanted to talk about this one first because I think that if you're not in a state where you're trying to build your own company you're trying to build your own software from scratch and you're just trying to think about how you might go practice building projects on the side right maybe you're a brand new developer and you keep hearing this advice that you should go build things the reality is yes we can't just make more time out of nothing so if you're feeling strapped for time and you're going I don't have time to go build these projects I'm already you know uh you could be working a full-time job you could be in school you could be doing both you could have a family there's a million things that are going to be occupying your time of course it was the same situation for me and in my case it's a full-time job it's my wife it's our animals I'm trying to make sure that I'm creating content online I'm trying to create courses online and then I went okay like I'm running out of time to be able to do any of these other things like I basically could not create more time when I wanted to start coding more things I was at my limits I basically had to give something up so for me it was a matter of trying to prioritize and that's what I wanted to talk about for this lesson right is trying to figure out at this point in your life in your current stage what things do you value the most because you only have so much time to dedicate towards things it's okay if these things change over time right I've heard people describe this as seasonal so it might be totally okay to prioritize something more highly than you usually would because it is a seasonal thing because it is going to be effective for you and the most beneficial thing right now for example if you are going through school right now right if you have a heavy chorus load you're studying for your exams and things like that and you're saying well I want to make sure that I can go build some side projects and carve out more time for that you might have to make a hard decision and say look like it probably isn't in my best interest to reduce my time studying reduce my time on my school load you probably should be investing the time into that for right now so if you want to go building side projects is there something else that you can carve time out of I don't recommend removing time from your friends and family I think that's very important but I think that you're going to have to look at your other Hobbies extracurricular activities and see where you can start to get some time back if you prioritize building things more than that I wanted to bring this up because it's something that we all encounter like I said we all have the same number of hours in a day but I think it comes down to priorities and you do have to be honest with yourself if you are saying I want to go spend time building things in my case I want to start building brand ghosts and take it more seriously make it a real thing I need to get the time from somewhere it's not coming from my work right I I need to be able to maintain my job my goal is not to just like I don't know have a huge valuation on something and then get rid of it brand ghost is something I'm building because it's exciting for me and it's helpful for me and if I can help other people with it that's awesome it's not coming from my job I need to make sure that I'm spending time with my wife right that's important as well for me I ended up having to remove some amount of content creation blog writing was one of the most timeconsuming parts of my content creation I put that on hold it's been on hold months now almost six or more months at this point that went away and I actually reduced my time going to the gym I was someone that would go to the gym 6 to 7even days a week and I said okay at this point in my life I've reached a lot of the goals that I had at the gym I'm not going to stop entirely but I will reduce that time and that way I have more time for this the next thing that I want to talk about is user feedback and I think that this is a super important topic and not a lot of software engineers get exposure to this kind of thing in their careers and that could look wildly different for some people you might work at a place where you know in the very beginning you were kind of getting user feedback and working with customers especially if you are a solo Dev and you have to be responsible for everything this is of course going to ring true to you but some people will go through their careers and they might be in a position where they have a product manager product owner and they're acting as the user proxy and they're kind of doing this job for you so I wanted to talk a little bit about this so that you have some understanding in terms of how I navigate this kind of thing thing with a little bit of experience from being at startups and from trying to do my own stuff before first of all it's really important that you are listening to users like user feedback is absolutely critical because you might have a great idea so you think but if it's not resonating with your users and you're not listening to what their challenges are then it's going to be really hard to make sure that you're delivering value to them we've even been through this with brand ghost right so for me I saw value in this I wanted to start creating it for myself and when I started working with my part Partners on this they literally had to ask like does anyone else have this problem right they want to believe me but they need to make sure that we can hear from other people the user feedback like yes I also have this problem yes these are the top priorities for me here are these other challenges I have we need to hear from users if you're not doing that you may just be wasting time hoping that you're going to create something put all this effort into and just hope that people want it but you can be proactive about it and try listening to the feedback that's coming in and feedback can come in other ways too right so in terms of people using your software so now they're trying it out what are they requesting are there bugs right are you going to listen to when people are filing bugs making sure that you can fix them promptly show them that you really care we've already had feedback for our platform not that there's any bugs ever in the software that I write but uh we've had feedback where people have said hey it was really awesome to see just how fast the team responds and to me that means a lot we're very proud about what we make and we want to make sure that people have a good experience so I think it's critical that you're listening to users but there is one catch here and that catch is if you're following user feedback blindly so this might sound kind of funny based on everything I just said but if you have users giving you feedback and they're doing things like giving you Solutions right they're giving you Solutions and you say that makes sense good solution I'm going to go build it if you keep repeating that for the users that you have what ends up happening is that you create a very disjoint product or service and you might get lucky and that doesn't happen but if you think about it if you have individual people telling you solutions for things on the outside of your business and the product that you're building they're not going to have all the perspective that you should have in your product or service offering I think it's really important and it's actually great if someone's giving you a solution right it's great that they're doing that but I do think it's really important that you go back and ask them what their goals are and what challenges they're having that's important for you to understand and they've given you a solution and it's a solution it doesn't mean that it's the best solution and you need to go back to the drawing board and say based on what I'm hearing the goals that my customers have the biggest challenges they're having is this a viable solution or can and should I come up with something else this way you think about things holistically and you're not operating with blinders on and just kind of Super Hyper focused on individual things one at a time this will really help you create a cohesive piece of product the next lesson I want to talk about is testing and if you're watching this YouTube video and you've seen my other YouTube videos where I talk about testing I think software testing is incredibly important it's one of the things that I love to talk about I know it's kind of weird because not Everyone likes testing and probably many people think it's boring but I've seen the benefits of it I've seen us transform our teams that I've worked in to make sure that we have good testing that we feel confident in our code so I do love talking about testing because I think it's critical however I don't think that it's critical all of the time I've made live streams about this I've written newsletter articles about this and I've vlogged about it as well and I'm going to say it in this video too because I think that it's really important I think software testing is very important in your development but I don't think that every single thing you do at every stage you're operating at requires tests in our example with brand ghost we were doing so much iteration so fast in order for us to make sure we had a lot of test coverage it would be slowing us down tremendously and I realize that that might sound kind of scary you might be saying Nick how could you ever put code up and run it on the internet if you don't have it tested and you're not confident but that's the difference I am confident in what I'm building so the tradeoff in order for me to go write the test and have the testing infrastructure on this code that I might be blowing away completely the next day is not really there what we were finding as we were building stuff is that we can move very fast at the stage we were at without the tests and that's because with no users we can keep trying things getting it to run and going okay seems good you know let's keep going oh let's tear that down thankfully we didn't go write tons of tests on it and waste more time and keep experimenting as users are coming on board we can do this less and less now for me I'm writing a lot of the backend in asp.net core there are experimental features that only I can see because I'm controlling the entire back end so I will set some of these up for myself and I would experiment with them and the way that I have that working is that it's impossible to interfere with other people so I have a high degree of confidence that I'm only going to potentially mess up myself in the content that I'm posting but that starts to not be the case and as things get more complicated and we have more users on my confidence level starts dropping very fast and for us we reach a point and we have reached this point where we started saying look it's not okay to not test anymore we literally reached this point where we said we do not have confidence we need to slow down to speed up so slow down so we can get the testing infrastructure in place write those tests so that we are able to get back to having that agility we reached the point where we felt the pain of not having tests and we said aha okay here it is let's make sure we're writing those now and that way we have confidence and we can keep iterating fast and what ends up happening is that we notice that there are core parts of the code that are not changing anymore right they're stabilizing so we might still have experimental features and things that are kind of On The Fringe of the application and there still might be big parts of the application that we do rewrite but there are these core parts of the application that are really forming up so for example in our platform We Have a scheduling system and we have authentication and we have these repository patterns and our database schema like some of these things at this point haven't changed or they've had small iterations on them for like 6 months now so it's probably important for me to make sure that stuff is Rock Solid it's a critical part of what we're doing I want to make sure that if I do need to experiment or try something that I have the tools to do it locally and that I can try it test it before I push it I wanted to talk about this because I think it's important to keep moving quickly but you will reach a point where you start saying look I don't have confidence and if we want to keep moving quickly we need to do something about that for us it's adding different types of tests over the key parts of our business logic finally the last thing I want to talk about and no I did not coin this or invent it but I am leveraging this Insight from why combinator and it's do things that don't scale and what we mean by do things that don't scale is kind of interesting right because if you think about software engineers in particular we have a bad habit of like basically over architecting and trying to make things that scale you know to the moon and back because we're so used to building software systems that we want to make sure will scale but there's a difference here when you are writing software systems to be scalable it's at a point in time for us where we have not scaled yet you're starting to make a tradeoff and you've probably heard people talk about this with microservices versus monoliths as one example right if you jump into microservices right away someone will say well maybe that's a bad idea because if you have no users and you're immediately introducing a lot of complexity with microservices you might find that it's very difficult to move forward at a fast pace that's because you have not scaled yet and of course it's really difficult to reach a ton of scale if you're not scalable so there is this sort of Catch 22 this balance that you have to do but for us we do things that don't scale because we have not scaled yet what that looks like for us is say for example onboarding a user to our platform how would that look in the very scalable way we would have you know a completely automated workflow it would do everything that the user needs it could import content for them to post it's a social media integration application so we could do all of that for them right and we could spend all of the time trying to make that perfect but for us the thing that doesn't scale is that I can go message someone and I can say hey I know you're on boarding can I help you get your content imported I can literally go to your social media and if you let me know what kind of content you want from your social media I'll go grab it for you I'll go do all the work I'll go literally put it directly into the database for you that does not scale but what's really cool about that is that I can start to build relationships with the people using the product they can feel comfortable talking to me about their challenges either in their content creation or using our product so I'm nurturing this relationship and learning from them and giving them a lot of value at the same time they're giving us a ton of value because we're getting to learn from them now at some point this does stop scaling but I also think at that point we're in a really good spot because we are starting to scale there will be a point in time we're being able to do this kind of thing like handholding people to make sure that they can onboard effectively is unscalable but that's okay if we start paying attention to when that starts to become unscalable and we're making sure that we are paying attention and trying to build the scalability into our systems we should be in a good spot I thought this was really important to talk about because it's a living real example of these situations where we talk about things like premature optimization and that could look so many different ways in software engineering I already mentioned like the microservices thing you could be say writing code and going hey like I need to make sure that I can get the the latency down to like you know 1 millisecond or I need to make sure I can optimize for throughput of like 10 million requests per second but do you do you really need to be doing that or are you just doing it because it's interesting right for us we need to make sure that we can focus on just enough and that we can put our energy potentially into these other things that aren't really scalable because they'll offer so much more value for us right now those are the four lessons of I wanted to talk about from building brand ghost so far but we're still early in the journey and I'm sure there's going to be many more lessons to come so I hope you thought that was interesting and I'll see you next time