In episode 609, join Rob Walling for a solo adventure as he answers a handful of listener questions ranging from when it makes sense to have multiple LLCs and hiring task-level vs. project-level thinkers to planning for large projects. He also shares his thought process behind ways you can build a complex mobile app prototype in a capital efficient manner.
Topics we cover:
[1:56] Is it worth it to create multiple LLCs?
[6:10] Do you have any tips for how to find the time to work on future improvements when it feels like you don’t have time to do anything but fix bugs and answer support tickets?
[13:01] Do you have any advice around how to build a complex mobile app MVP in a capital efficient manner?
[20:30] Should internal company, marketing and transactional emails be on the same domain?
[22:27] How do you plan for a large project?
Links from the Show:
- Episode 551 I Task-level vs. Project-level Thinkers, No such Thing as an Autopilot Business, and More
- MicroConf Connect
- Episode 505 I 42 Side Projects and the #NoCode Movement
- Github Issues
- Episode 311 I What’s It’s Like Selling a $128k Side Project
If you have questions about starting or scaling a software business that you’d like for us to cover, please submit your question for an upcoming episode. We’d love to hear from you.
Rob: Welcome back. It’s Startups For the Rest of Us. I’m Rob Walling. Thanks so much for joining me this week. If you haven’t checked us out on Twitter, @startupspod, you get to see every week, a little 60th-92nd snippet of the episodes and their video snippets.
You’ll get to see my cool background with my Millennium Falcon kind of blueprint-ish thing, my Beatles gold record up behind me and of course, The Startups For the Rest of Us episode one album cover, What is a Micropreneur? Thanks to producer Xander for having that LP pressed for our first episode.
This week, I’m diving into listener questions, as always, video and audio questions that go to the top of the stack. You can ask questions by emailing questions at startupsfortherestofus.com or head into the website and click on Ask a Question. First question is from Josh Duffy, a longtime listener. He is asking about whether it’s worth having multiple LLCs.
Josh: Hey, Rob. My name is Josh. I’m the founder and CEO of a SaaS product that I’ve been working on since 2013. We’re currently doing 25,000 MRR and it’s under an LLC. I also have one other super small SaaS product that only does about 1000 ARR. It’s an early side project back in the day that still earned some revenue.
My question is about accounting and bookkeeping. I know you recommend different SaaS projects to have different accounts and everything set up so it’s super clean, so you could potentially sell one of your projects later. I recently spun off a module of my larger SaaS project last year into its own standalone SaaS.
It’s starting to take off. We’ve got five customers so far. I’m curious, just with all the effort involved, if you’d recommend making this transition at 1000, 5000, 10,000 MRR, or maybe once you have some product/market fit and when it lines up with a fiscal year.
A follow up question, would you recommend having separate LLCs? I’m a solo founder, so separate LLCs that are just owned by one holding company for tax simplicity. I’d love to hear your thoughts. Thanks for everything you do. I love listening to the show. Hope you have a good one. Thanks.
Rob: Thanks for the question, Josh. That’s a good one. I should start by saying I’m not a lawyer, not legal advice—all the usual caveats. I will say if I was in your shoes and I only had one SaaS app, so I did not have the 25,000 MRR app, but I just had one doing 1000 ARR, I personally don’t even think I would have an LLC.
In California, the fee for an LLC is $800 a year and other states vary. But just the headache of having to set up the legal structure and maintain it, personally, it wouldn’t be worth it at that point. I would just let it flow in the US. It flows to your Schedule C, I believe it is, on your taxes, so that revenue just almost comes in like 1099-type revenue.
Given that you have a business that is already under an LLC on its own, I would consider just having this side business just go to the Schedule C. Obviously, you’d want a separate bank account for it and I’m assuming a separate Stripe account. The cost, the headache, the hours of filling out LLC filings, and all this stuff—I act like it’s perhaps more than it is. I’ve had several LLCs running at once, and it winds up being a pretty big headache.
Personally, unless there was a compelling reason or I felt like there was extra exposure, because LLCs are supposed to offer you this exposure or this firewall between personal and business stuff such that if the business gets sold, they can’t pierce it. Single member LLCs, I’ve heard they often get pierced and in certain states, they just are viewed as it’s a personal thing. It’s a shield for shield’s sake, so they pierce it pretty easily.
I don’t know. I would either just have it on my schedule C and own it personally. I guess you could attach it under the other LLC, which is fine. I guess I don’t see much reason to do that if you don’t need to, because it does muddy the waters if you ever want to sell that 25,000 MRR app.
It’s all clean right now. Adding another product in there, if it’s not affiliated with it or you don’t have to sell them both at once is all doable. It’s not that big of a deal. But personally, I’d probably just have it as a side thing, much like I owned half a dozen websites back in the early 2000s.
They were throwing off hundreds or low thousands of dollars a month. At the time, I didn’t have an LLC. I had a consulting LLC that I was using. Even that I did consulting work for four or five years before I started the LLC, and I was doing six figures. It was just going to me personally.
It’s great. If you can get an LLC in place and get all that stuff in place, it’s fine. I do think some people will kind of pre-optimize some of these things, where if the business never does anything, then you have to shut down the LLC, and that’s even more paperwork and time that you have to spend doing it. Thanks for the question, Josh. I hope that was helpful.
Our next question is a video question from Ruth Maine.
Ruth: Hi, Rob. My name is Ruth. I’m actually calling in with a question for my husband as even a little bit of a surprise for him. I don’t know if he’ll end up on the show or not, but he runs his own business, a software that helps run livestock shows. His name is Josh. He’s been listening for a long time. He got me hooked, even though I’m not a software person at all.
He’s just really in the grind right now. He’s a few years in. The business is going really well, but he’s just sort of constantly inundated with little fixes and support issues, even though he has a few people helping him part-time. That is just a constant stress that never allows him to have the freedom at the time to work on improvements and updates that would alleviate some of those problems. It feels like he’s in a cycle of just constantly trying to keep up and keep his head above water versus being the head.
If you just had any tips or encouragement for how to make the time to make those needed updates when it feels like you don’t have time. I know you’ve talked about this a lot, so it’s not really a new question. Just looking for a way for him to have that time and to encourage him in that direction. Again, his name is Josh. He runs an app for livestock shifts. Thanks.
Rob: I love this question. Thanks, Ruth, for sending it in. Hi, Josh. I hope this is a nice surprise for you. What a nice gesture for Ruth to send that in. I love it, Ruth. You said he’s got you hooked, even though you’re not a software person. That’s the cool part. Startups For the Rest of Us can be just about entrepreneurship for a lot of people.
I know many non-software founders who’ve never planned to launch software companies who can apply the lessons that we cover on this show to their business. Yeah, this is tough. Honestly, I feel for Josh. I think the idea here that I have is, if he already has some folks helping him part-time, are they task-level, project-level, or owner-level thinkers? Because back in the day, I had eight or nine task level thinkers.
It was great. They were inexpensive. I was doing the four-hour work week thing. The problem was I was the only one that was thinking about projects, and certainly the only one thinking at an owner level. Anything that wasn’t within this really well-defined process bubbled up to me.
That got really old, and it wasn’t fun. My four-hour workweek, which was actually 8-12 hours a week at the time, was filled with a bunch of crap that I didn’t want to do. It wasn’t interesting work. It was answering questions that frankly, a project-level thinker could have answered.
Eventually, I had the budget to then hire someone who was more of a project-level thinker who could manage and deal with a lot of the task-level thinkers. I’m wondering if that’s perhaps an avenue that Josh could go down. I think a lot of us make the mistake of hiring too many junior people, because they’re less expensive, and you meet a person who has this great attitude, and maybe they’re your friend or maybe there’s someone you get along with, and you’re like, well, I can teach them to do this.
You’re right, you can. The problem is it slows you down. Then you essentially become more than just their supervisor, their boss. You become almost a mentor, and they turn to you for a lot of things that a senior person may not do. I wonder if there are these bug fixes and support issues that are coming to you. Is there a way to hire someone who is more of a mid-level or a senior developer who can handle these things?
Really, there are two ways that I’ve heard about it. One is the way that I structured it at Drip, which was that we had a junior developer. They were assigned all the customer-facing stuff. They were level two support. Level one, tier one support was our support person answering email.
If there was a technical issue, they couldn’t troubleshoot, and then they would escalate it to this junior developer who would then dig into the code, figure out how to fix it. If they needed to rely on a senior dev to get input, then they would. But if not, they would push that pull request, push it for a review, and then we push it and the bug will get fixed without a senior dev ever having to get involved. That’s how I’m thinking about Josh being the senior dev in this case, where he can consult or he can offer advice, but really, someone who is more junior might be driving that fix.
The other way that I’ve heard support and bug fixes handled by dev teams is that it rotates. Every week or every two weeks, one developer is basically assigned all the tickets that are coming in. The support person or team knows who is on call, in essence, and those are funneled to that person. It’s good practice to continue to be in the code base and answering support tickets.
It’s not something that a senior developer wants to do 40 hours a week. They’re there to write code and build things, so there’s this balance. My gut is that Josh, you’re hanging on to too much stuff. I know you’ve heard me say it, but you have to figure out how to not just delegate tasks, but actually start to delegate ownership, and delegate project-level thinking and initiative.
Whether that means not having a few people and just consolidating to one person who’s helping you or that means rotating these responsibilities through your team to where support tickets don’t always go to you, you can’t just be the frontline and take the bullets all the time. You can grind it out, and you know how to do it, but it’s going to lead you to burnout. It makes it hard to lead a normal life. It makes it hard to relax in the evening when you’re hanging out with your friends or when you go on vacation with your family. You’re constantly thinking about your business because it relies so much on you.
I’m guessing you’re in a relatively early stage. I don’t know the stage of your business. I don’t want to act like you can just hire five people and hand it off to them. I realized that’s not a realistic approach for so many bootstrappers. It’s the approach that I had to take. I had to be the backstop.
Over the years, I learned that the more I was able to delegate, the more advanced project and owner-level thinkers I was able to hire. The more senior people, the better off I wound up doing. Thanks again, both Josh and Ruth. I love having you too as listeners. It’s a good question. I hope that was helpful.
This week’s sponsor is Kelsus. Kelsus provides engineering teams for startup success. They stick with their clients for the long-term. Kelsus has worked with clients through nine acquisitions. Every time, their work has passed due diligence and security audits by big audit firms and public companies.
Working with Kelsus starts with a half hour walkthrough call where you tell them about your startup. After that, they usually begin a three-week fixed bid discovery project. Go to kelsus.com/startup to schedule your walkthrough call.
Matt: Hey, Rob. This is Matt Lasker. Thank you so much for letting me ask you a question. Really, I want to say I appreciate everything you do for founders like me out there trying to help us find our way through this process.
We are really wanting to know or get some advice about the MVP process development, in particular. We are trying to build an app that helps coaches, help their players, engage with their playbook. Right now these coaching apps are nice and beautiful, but they’re really made for the coaches. There’s really little engagement from the player’s side. We want to create a game, a mobile app that players can play, but it’s based on their coach’s playbook, basically.
We’ve talked to a lot of developers. We keep getting the same amount of cost right around $80,000-$100,000, which is not realistic for us to make our MVP. We are definitely of the mind that we want to make this MVP with a few core items, so we can get it out in front of players and coaches and let them tell us how to make it better. $80,000 is just not really realistic for us on that.
We did find one company that specializes in rapid prototyping that can do it for even less than half the cost. It’s great, but they are very adamant that this is not a long-term product that we can sell. It would take some additional development or just scrapping it, and then finding money to build the whole new real application afterwards.
I’m just having a hard time balancing that in my head—$40,000 for a prototype, we want to prove it. It seems like a lot, especially if you layer on the fact that we probably won’t see any value after that. Obviously, proving the concept is invaluable. I get that. I’m having a hard time quantifying that, so I’d love your opinion.
Rob: Thanks for the question, Matt. Yeah, this one’s really interesting, especially a tough question, because it’s a lot of money to put at risk. Given how startups are so unpredictable, and that the odds are that they probably won’t work out, you’re going to be selling to schools, I’m guessing. I can’t imagine.
Maybe the coaches themselves or I don’t know if the school is going to have to approve it, but it’s tough to get money out of schools often. I guess I don’t want to go down the road of thinking through the business case for this. I really do want to just answer your question about getting the MVP out.
It pains me to think of you spending $40,000 or $80,000 of your own money to prove an MVP. I think that’s what you’re getting at as you have that same feeling. Typically, in this case, what I see is that either the person, the founder, or you, learns how to code well enough to build something that people can use.
I would say I’ll build prototypes and show them how it’s going to work, but I get it. It’s coaches and kids or coaches and players. I don’t know if you’re talking major leagues, college, or whatever it is, but they’re going to have to see it in this case.
I’m wondering, as a founder, a lot of folks are able to put these out because they do learn to code just well enough or they bring on a co-founder who can build it, which is a whole other podcast topic to go down. It’s like how you would find that founder and how do you know they’re good.
I would say that there are folks in MicroConf Connect. There are more than 3000 mostly bootstrap founders. Some folks in there, there are a lot of developers. There are probably 80%+ developers, and some folks are looking to come on with a non technical co-founder and team up. I don’t know if it’s the hiring channel.
Honestly, if there’s a co-founder channel, I’m not in it at this minute, but that’s an interesting thought. You have to bring something too, which I think you’re already doing. You have to bring some validation and the leads, and that you’re going to sell, and all this stuff in order to ask a developer to spend X amount of months, $80,000 worth of months to build up the app.
The other thing I was thinking about is, there’s a bunch of no-code app builders. I’m not an expert on these. While I wish I could recommend one to you, I went to Google and typed in no-code iOS app builder. Of course, there are these lists of the top 22 iOS app builders. Each of these is going to have a limited feature set. It can do one, two, or three things, and that’s it.
It’s not going to be completely custom. But I would ask myself, is there a way where I could build enough of an MVP with one of these app builders to use that as the MVP, or is there a way I could hire someone on Upwork or find them in MicroConf Connect, who is a no-code builder, and pay them for a few hours of of consulting to say, is this even possible? What could we build with no-code, given your knowledge of these tools?
I had Helen Ryles on this podcast. It’s probably 12, 18 months ago. She’s a perfect example of someone who knows no-code really well. Someone like her or someone you find in the no-code space, it’s a great community in general, I think could be beneficial to give you an idea of if you spend a few $100 to get a yes or no, because then that idea may be harebrained or it may be the solution to all your problems, so to speak.
The only other option I can think of is, is there a way that you don’t build it as an app, but that you build it as a mobile responsive web app. Then you don’t have to go through the App Store. It’s just a URL that the coaches would hit to log in and do things, it is a URL that the players would hit to see the playbooks or whatever? This may be reaching.
I’m really just spitballing here. The reason I throw that out is because I think that building a mobile responsive web app is going to be easier, and you’re going to get more functionality than if you try to build an actual iOS, and God forbid, also an Android app if you need something to be compatible with both. I know a lot of the app builders do both. I just know that once you get into the mobile app world, they are more complex and more challenging. I think there are fewer people with that expertise than there are who could no-code build a web app.
When I hear $80,000 to $100,000 to build a working prototype, that sounds insane to me, like so expensive. I think, what if it was a web app? Could it be done for a 10th or a quarter of the cost? In my experience, probably finding a good freelancer through recommendation. Again, I keep saying MicroConf Connect, because that’s where there are 3000 SaaS founders hanging out who were bootstrap and mostly bootstrap, who listen to this podcast, and who are helping each other out with this kind of stuff.
Whether you found a freelancer there or you found a recommendation to one, that’s one way to go. You could also go to Upwork. You can go to Indie Hackers, go to the Dynamite Circle. There are a bunch of communities where folks are going to be able to help guide you. I’m glad you wrote in with this, because I’m sure there are other people out there with this exact question.
I think my reaction is, oh, my gosh, these numbers just sound expensive. Of course, hiring a full service agency that’s going to deliver everything, yeah, I get it. I ran a micro-agency back in the day, so I know what the margins aren’t and how that works. But paying this much for an MVP, unless it’s really complex, feels like the funded approach to doing things. It’s not the bootstrap, mostly bootstrap capital efficient way.
Hopefully, that’s why you’re asking me, because I’m trying to think of how I would have done this years ago when I didn’t have that kind of money to drop on a prototype. There’s a lot to think about here, Matt, but I appreciate your question. I’m glad you wrote in. I hope some of those ideas were helpful.
My next question is from a longtime listener named Scott. He’s asking about transactional and marketing emails, whether they should be on the same domain. He says, “We’re a startup. We’re getting ready to start sending more marketing emails very soon. Should we be using the same domain name or dot-com for corporate emails—that’s your internal emails you would use in Gmail, Google Apps, Suite, Outlook, whatever you’re using, marketing emails—you all know what those are, Drip, MailChimp, et cetera, transactional emails—these are emails that are sent if you’re a SaaS app, you’re sending billing receipts, or you’re sending onboarding emails, or you’re sending notification, hey, someone just signed up for this or that.”
“The question is, should we be using the same domain name or dot-com for all three of these? If not, what is the best strategy? We’re already using the dot-com for corporate emails. Should we create emails as a subdomain for transactional marketing or both? I thought maybe some of your Drip experience might come into play here.”
Of those three, the biggest risk is marketing emails. Honestly, usually, I would send all of them from the same domain. I’m just not that worried about it. The place where I would tend to break them into a separate domain is if you’re sending a cold email, because that is where you’re going to get the spam complaints, and that can impact your sending strategy.
If you don’t maintain and might be mindful of the health of your marketing list, it can as well. The most dangerous one is marketing. If you want to separate that out, you can. But I’ll admit, it’s not something we did with Drip. It’s not something we do with MicroConf. It’s not something we do with TinySeed.
To be honest, corporate and transactional emails winding up in spam is pretty low, because they’re so targeted. It’s an it-depends, risk tolerance, blah, blah, blah. But most companies that I see have their corporate marketing and transactional emails all on the same domain, and then they start thinking about it when they’re sending cold emails. They start thinking about breaking it apart. Thanks for that question, Scott. Hope that was helpful.
My final question of the day comes from Philippe, who’s asking about planning for a very large project. He says, “Hey, Rob. When starting up a project, do you have any tools you like for organizing the steps of the code? I’ve always just cranked out hours and hours of code, but I’m wondering if there are tools that you like to perhaps tying to Gmail or just how to plan for a project started from scratch? Do you lay out in a calendar, which features need to be built by which date? Do you have something that allows the UX team to run parallel to the dev team? I tried Trello, but didn’t really like their UX. The ideal solution, I think, would be some sort of to-do list that ties into a Google Calendar. Thanks for your help.” Interesting question.
I have never had anything that tied into a calendar. Back in the day, I used to use an Excel spreadsheet, and then moved to Google Sheets, where I would have each feature, and then my estimate, and then how many hours I put into it, and how many hours I thought were remaining.
There was a count date feature. It would add up all the hours. It was a workday, I think it was. It would add up all the hours and tell me what day based on these estimates if they were accurate when it would be finished. It wasn’t individual. I didn’t calculate it for each individual feature, I guess you could. That’s a pretty simple way to do it.
In fact, Joel Spolsky has an article on his spreadsheet. I just took it and edited it. I loved that when I was consulting, because it would give a pretty good idea. I would do my estimates, and then I would submit them to the client. Hey, this is going to cost $40,000, and here’s why because here’s the hours we’re throwing at it. Then I could see if we were on track ahead or behind. It was a very simple way to do it. I really enjoyed it.
These days, there are other tools. Bottomline and GitHub Issues is one that is really good. In fact, it’s what we ultimately wound up using at Drip. We had an engineering team of 18, 20 people by the time we left. We had a UX team and we had all types of people working in tandem. GitHub Issues was what we rolled that on, so I think you should definitely look at that.
What I don’t remember is if there were calendars tied to it, because we worked in sprints. I forget if it’s two or three weeks. We didn’t say this feature was done on this day. It was kind of like once it was done, then it was QA’d, and then it went through a code review, and then if it was complex, we put it on staging. Otherwise, we push it to production.
There was this process that we had, but we didn’t try to pinpoint it down to exact days when exact features were going to be complete because we just didn’t need to. We pushed it to production as many times a day as we needed as features were complete. There was no reason to plan to that level of specificity.
Other tools people use include Jira from Atlassian. That’s a bit of an older tool. I know that a FogBugz back in the day, also an older tool, is what we had used before GitHub Issues. In fact, we actually used codetree.com, which is a tool Derrick built on the side while we were building Drip. He later sold that.
I interviewed him about that very process on this podcast years ago. He sold CodeTree, so there are new owners now. It’s basically built on top of GitHub Issues, and it adds some extra functionality. That’s an interesting play.
I’ve heard some folks use Trello as well, and then Wrike is another one of those. Boy, there’s Asana and Basecamp too. Some people use them. Basically, I could probably rattle off 100 different tools that are focused on this niche, because there’s not much of a niche.
It’s a very horizontal play, there are a lot of software developers in the world, there are a lot of software projects, and there are a lot of tools. I don’t want to overwhelm you, but there are many, many tools that are built almost exactly for this use case that you’re describing. I’ve tossed out a few of them here today. I hope that was helpful. Thanks for the question.
That wraps up our episode for today. Thanks so much for joining me this week and every week. This is Rob Walling signing off from episode 609.