How To Build Solid Multi-tenant Account Systems For SaaS

Show notes:
Links:
Cameo
Sarah Cooper
StiumulusReflex Video
Jumpstart
Whirly Board

Full Transcript:
Ben:
So we had a bit of an interesting COVID related thing in our household, so we have this grocery store that we love near us, it's called Haggen, it's a Northwest brand. So a lot of our listeners won't be familiar with it, but we love this place, it's a great little grocery store. My wife, who typically does the grocery shopping, hasn't been there in forever, because like, "I can just get stuff from Amazon Fresh." So we've been doing that, but finally, Amazon Fresh started running out of some of the things that we really want. So I think today was the first time in weeks, many, many weeks, that we've actually ventured out to the grocery store.

Josh:
Exciting.

Starr:
You went inside the grocery store?

Ben:
Inside the grocery store, yeah.

Starr:
Oh, my gosh.

Ben:
Just like the good old days.

Starr:
So you just love taking life in your own hands like that.

Josh:
I never took you for an adventurer.

Starr:
We're still doing the order online and then pick up outside the store thing.

Ben:
Yeah? I went and did a pick up for some teriyaki the other night, and there were actually people dining inside. It's like, "What? That's a thing?"

Starr:
I can't believe that. Florida just opened 100%, so I don't even know. I don't even know what's happening. So I did a little research over the weekend, like normally we record this podcast on Fridays, but we moved it to Monday, because I had a thing. So I had some time, I did a little research over the weekend, and I'm pretty sure that if we are willing to move the legal entity of Honeybadger Industries Incorporated, we can all move to Canada.

Ben:
Oh, yeah. I read something about that.

Starr:
Yeah, yeah. Get in on some of that sanity.

Josh:
Does Stripe have, like Stripe Atlas for moving your business out of the country?

Ben:
Great idea.

Josh:
Because it's a freebie.

Starr:
There you go.

Ben:
We should relocate the headquarters to Vernon, BC, then we can hang out with Justin.

Starr:
Oh, of course.

Josh:
There you go.

Starr:
Another place I know that does this is Scotland. I'm pretty sure that actually if you move a whole company, you can go anywhere you want.

Josh:
We've just got to get everyone, everyone has to be on board.

Starr:
Yeah, just like, "Yes, bring all your ..." Hire local people.

Ben:
Scotland versus Canada, that's a tossup, that's a hard one.

Starr:
Canada's a lot closer, it would be significantly less disruptive. Just mosey on over to Victoria or Vancouver.

Ben:
It would be kind of hard to drive that U-Haul over to Scotland.

Starr:
Yeah, that's true. But you get to hang out with Nessie, and that's always a bonus.

Ben:
Yeah, my kids are like, "Yeah, so when are we moving?" I'm like, "Well, first they have to let us in, then we can talk about the practicality of moving to Canada."

Josh:
Is that the bigger hurdle here?

Starr:
There you go, yeah. You can be like, "I've got a business. I have skills." What are you doing? Why are they going to let you in? You've got to prove your own worth.

Ben:
I did mention that, I'm like, "By the way, I'm the only person in this family that has a passport, so I can go, but what are you going to do?" Speaking of traveling though, we talked last time about the conference that I was going to, the Business of Software Conference, and that happened last week. It was the one that originally going to be in Boston, because that's where they hold it every year. I've got to say, while I loved the conference, it was great, even online, I did miss going to Boston. I've realized that I actually enjoy putting myself on a plane for six hours and having that trip.

Josh:
Yeah, it's nice to get out.

Ben:
It is. I miss traveling, I miss leaving.

Josh:
Can you imagine what the next time that we do go to a conference, how great that's going to be? Hopefully, hopefully it's good. I think for us, we probably will wait until we're sure it's not going to be a train wreck.

Starr:
I'm just going to bring my moon suit with my ... It's just a completely contained bubble and I just walk around inside.

Ben:
Yeah, I'm surprised that industry hasn't taken off in the past few months. Personal suits.

Starr:
Are those big transparent plastic balls that you just inflate with air and then you roll around?

Josh:
That would just be fun too.

Starr:
I haven't seen any of those.

Josh:
That's not a hard sell.

Starr:
I did see a guy with a beekeeper's mask on, like a beekeeper's helmet on. Beekeeper's helmets look weird, they look fedora-y, like milady. They look kind of milady-ish. It's this weird milady hat and then screen stuff coming down. I don't think that works, I don't think that works like you think it does, guy. The coronavirus is much smaller than a bee.

Josh:
He was wearing the screen too?

Starr:
Yeah, yeah. No, it was clearly a PPE measure just walking down the street.

Ben:
Those bees that carry that virus, they can't get through.

Josh:
That's true.

Ben:
So the big bubble thing though, Josh, reminded me of your whirly board or whatever it's called. How is that treating you?

Josh:
I'm on it right now, I'm standing on it right now.

Starr:
You're so level, I wouldn't even imagine.

Josh:
I was debating actually taking a minute to lower my desk so I can get off, just because, I don't know, the gain on my microphone, I've noticed since I got this Cloudlifter thing, it's a little more touchy and I don't want to be slamming on my desk, or I think every little movement's going to show up. But I like it, yeah. It's nice to have something to stand on that keeps you off balance.

Starr:
That's so un-intuitive.

Ben:
You look like you've mastered it, that's for sure.

Josh:
I'm getting there, yeah. As long as you just stand right in the middle and don't move around a whole lot, you're good.

Ben:
Nice.

Starr:
So when are we ... We're getting pretty close to launching Hook Relay, right?

Ben:
Yeah. Some people have found it on their own and started using it.

Starr:
Wait, what? Really?

Ben:
Yeah, yeah.

Starr:
We've got organic traffic?

Ben:
Yep.

Starr:
Is it officially launched yet though?

Ben:
It is not officially launched yet.

Starr:
That makes those people hackers, those are called hackers. We need to sue them.

Ben:
Maybe we'll just ask them questions instead, that's almost as bad as a lawsuit.

Josh:
Then build what they ask for.

Ben:
Yeah, it's close. Kevin just opened a PR for one of the last features, we have to write some documentation, but beyond that, it's ready. It's good. I'm excited.

Josh:
We even have an amazing welcome video.

Ben:
Yes. Josh knocked it out of the park on that one.

Starr:
I haven't seen it yet, I need to watch it.

Ben:
You should go sign for Hook Relay and check it out.

Josh:
You just have to sign up for Hook Relay.

Starr:
I haven't signed up, that's my problem. I just assume I'll get ushered in with VIP treatment.

Ben:
You know what we should do though? Josh, your video is fantastic, but I think what would be even better maybe is if we have Sarah Cooper do the video. Could you imagine? That would be pretty awesome.

Starr:
Who is Sarah Cooper? Was she the lady in Terminator?

Ben:
She's the one that does the videos with Trump's voice.

Starr:
Oh, no. That's yucky, that's gross. What?

Ben:
She's hilarious.

Josh:
It doesn't have to be Trump.

Ben:
That's true, it doesn't have to be Trump.

Josh:
She isn't Trump, to be clear. Is she on that, what's the website where you can get ...

Ben:
On Cameo?

Josh:
On Cameo, is that where she's coming from?

Ben:
No, no.

Josh:
Can we get her to do something? Okay.

Ben:
I don't know.

Josh:
You might, because Cameo apparently, a lot of celebrities are on there right now, which was interesting.

Ben:
Yeah, that Stimulus Reflex video, that just blew me away when I saw that.

Josh:
Yeah. I can't remember that guy's name off the top of my head now, his character in Silicon Valley, the billionaire.

Ben:
I'll tell you a secret, I'm going to lose all my street cred right now, but I've never watched the show so I didn't actually recognize the guy in the video. Everyone's like, "So cool." I'm like, "Who is he?"

Starr:
So explain, so take two steps back and explain this to me, because I have a vague idea what you're talking about.

Ben:
Go for it, Josh.

Josh:
Well, okay. So again, I'm blanking on the actor's name, or the character's name in Silicon Valley, but he's like this, he plays an over-the-top Silicon Valley founder billionaire dude, and the people that do Stimulus Reflex, the Rails plugin, got him to record a video about how great Stimulus Reflex is and how much better it is than React, because they're a competitor to React. So his line was, "A reflex is faster than a reaction." You just have to go watch the video, because his character is just like ... I don't know what you thought, having not seen the show, Ben. You were probably like, "Oh, who is this completely plausible guy from Silicon Valley talking about Stimulus Reflex?"

Ben:
Yeah. Even without the context of knowing about the show or who this actor was, I thought it was still funny. It's great, great video.

Josh:
Yeah.

Ben:
He's obviously a good actor to be able to pull off some ... I just think like, "What's that conversation like?" When you hire someone, like a voice actor that we hired for the podcast, and you give them lines like, "Here, do something with this." And they do. But not having actual experience with the field, I'm sure he's not a Rails, I'm guessing he's not a Rails' developer, so he probably isn't all that familiar with what Stimulus Reflex is. But still, to be able to take a script and to run with it and make it relevant, and then connect with the intended audience, that's an impressive talent right there.

Josh:
Yeah.

Starr:
It is, I guess acting is more than reading. Okay.

Josh:
Yeah, but apparently they got the video, he's on Cameo, so if you want him to record your video.

Starr:
Oh, he's on Cameo?

Josh:
Just go on Cameo.

Starr:
Is The Rock on Cameo? I want The Rock to do a Honeybadger video.

Josh:
I don't know.

Starr:
I saw The Rock was late for work, because his gate malfunctioned. He's got a gate in front of his massive house, I'm sure. So using his own hands, ripped it from the moorings, and got to work.

Josh:
Nice.

Starr:
So I want that kind of energy behind Honeybadger.

Josh:
That sounds like something I'd do, if I had a gate in front of my house. I don't, so that's why I've never done it, obviously.

Starr:
Josh, let's be frank, let's be frank, you work out, it's obvious, but you don't eat that much cod every day.

Josh:
I eat a lot of cod, but he's got me beat right now I think.

Starr:
The Rock is not on Cameo, I'm sorry.

Ben:
That's a real shame. But the video that Josh did is fantastic, so everyone should definitely sign up for Hook Relay and check it out.

Josh:
I actually might eat that much cod, just saying.

Starr:
You can get pets and stuff, they have little dogs.

Josh:
Really?

Starr:
I searched for Pee-wee Herman and there was a dog named Pee-wee Herman. Oh, my gosh. There's lots of wrestlers on here. There's Mick Foley, oh wow.

Josh:
Yeah, there's a lot of people on there.

Starr:
I'm sorry, I'm just going to ...

Josh:
Tommy Chong is on there, Tommy Chong would be a fun one.

Ben:
That would be. Sorry, I was going down the Cameo rabbit hole.

Starr:
Oh, my god. You can have Mick Foley do something for $75. This is wild. You can have the guy from Ghostbusters say something, you can have one of the Ghostbusters talk to you for like a couple-hundred dollars. Amazing. I just want to hire these people to just tell me positive things about life. It's like, "Go outside and look at ..."

Josh:
I bet that's a thing.

Starr:
They should, yeah. Like, "Go outside into the sunlight, look at a flower and describe it to me."

Ben:
But, Starr, how much should we pay you to make that kind of video for us?

Starr:
I'll do it for free, because that's just how I am. I just spread the joy. Oh, my god. Chumlee from Pawn Stars is on here.

Josh:
Yeah, not all of them, some of them are kind of pricey.

Starr:
Carole Baskin's on here? What? Carole Baskin, as featured on the Tiger King show, and she is at a higher price than Gilbert Gottfried or Mark McGrath. Okay, I'm going to stop looking at this, because this is really off topic. I'm sorry.

Josh:
It's a bookmark, for sure.

Starr:
I closed it, I closed the tab.

Josh:
But I know the question you really wanted to know is, is Randall on there? And unfortunately, not. Not yet, but maybe we'll get him anyway.

Ben:
It's a real shame.

Starr:
I don't recognize the existence of Randall. But now if we want some new podcast intros, we know that we can really ... If we want to splurge a little bit more, we can get some really top notch celebrities.

Josh:
The only thing is this is going to be the thing now, like everyone is going to have a celebrity introduction to everything.

Starr:
Yeah. These people's voices aren't that recognizable, so they'll just have to be like, "I'm so-and-so and you're listening to FounderQuest.

Ben:
But actually, I haven't been working on Hook Relay for the past few weeks, surprise, surprise.

Starr:
Yeah?

Ben:
I've been working almost entirely on accounts, yeah. So this long, long desired feature of being able to have a level above users that manage accounts is finally going to happen. It may not quite meet my self-imposed deadline of three days from now, but it is very close and I am pretty excited about it.

Starr:
That's amazing.

Ben:
Along the way, but now we do a lot of cleanup, and I think there will be some nice UI improvements. Nothing significant, but some little updates and a little bit of a polish and things that just work a little bit better than they do today. So I'm really excited to have this off my plate finally after wanting it for so long.

Josh:
I was thinking about this earlier today, when I was thinking about the podcast, and it might be good to explain how you should build your account system very briefly, in order to not end up in the position that we ended up, wanting to do this and it became a huge project, now that we have thousands of users.

Starr:
I was just thinking about that, yeah.

Josh:
You want to give that a go?

Starr:
We've got to make up for being so off topic, we've got to have a ...

Josh:
Yeah. This could be a really big tip, because if we had done things a little bit differently in the very beginning, it would have saved us all this work later on. The way we set up our app and account system, basically.

Ben:
Yeah. It's a perennial question that comes up in developer forums, like Stack Overflow and various other places where people hang out. Because developers, a lot of developers are building SaaS apps that have the concept of multi-tenant, and they have teams and they're trying to figure out, "Well, how does a user interact with a team and how do we do billing and how does all that set up?" There are tons of opinions about how to do that, and I'm not going to say that what we did before was most ideal, or that even what we're going to now is going to be the perfect solution.

Ben:
But I think what we're moving to is a lot better than what we did, so I guess I should describe what we did before and then what pain we felt and how we think it should be. So when we launched Honeybadger, we just had a user ... So everything's going to be in Rails' terms, since we're a Rails' shop, so I'm just going to put that apology out there right at the beginning. But we have a user model, so there's a user's table on our database, and that had a Stripe ID which is tied to a Stripe record, since we do all our billing with Stripe. When you created a user account, you created a subscription in Stripe to go along with that.

Ben:
We do offer a premium now, although we didn't when we launched, so we had this assumption that every user has a Stripe subscription. A lot of our users have free subscriptions, they're just collaborators with other users. But we created a user, we created a Stripe subscription for that user, and then everything associated with that user in our database. So we have a user owns, has many projects, has many teams, and that worked out really well at the beginning and was really good for getting people onboarded quickly, because we had a lot of freelancers who are our customers in the early days, and small agencies.

Ben:
But the problem comes when you start getting these bigger teams that have these billing responsibilities that are separate from the users who are actually using the application. Or as time goes by, you have a person who set up the account for a company and they move on to a new company, and then everyone else is like, "Okay, so now we need to take ownership of this billing relationship and it's tied to that user." That became painful over the years. We wrote some code to transfer all of the billing relationship from one user record to another user record, and fiddle with Stripe and do that, but it was kind of hokey.

Josh:
When we had so many things that were tied to the user based on the account owner role I think, that doing that meant assigning ... You had to change a bunch of different database IDs basically, like re-point them if you're going to reconstruct, like transfer ownership of everything to someone else.

Ben:
Right, right.

Starr:
So I think conceptually, I should point out that a lot of SaaS apps have a system where there is ... You go, you sign up for it, you, I don't know, maybe set up payment details or whatever, and then you start inviting people to collaborate. Those collaborators then belong to that account, so there's a clear delineation between the top level account, the owner, and these collaborators. Because the collaborators just belong to that account, and people can't collaborate for multiple account owners with the same login, and that's just not done by a lot of places.

Starr:
Whereas, a place like GitHub does a slightly different thing, you have essentially every user is a peer, every user is a peer, and users can collaborate on other users' projects. So I can invite Bob to collaborate on my project, and that doesn't mean that I own Bob's account or I have any control over it, but that's just it. So we went with the GitHub route, because we're like, "We want ..." I don't know if you guys were thinking about this, but I was like, "I want everybody to be a customer." You're going to log in to your Honeybadger account and you're going to see the arrows for all the different organizations you work with, because we all come from freelance backgrounds, so that seemed pretty natural. But we didn't start out with this accounts' idea that Ben was mentioning. To be fair, I'm not even sure GitHub started ... An account as you're talking about it is similar to GitHub org, and I'm not sure that you can GitHub launch with GitHub orgs.

Josh:
I don't think so. Actually, I don't even know if they have their full org system when we launched, because I think we copied a lot of what they were doing in the first place. So I think a lot of this has come out of us following what GitHub did.

Starr:
Yes, yes. I guess the lesson, and correct me or just let me know if you have any thoughts on this, but I think the lesson is like you either need to do a system where you have a single account owner and then user accounts belong to that owner, or if you go the GitHub route where people are peers, then in addition to those people, you need the concept of an organization or an account above them.

Josh:
It's detached, right?

Starr:
Yeah, that's detached, and that allows for the flexibility in setting up payment details and transferring projects and ownership that more things aren't just tied to individual people.

Ben:
Totally, yeah. We just launched with this notion that freelancers and small companies, they just have this person that pays for things and that's that. So you associate the billing with the person, and you're off to the races. But yeah, like the GitHub organizations, we realized that it is really handy to have this separate entity, separate from users, that has the billing responsibility, and then multiple people on the team can manage it and it can be moved from person to person, et cetera.

Josh:
Think of how often people switch companies, and a lot of people, like you work at a company and you sign up and you use your company credit card, but you're not thinking about, "What is this tied to?" But it's tied to your account, unless the service has some sort of abstraction that makes it easy to work in a team environment. So think about how often those people switch companies, that's how often we were having to deal with account transfers basically. It's pretty frequent, it turns out.

Ben:
There's the other issue that you just mentioned about having the person who is the primary responsibility for managing the account is not necessarily the same person that has the billing information available to them. But you might have an engineering team lead or an engineering manager or even a CTO that's responsible for managing Honeybadger, in this case, it's a developer tool, but someone in the billing department has the actual payment information. We ran into this problem fairly early on, we knew that developers by and large don't have the payment information on hand when they're signing up for their account, but they wanted to try it out. That's why we started out with no credit card trial up front, but we quickly ended up having to create a way for a user to share a link that they could send to someone that actually has the credit card. I think we, or at least I initially assumed that someone would get handed the credit card and they would key in information and et cetera. But having ...

Josh:
You would never give your employees a credit card back then, because as a freelancer, like ...

Ben:
Sure, sure. Although, everyone at Honeybadger does have a credit card, that's one of our policies.

Josh:
Yes, we do. We do give them now.

Ben:
So we did have that link where we say, "If someone else is paying for this account, just give them this link and they can enter in information." That worked out really well, but I think having a separate organization, in GitHub's terms, where you can actually invite someone to the organization whose only responsibility is billing, they don't need to access all the technical stuff, that's also really helpful and great for those businesses where you need some more partitioning among some different teams.

Starr:
I imagine this is going to useful going forward for things like SSO as well.

Ben:
So we do have to redo how we use some of our SSO, as a result of this. So right now, when like for example, Heroku, we're on the marketplace and people come in through SSO for that, after they've provisioned an account with us. So before, they signed in and we said, "Okay, you're a part of this Heroku app, so there you go." Every person that came in through SSO was actually tied to that one user. Now, they're going to have their own user records, because the Heroku provisioning is going to create an account, instead of provisioning a particular user. So it's going to be at a level removed. So yeah, it's going to impact that as well.

Josh:
That's interesting. That's potentially an improvement, like an improved user experience for Heroku users, because before, it's like no one had their individual settings, because everyone's on basically the same user in our app.

Ben:
Right.

Josh:
Which as I recall, was not unique to us. That's pretty much how everyone did it at the time when we originally designed our integration. I don't you could even have, they didn't have the concept of multiple users signing into an add-on at one point. Did they?

Starr:
No, they didn't when we launched. I'm pretty sure they didn't.

Josh:
So that's nice, people will get to use some of our user specific features like the local, like configuring your text editor for instance, with custom paths. You couldn't do that before if you were a team.

Ben:
So like I said, I've been wanting this for a long, long time. I remember talking about this many, many eons ago in Honeybadgers.

Starr:
This is an old dragon.

Josh:
Would you say it's canonical and accounts, the two dragons?

Ben:
I think I've started this work at least three times, and the prior two times were just like, it's such a big change, so much of the plumbing in our app that just gave up after a while and went back and did something easier. But I came back to it again, and this time though, having worked on Hook Relay, we used Jumpstart Rails for Hook Relay, and Jumpstart has an account, multi-tenant kind of thing built in.

Josh:
I was going to say, I really like the way they did it.

Ben:
Yeah. So I basically used that as the inspiration for how we're going to be doing it in Honeybadger.

Starr:
How awesome.

Ben:
That was really nice, so I really appreciate having purchased that and having seen their example. It kind of reminded me actually of people who bought RailsKits back in the day and they're like, "Yeah, I don't actually want to use the code, I just want to see how you did it so I can use that as inspiration for my own app." Which I thought, I never expected that, so that was kind of cool. So now I've done that on the other end.

Starr:
One thing that might be unexpected that also came about as a result of having our accounts we've had for so long, where every user has a Stripe ID, has been that one of the tools that go in and give you, crunch your Stripe statistics and then give you back information on trial users and everything, it really screws with them because they really ... If a user has a Stripe ID, they consider that user to be some sort of a trial or some sort of an actual potential paying user, which I guess that's fair.

Starr:
Whereas, in our system, it has this super long time. Everybody has a Stripe ID, even if they will never ever buy their own account, because they're only using someone else's account. So as a result of Ben's work here, I'm really excited that finally some of our metrics in third-party tools around trial conversion rates and stuff like that are finally going to make sense, because right now, our stats tools, they're like, "You have thousands of active trial users and you had a couple conversions today, therefore your conversion percent is nothing."

Ben:
Yeah, to be clear, we didn't have to do it that way. We didn't have to have a Stripe ID associated with people that we knew were just collaborators, but that was one of those technical shortcuts that you take to get the product launched faster.

Josh:
I don't remember, we might have built that before we even had collaborators. It might have just been literally everyone. I think we had collaborators.

Starr:
I think that was it.

Josh:
Yeah.

Starr:
But also, we had the idea of like, anybody can upgrade and then it's like, "I like this, I'm using it for my employer, I can just upgrade it and use it for my own other projects I'm working on."

Ben:
Yep, and that happened quite a bit. But now, we're going to have an account model and it's going to be created by a user, so a user has many accounts. So now you can have your private, your personal stuff, and you have your work stuff. You can manage those two accounts and build relationships separately. That account is going to have many users, and account will have many teams and many projects. So everything will be associated with the account now, and if we need to transfer ownership, now it's just a matter of changing the user ID for the account record, as opposed to changing a bunch of user IDs across a bunch of tables.

Josh:
Yeah. I think a lot of this just comes down to thinking about what the relationships are in your app when you're first designing it, and I think especially at the time for us, it was very much like the MVP, just do the simplest thing that you can think of or the quickest thing to ship. I think, I don't know about you, my thinking has come around on that a little bit recently, whereas like with Hook Relay, we obviously had Jumpstart, which did that thinking for us in a lot of ways, which that's like a huge pitch for Jumpstart. You can always just hire someone to design that up front.

Josh:
But if I were building an app from scratch, even if it's in MVP these days, I would spend more time thinking about the relationships, the model relationships within the code, but also the roles of what a user is in the system. Because a user, this isn't only useful in billing, I've run into similar issues in setting up marketing tools for instance. You want to communicate with different people, with people in your app differently, if they're a collaborator or if they signed up for a trial or if they own an account versus if they're just ... Maybe they're both, maybe they own a different account but they collaborate. There's a lot of different ways potentially that those relationships can coexist, and having some sort of abstraction for them in the actual app itself I think can solve a headache down the road. It's probably worth doing a little bit of that design up front for me these days, just because I felt the pain of trying to sort that all out once you have thousands of people in there and you're trying to figure out who is who.

Starr:
Yeah, it seems like it's a difference between breaking down all the different types of roles involved with your application. We've got a developer role, we've got a billing role, we've got a manager role. Versus just being like, "Oh, it's a user. We'll just make them ... Everything's a user, we'll figure it out later."

Josh:
Yeah.

Ben:
I'm with you, Josh. I think MVP was great when it came out and helped get people away from the idea that you had to do this waterfall, you had to do this huge production before you could even do anything. Agile of course, was the standard bear there, but these days, it's nice to have a little more polish, a little more thought going into that V1 that goes out the door. These days, I'm shying away from the MVP label and going more towards, "Well, this is the first cut. This is what we're going to show our customers, and we feel proud of it." It's not just, "Oh, here's the first thing that works."

Starr:
I really like that, the first cut. We should write a book about that.

Josh:
The first cut. Yeah.

Starr:
Can I tell you all a rambling grandma story?

Ben:
Please.

Starr:
It's going to relate. So I recently moved out to my new backyard office, and it basically took me about a year to build, I did most of the work myself. Early on when I was putting up the walls, I hadn't quite figured out how to reproduce, always cut off the ends of the boards in a completely right-angle way. So I had this one board and I didn't even notice at the time, but it was just at a little bit of an angle, so it stuck out maybe like a quarter of an inch more. One side of the cut was right at the right spot, and then it drifted a little bit, so it was maybe a quarter of an inch off the other way.

Starr:
I put it in the wall, I looked up, I was like, "That doesn't look quite straight, but it will be fine. It's a building, what's a quarter of an inch here and there? It's no big deal." So I built the wall, we put the trusses on, then like, "Oh, well the truss that sits on top of that piece of wood is now higher than the other side, noticeably so." So I added some shims under the truss on the other side to at least level it out, and so then we get that done and I'm doing drywall and I'm like, "Well, okay so this truss is actually uniformly higher than the rest of the trusses." So then I had to get these drywall shims and just stack those in. So now, finally, the drywall's done and the ceiling looks level, and you'd never know, but underneath is just 10 different types of shims, all just crammed in there. I feel like that's a metaphor for the user model.

Josh:
It sounds like Honeybadger.

Ben:
Yes, that sounds like a great metaphor for software development.

Josh:
It's great, yeah. Luckily, it's a little, I want to say it's a little easier to change the software than to change the building in most cases, at least that's ...

Starr:
That's true. Hopefully, I won't have to change it ever. We'll see.

Ben:
With the building, you don't have all your interfaces changing every time because an API went away.

Starr:
Oh, god. Yeah.

Josh:
You've got a new roof adapter that you have to support.

Starr:
Exactly. Like if you don't go in and change all the screws holding the drywall to the ceiling, they're just going to start failing in two months, because they're being deprecated.

Ben:
Like, "No, we don't have that paint color anymore, so you have to change it."

Josh:
That's a good one, Ben.

Starr:
Yeah.

Josh:
Back to the MVP thing though, these days, there are a lot more starters. Back then actually, there were a few starters, including the SaaS starter kit from RailsKits, which was your starter, Ben. You used some of that in our initial version. Ironically, I think you had it, at one point, you had an account model in there, and I think we opted to not go with it though or something. I don't want to out us, but we have to own, I guess we have to own it.

Ben:
I can admit my mistakes, it's fine.

Josh:
But yeah, these days, there are a lot of starter options, like Jumpstart or Bullet Train, there are others, there's free things. Then that's just Rails, so I think you can still, your MVP is going to usually, if you start with something else, it's going to include all, I don't know, the basic things that you need. You won't have to think about today hopefully, like you would back, if you're starting from scratch or back when these things weren't ... There weren't as many options basically.

Ben:
Yeah. I think these days, the stakes are higher, the table stakes. You have to come with some sort of team management if you're going to be doing a business app, because everyone expects to be able to invite people to join their team. I think maybe right now, we're going through a transition period where perhaps in a few months we'll see where ... Like two-factor authentication is table stakes, just because that's a thing. For example, Hey, they launched their email service recently and two-factor authentication is required, because we recognize that passwords are weak sauce. So this two-factor authentication is a way to make your app secure.

Ben:
So I think we definitely have seen over the past 10 years, and I think we'll continue to see these table stakes getting higher, and so it does really help to come in with one of these ready made things that has all this stuff done for you, so you don't have to think about it. It's just like Rails, when that launched, it did so much of the plumbing that you didn't have to think about, that before you had to do yourself. So I think going at those levels of extractions and having all that plumbing done is great.

Josh:
Again, these are the things that probably would have prevented us from launching anything at all, that's why we didn't do them in the first place I think, because we didn't want to have to do it ourselves and we could go scrappy. We had Rails, which was filling that, at the time, that was one of the ... It was like you said, the same deal. If we would have had to build our own web framework before we could launch our SaaS, we probably wouldn't have launched a SaaS. These days, you get to use Rails and you get to have billing solved and notifications and all the other things that have driven us crazy the past eight years.

Ben:
One thing I will say though, talking about tenant stuff, is I will come down strongly against the idea of using multiple schemas for doing multiple tenants. It's been a long practiced method of doing multi-tenant as having these multiple schemas in your database, how tenants are partitioned from each other. I've just seen so much pain come out of that.

Starr:
Like every separate account would have its own database or something.

Ben:
Basically, yep. In Postgres, they call them schemas, but in other systems, you can actually create separate databases to keep all the data partitions. Every database or every schema has the same structure, but it's just there's only one customer's data in that particular database or schema. But that's just so much pain, once you get to a point where you have hundreds of customers, because you're making all these changes anytime you want to change a structure.

Josh:
You have to migrate like 1000 different databases when you deploy.

Ben:
So totally just go with a tenant ID foreign key field in your database, people are like, "That's a security risk, because what if you forget to scope?" Modern framework will handle that for you, so just ignore the haters and go with a tenant ID, make your life so much easier by not doing multiple schemas, multiple databases.

Josh:
Yeah. You can make the same argument, what if you forget to have a database password or something? Yeah, you could definitely give everyone your data any way you look at it.

Ben:
Totally.

Starr:
Yeah, security is so 2019. Well, we should probably wrap this up. Do you guys have any solemn parting words or anything?

Ben:
No.

Josh:
Jumpstart, strong recommend.

Starr:
Jumpstart, strong recommend.

Ben:
For sure.

Starr:
Okay, well if you have enjoyed this podcast, please give us a review on Apple podcasts or whatever. If you want to write for our blog, go to Honeybadger.io/Blog and look for the "Write for us" link. That is the first test to determine if you are capable of writing for our blog, is finding that link. Yeah, go with our blessing. I will see you all later.

Episode source