In this episode we chat about refreshing OAuth tokens and building CRM features with SMS/voice APIs. CJ and Colin also talk about the tradeoffs of building "calm", bootstrapped companies versus venture-backed startups. It seems like everything that is old is new again! What startups from the 2009-2012 vintages do you think could do with some disruption today?
Some resources mentioned:
Colin: Welcome to Build and Learn. My name is Colin.
CJ: I'm cj and hey, we've officially survived past that one year point for a podcast. We made it. Most podcasts don't make it one year, and that's because of the podcast fade. The pod fade.
Colin: I think, that this is one of those like consistency things. This is the going to the gym, any habit. I have a newsletter, I have a blog. I don't keep them up to date as much, but I like that we put this on the calendar and we get to chat. So especially now that we're not in the same place anymore and it's still still something I wanna do. So I'm excited to hit that. And, and Transistor has this little fun badge system that I think it's nice to just, when you log in to edit an episode. I just saw it was a year, I don't think I would've noticed otherwise. So kudos to the team over there. Just a little fun, fun, surprise and delight in the transistor product.
CJ: Yeah, They've got like quite a few little gamification things built in that are pretty neat for podcasters. So there's like lots of little badges and things you can earn throughout. So it's pretty neat. What are you working on this week, Colin?
Colin: I am still a little bit in calendar. Hell it's been fun. If you listen to the last, I think actually two episodes I've been talking about Google Calendar, APIs and CloudFlare Workers and things like that. So still working on my Google Calendar bot. It's been fun. I've learned a lot about CloudFlare. Like I, I had to like, kind of like when you're working with Lambdas You make like different functions for different things. And I thought I had to do that in CloudFlare. And so I had like six CloudFlare workers and turns out you can just put them all in one CloudFlare worker. So that was the, the big takeaway for this week. A lot easier to deploy and manage like the same resources and stuff, so they all have access to the same database and key value store and all that stuff to do. All the different crons that I have to do. If you've never worked with the API before, like you can subscribe to a calendar's notifications, like new event, edit event, delete event, canceled events, but it expires after 30 days, and so you have to renew the subscription on top of also catching the events and dealing with those. So I, I had set it up as like a subscription renewal worker and then a subscription like events. Like kind of route to catch those web hooks and things. So yeah, just been playing around with that, getting that going. It's quite satisfying to get my first, like you have an upcoming event message where it wasn't just telling me what I had for the day, but it was telling me like right before the event that I had a meeting to get to. So that was kind of cool.
CJ: That's awesome. So for the subscription renewal bit can you, is it like you get a refresh token and then you just use the refresh token to get like a new access key or something, or? Okay, got it.
Colin: Yeah, and, and Google Auth doesn't last very long anyway, so I had to build, refresh into the whole system. So I kind of made like a function that gets their access token and if it's expired, Renews it so you always have a fresh token. But I also don't wanna refresh all the time just because you might be making multiple calls. So I usually, I, I do a try catch and if it fails, For token, like in like Grant invalid, then I do a refresh. And this is one of those things that I feel like I have to write over and over and over again and like, I think like Stripe and others u like have that built into the SDKs and stuff these days. But I usually don't use SDKs and do a lot of bear rest client stuff, so, or fetch.
CJ: Yeah, I like that pattern. I know like a, I mean, for a lot of OAuth APIs, They'll give you a refresh token. I mean, some of 'em don't do the refresh thing. They're just like, here's an access token that's available forever. Or like, if it gets revoked, then you just like have to go through the flow again. And yeah, I think when you're, when I was starting out, I definitely took the route of like, oh, I'm just gonna refresh these every night. Like, I'm just gonna run cron that goes through and re gives me new tokens every night. But yeah, I definitely find that it can be, A little bit smoother to sort of like lazily refresh, like you said. Just like wait till you actually need to use it. Try to use it. If it doesn't work, try to refresh it. Use the refreshed one. If that doesn't work, then you like handle your errors gracefully. But
Colin: It actually, I think it, it helps clean up the code a little bit too. It makes it more reusable 'cause you're gonna be calling it again after you refresh, you're gonna make the same call you made before. So like when I'm prototyping, I don't necessarily design it that way, and then it makes me like modularize the code a little bit and try catch, and then call itself again. And I think Google's, they only last a few hours, so you would want, you wouldn't wanna like, refresh every few hours if you're not doing anything with that data. But yeah, that's, that's kind of been in OAuth land and lots and lots and lots of practice makes perfect. I guess.
CJ: Yep, totally.
Colin: What are you working on?
Colin: I would not have thought that would've been an issue, but I can see how that would come up.
Colin: No, especially with Tailwind, like gives it to you and then you're like, I'm using Rails. I shouldn't be punished for this.
CJ: Yeah. Yeah. So I
Colin: another shout out for Chris.
CJ: Yes, exactly. I, like, I am using so much of his stuff. It's crazy. Like the, our, our stack is like, at least half of it is written by Chris, which I yeah. Hugely, hugely appreciate. If you if you haven't already and you're a rails dev, go subscribe to Go Rails, just to like help Chris out.
CJ: When you were at at orbit, what was the front end for the Orbit app?
Colin: We definitely had, it was a, it was a lot of stimulus, like in our our filter view, like that was all stimulus, I believe. So you could like add your filters for like which member you're looking for. We had React components, but I don't know when and where the, that's where like it gets fuzzy. Like we have React components, but how, how you interact with them from the app I think was using stimulus as, as the glue between this, if that
CJ: Okay. That's cool. Interesting. Yeah, we, we do like our marketing site is all built in next jss and we've been sort of exploring how do we bring some stuff. Like some React stuff and then just sprinkle that around the app the same way that we are with Stimulus. But I, I haven't gotten like too deep into that yet. So that'll
Colin: Well, I, I bet tabs are easier on the next JSS website, right?
CJ: probably. Yeah. You just like drop in
CJ: Yeah, some actually, you could probably just copy and paste the examples directly from Tailwind UI or Headless UI or whatever, and it should just work. But Things like combo boxes. We have like a dropdown list where you can add a specific paint color to a project. And in the combo box I wanted to show like a little palette that has the hex, like a little circle that is the hex color for the paint color. Then the name of the color, the brand, and like its little code, so like the Sherwin Williams code or the Benjamin Moore code or whatever, and building a like really rich. Each of the options really rich into just like a select or dropdown box was made so much easier with with these little tailwind components. I'd say, I dunno if you're using rail stuff, go check out Chris's tailwind stimulus wrapper. We've also got sort of a research project going on. We have I know I mentioned this like podium tool that is where we have our chat widget, but eventually we'd love to sort of centralize all of our communication, so we have. Phone calls, web chat, text message, and then even other like social channels, all of that coming into one source where we can like view all the past conversation history. And so I've been digging into Twilio Flex, which is kind of like, It's almost like the support agent interface that lets you say like as an agent. Yes. Right now I'm available and I'm online and I can handle conversations or whatever, and then it will ring your phone or it will, you'll get the web chat or you'll get the text message and you can kind of like handle each conversation. And right now, The whole entire UI is basically just dropped in as an an iframe and like into our application. And so over the next couple weeks something that I want to play with a lot is like using the Twilio APIs to create contacts and create conversations and start to like build mappings between like what's in Twilio and what's in our system. Just to see if Twilio's the right answer. I don't actually know if that's the way we're gonna go, but yeah, like Twilio, Intercom, any other sort of like multi-channel communication platform? Curious if you've had, do you have opinions or thoughts about things we should avoid? Things we should try? Is this anything you've touched before in the past?
Colin: Oh yeah. I've done a bunch of call center stuff. I would say avoid Salesforce. Yeah,
CJ: That's right. I.
Colin: Sorry. Salesforce. But you know, they have a lot of this stuff built in, but like Twilio feels like a strong direction because you get Ss M Ss, you get phone calls, you get the ability to do reminders and voice reminders that are automated and all that stuff, which is really powerful. If you have multiple agents around the world eventually, right, like people answering calls or texting or whatever, then it's whatever one is enabled. Like a lot of the tools out there promise that stuff, but it's like it's promised that you can go get a consultant to then implement it, not out of the box, right? And whereas you guys are already using the bare metal Twilio stuff, so like you might as well just extend off of that. I don't, does Intercom do text and voice stuff these
CJ: I am not sure I, so I've only looked, yeah, the, I've only really looked into Twilio so far and we're kind of still early in, in the research phase, but I. It's my understanding that Intercom has fewer channels. But yeah, like I, I kind of also expected that Twilio Flex would have a bit more. In terms of helping you connect to your own c R m or like your own sort of like customer database. It really just has support for a couple outta the box. I think it's Zendesk and maybe Salesforce, where like those partners of Twilio have built integrations into Twilio Flex. And it seems like if you want your C R M built into this, then you kinda like have to invent, reinvent all of the a p I connections, which. At the end of the day, they're giving you an interface which is much better than nothing, and just having the raw APIs, but,
Colin: Yeah, I mean, this is the tricky classic build versus buy thing, right? It's like how close to the bare metal do you go when what? What's your competitive advantage? Right? And we talked about this in last few episodes in the past, but the tricky thing with that is like if you were to, let's just say you, you, it sounds like you guys are building a C R M in a way. have infinite flexibility there versus if you go use a Salesforce, you will constantly be running up against what you're not allowed to do what you can do. Oh, we have to pay more to have access to that. Oh, that seat doesn't come with this thing. It's just, and like, Salesforce is not the new thing. The whole what's old is new again around designing like new startups around old concepts like Paul Jarvis has his analytics tool, which is very similar to the analytics tool called Mint. That was like, 2005, 2006 or something like that. And it was just better, simpler analytics than Google Analytics. And Salesforce was the simpler c r m against all these huge, you know kind of incumbents. Salesforce needs to be disrupted, like most of the CRMs that I see today. Either live long enough to become the villain and they become the big sales force that they are. Same for Intercom. Like I think Intercom will probably get, you know, there'll be a new startup-y version of Intercom that is simpler, cheaper, and they all end up going upstream to enterprise because they took so much funding and that they have to Which is why I'm kind of excited to see like the calm fund and tiny seed and stuff like that. Is that Salesforce would be a pain. So I would avoid that road. That's the long way of saying that, I guess, but, you know, there's things you could learn from that. I, I think you guys are on the right path with Twilio and I'd be interesting to see what you guys do with it.
CJ: Cool. Yeah, it is. We are building some C R M features. But at the end of the day, we're kind of just, the goal for this project is to centralize communication so that we have a full and complete history and I mean, there's a bunch of gaps and issues with our current setup. Like we're using Google Voice for some. Text message flows and like if anyone reads the text message, then it shows as red and no one else will know that it was red. Unless we're all being like super vocal about like, Hey, I read the text from so and so, it meant it said this, or whatever. So there's yeah, there's definitely gaps. But lots of opportunity for us to centralize.
Colin: I like that. So it's more a shared inbox, multimodal instead of c r m, right? Like, yes, there's the who, but you're not, I mean, you mentioned things like opportunities and deal flow and like where they're at and stages and stuff and, but it's so specific, like you would spend more time and money customizing like a real c r m to do that than just using code.
CJ: Right. Yeah. We're, we have like the coach built process for sales already built for this small set of states that we are, that we need and expect. And what's cool is that now we can build whatever automations we want to on top of it. And whether we're using an a p I to do some third party thing or we're building it ourselves, we can do that. So yeah, it kind of, it gives us the flexibility to integrate or like solve problems however we want to. For instance, we don't have integrations with a third party paint. Like manufacturer because apparently it doesn't exist or like yeah. So there's not like an a p I to like order paint from like Sherwin Williams or whatever, or as far, as far as I understand. And so instead we communicate directly to an account manager at a certain place, be a text message. And so like early versions of like order management, just gonna be like build the text message that's gonna be sent as like the order for the thing which is all stuff that we can. We can do because we have the flexibility and we're in a position like that, we can build everything that we need. So yeah, I dunno. It's fun, it's exciting,
Colin: yeah, like pulling back from the specific use case. Do you, the thing that I wonder, do you think a startup could build a C R M. I don't think the goal is to become as big as Salesforce, like Salesforce is just insanely large, but like to unseat Salesforce. Do you think that that is possible?
CJ: I think, I definitely think so. And I think the way to do it is to niche, like niche down and be like, okay, we're building a C R M for hairstylists and it's gonna be like super, super specific to hair and then you end up with squire or something like that, right? Like so yeah, I think it's
Colin: The MINDBODY online type
CJ: yes, yes, exactly.
Colin: CrossFit Gym, c r m. Yeah.
CJ: Yep. Yeah, I think the c r m, like c r m features are just, those are kind of just features of a system that's purpose built for a specific niche, and there's totally opportunity to go out and crush that. And I think a lot of people are kind of expecting, they have like more expectations about software that they're gonna buy to run their business, that it is already integrated with a bunch of stuff like, They're gonna want stripe out the box and they're gonna want customer messaging out the box and they're gonna want whatever, some, some sort of reminders in the Slack integration, discord integration and whatever,
Colin: So like the, the Salesforce a p i costs money, right? You have to be on a certain plan to have access to it, and then if you want to customize it, you have to use their like lightning and visual force and like a subset of Java and like there's just all these headaches there. So it would be under, if anyone has not used Salesforce, like the admin screen is, Millions of pages. Like it's, you open these toggles, probably not millions, it's hyperbole, but you know, you open a toggle and then there's like 10 more toggles. Then you open those toggles and there's like, you like hunt around for these things and they, they've added so many features for every use case that you have to hire consultants, which is what one of the jobs I used to have. Just to implement it and then you're not necessarily happy that you're paying a fortune for Salesforce and then a fortune to someone to make it do what you want it to do. So it's the c r m one is one that has rolled around my head for a really long time, but it just feels, you know, it's similar to the past where like if you don't have a lot of funding, a lot of companies won't trust it. Because the funding is a signal that you're gonna be around in some, some people's eyes once the funding dries up. You may not be around if you aren't a sustainable business, but I think like 37 signals used to have high rise. But that was like kind of like a Fisher-Price version of a C R M in my mind. Like it worked, but it was like a glorified calendar book. It wasn't really like a A C R M.
CJ: I think in terms of like customer support and sales, like really basic stuff for startups, there's definitely an opportunity to do something like, Maybe not as intense as Salesforce, but maybe closer to something like Zendesk where you could build a Zendesk competitor with some Twilio APIs and Jumpstart Pro and like a few smart things and a really nice design and a low, low price. And I think, you know, early startups would be like, hell yeah. Like,
Colin: Yeah, the linear of Zendesk
CJ: Yes, yes, yes, exactly. That's just like,
Colin: these are free startup ideas for everybody
CJ: Yeah, exactly. Yeah. If you're following along at home, I, you know, so like as I was going through the the thought process of Twilio and how I might integrate it and everything, I was like, oh, you know what? I think I might record this as a video because there's enough, like off the beaten path stuff that I need to, like, try and experiment with to see if it'll work. So if folks are interested in. Watching a probably a series because it'll take a while to figure that stuff out. Like let us know. Also, going back to the pod fade concept that we were talking about earlier, man, it is. Really, really hard to put out content consistently. I know you and I, we took a break. I haven't put out any videos on my own channel for like six months. I know that my former team at Stripe is like slowly sort of they don't foresee a ton more content coming out on that channel. So there is just, it is, it is really hard. I was talking to Aaron Koble from. Webflow earlier today. He's also like slowed down on content for his own channel. I think a lot of people are just finding it really, really hard and The point that you made about falling to the level of your systems, I thought was kind of interesting, especially because when, when I think about my blog and my like YouTube channel and your newsletter and your blog and things like that, right? Like those were only held accountable to ourselves, right? At least with this podcast, you and I are both sort of accountable to each other that like, okay, yeah, I'm gonna show up today even if I don't want to do it because I wanna hang out with Colin and I want this to be successful and whatever. And so there's a little bit more pressure. And I think this is probably also it's part of the system, it's part of accountability. It's part of part of the reason too that I think YC invests in companies that have two or more founders because it really gives you like other people to lean on and other people to kind of like hold you accountable for just showing up. So,
Colin: It's funny you say that because I don't, did, did you see the conversation going around about whether or not you should have co-founders or not on Twitter this week? On Yeah, it was of all people. It was the product person from Twitter Esther Crawford, who was saying that of her Angel investments. The ones that have gone to Zero the fastest have been ones with co-founders where they have a co-founder dispute. And I will say like, yes, those are real. Like you, when you're starting a company with someone, like you should not take that lightly, especially if you take. Investment, right? Because you are now not just accountable to your co-founder who is in weird way, you're gonna spend more time with them than your actual partner in some cases. You also are now beholden to your stakeholders and then eventually, hopefully your customers. There's just so much involved there. And so I know YC really likes to have founders who are like first time outta school, three people who went to the same school together, but like they really haven't seen life. You know, enough of life experience to to do it well and you know, usually you see, I think like even with Uber and Travis Kanick and some of these others, like it, it was not, Uber was not his first rodeo by any means. There were a lot of missteps along the way and I think they had their share of founder, you know, drama as well. So it's always interesting to see that. Thing of like doing a startup by yourself. There's just a lot to do. So like I don't necessarily recommend that, and there's, I think YC and Techstars both are like, well, if you can't convince someone else to come along with you as a co-founder, then why do you think we should invest that? That kind of argument is also interesting. But there's something to be said about just being able to build slow and calm and by yourself and work on it. But then, like what you just mentioned, like you're now only accountable to yourself. No one knows if you are showing up today to work on it or not versus having that, that partner to do that with.
CJ: Mm-hmm. Are you, so do you, do you have any updates about your Door app? We had talked about like you're gonna take a couple days off to work on the Reno Collective
Colin: yeah, so I guess this episode's going to another place that we didn't expect, but it, it works. It's good. 'cause this is like the build versus buy thing, but it's also, I. An issue with a startup that raised money and has to go upstream. So we've been using this tool called Robin to run our conference rooms at the collective so that the coworking space for, for those of you who are new to this and it worked really great, but it was getting more and more expensive and they have to go upstream because conference room booking as a business onto itself, when you've taken a bunch of money and you've gotten really big and you have a lot of employees, Is not a full business, right? People wanna rent desks. And so the app now touts some really cool customers that are huge compared to this measly little coworking space that we are. And so I don't fault them for going upstream. They have to, they're seeing a lot that they can do. Around like health, wellness check-ins. Like when you wanna book a desk and come into your company, like a Google or whoever, they want to say like, okay, you know, everything from your badging system at Stripe and Discord or wherever to physical digital security. Are you gonna have a desk and a coworking space? Like a lot of companies have reinvented their HQs as like glorified co-working spaces, and so they built all their tooling around that. And so like the app for us just doesn't. It's expensive. It doesn't make sense for us anymore. Our members are finding it confusing 'cause they're like, oh, I log in and it's asking me to book a desk. I'm like, yeah, don't use that tab. Go to the other tab. And we just don't have any control over the app and the experience. I've been holding off on just building my own for a really long time. But I've also been playing around with calendar APIs. So I am, I'm playing around with it. My first prototype is a React app that just checks whether or not each calendar is free or busy right now. So it'll basically be red or green depending on if the room is booked. So that part, surprisingly, will be like, the easier part, the harder part is letting people book, Having the UI to do the booking and, and all of that stuff. I think we'll start with just building it for ourselves with no expectation, but maybe it'll become a conference room booking app that's just run by one person. We'll see.
CJ: Is the Google calendar, a p i? You can, I assume you can create events through it. And even if you're not authenticated as the, could probably auth like auth as like, we are the coworking space. And then just use that auth token to create the room or like book the room or whatever.
Colin: Yeah, and you can do things like with service accounts and stuff you can actually impersonate. So there's like all sorts of OAuth magic you can do with Google. But the other way to think of it is that like an M V P would be having a Calendly to book the rooms. It requires us to like create each room as a person.
CJ: Very cool. Thanks for the update, and it sounds like a fun project. I know, like the further I get into my career, I'm getting a little bit better at not just like building stuff that I'm like, oh yeah, that'll be easy to do. Let me just build some little web scraper that goes and gets the data I need for this thing. It's like, okay, yeah, that that'll work for a minute, and then like it'll explode. So yeah, it's, it's, I'm, I'm, I'm definitely struggling finding a balance between saying like, no, you shouldn't build the thing because. There's existing solutions out there and the tam isn't big enough and whatever. And then also just, you should just build it. 'cause it'd be fun and it'd be like interesting. And if it happens to work, great. If it doesn't work, then whatever. Like try some other solution. But yeah, I don't know. Maybe that's what this like Twilio Flex plus Jumpstart thing will end up being.
Colin: I think we've talked about this in the past with build versus Buy, but like in a way, rails. Is like a hybrid of the two. Like you're not building everything from scratch. Like Jumpstart gives you so much out of the box rails is giving you so much power, and then flex, you know, literally flexing over here on Twilio. So like, it's it's good you got, I think it's a happy medium. You may go down that path a little bit and find that it, it's too deep of a rabbit hole. And I think like, keeping in mind like, is this you know, a unique value prop for us or. Is it not? Because I've been at a company where we were gonna spend like six weeks on a billing system and it's like, is us billing our customer unique to us? No. Why should we be spending six weeks doing that?
Colin: billing is broken in the industry of getting your house painted, then sure, but I suspect that's not the problem. Right. It's probably getting your house painted is the bigger problem.
CJ: Yeah, that is great. I, you know what, when, when I'm in it too, it's so hard to, to. Keep that high level view of like, what is the most important thing for the business? And I'm sure everyone who's working on a startup does this and they're just like, gosh, I want these tabs to work. It's like, okay, if these tabs aren't working, if instead you just throw everything on the page, is that gonna be good enough for now? And then, you know, try to prioritize and focus on the problems that are gonna really move the needle for the business. That's tough.
Colin: This gets into like product management a little bit, which we can definitely talk about in the future. But you know, having an appetite, like, yeah, we want those tabs, but do we want the tabs? If it's gonna take us a week to build them, probably not.
CJ: Right, right, right. Totally, totally. I think that's a good spot to leave it. Thanks for listening to Build and Learn. As always, you can head over to build and learn.dev to check out the show notes. We'll drop links to things we talked about and yeah. Thanks for listening.
Colin: Bye friends. All audio, artwork, episode descriptions and notes are property of CJ Avilla, Colin Loretz, for Build and Learn, and published with permission by Transistor, Inc. Broadcast by