The Square Developer Podcast

Square
  • 0.0（0則評分）
  • 科技

The Square Developer Podcast dives deep into the backend of a business. Hear discussions about tech that fuels commerce innovation with folks who have built apps, integrations, businesses, and more on the Square developer platform. In each episode, we’ll chat with a dev about their real-life experience using Square tools — the good, the bad, and the buggy are all fair game as we go behind the build. Together, we’ll talk about the tech world at large, and how it influences their decisions or drives their ideas forward.

  1. Building Innovative Mobile Solutions for Restaurants

    5月12日

    Building Innovative Mobile Solutions for Restaurants

    Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard. Head of Devrel here at Square. And today I'm joined by David and Arielle from Blue Rocket. Thank you so much for being here. Can you go ahead and just give us a quick little intro and tell us about Blue Rocket. David Foote: Blue rocket is a boutique design and development firm, and we kind of cut our teeth on restaurant apps very early in the history of the iPhone. We were the ones that put together Chipotle's first mobile app. And, today, we're still loving restaurants, but we're also spreading out into a lot of AI applications, especially where AI meets the phone. Richard Moot: Very cool. And, what is it that each of you do here at Blue Rocket? Just to set the context for any of our listeners here so we can like, be sure like who's who and who does what. Arielle Watson: So my name is Ariel. I do a little bit of everything. My technical title is VP of Client development. But, in any given week, that might look like working with our development team, working with clients, coding, if I'm lucky, and some design work as well. David Foote: And I'm the CEO at Blue Rocket and haven't always been, but my, my partner retired a couple years ago, and so I stepped up from CTO to CEO, but I'm still I still code on a weekly basis on a daily, daily basis because there's lots of admin and overhead to worry about as well. Richard Moot: I feel like you're describing a little bit of my life. So the majority of like, you know, your expertise within Blue Rocket is like these mobile apps. How is that like your approach to mobile app development sort of evolved over time? Or is it like you came in with, like a certain level of expertise or like, I'd love to know, like a little bit more of like, you know, how you approach those things. David Foote: Well, historically we were very iPhone centric. You know, we've done Android apps along the way, but we've always kind of been more likely to be involved in an iPhone first sort of situation where, where everything was sort of vetted and, and figured out on the iPhone. And then an Android app was created later recently. You know, we tried in like 2016, I think it was we we tried out React Native, and it was just changing so fast that we just couldn't it was just too unstable for us to to do production apps on. But, we tried again recently and we really enjoyed it. It's been a good experience. Retention. So we're actually developing for both Android and iOS at the same time with that. Richard Moot: Excellent. I think you're describing, like, exactly what my feeling has been with React Native for a very long time. And like, there's this very strong love hate relationship where I love it because I'm, I'm mainly a web developer. I know how to build stuff and react. So I felt like, oh, I suddenly feel powerful. I can make web apps or I can make mobile apps. But every time I would come back to an app after, like, I don't know, three, six months, I mean, I'm mostly going to be, like, shocked by my own code. You like who wrote this? But I would also get endlessly frustrated, like, oh, I'm going to go upgrade my dependencies. And oh my gosh, like, I can't get anything to build. And you know, actually X code's on a different version. And it was always a nightmare. So I'm glad to see that there's a little bit more stability here. It feels a little bit more reliable. Have you found that like most of this like expansion with React Native? Do you still do like native Android development or is it still kind of like iOS is like the deeper expertise and then like React Native enables this, like cross-platform, like code reuse? David Foote: We still do Android native development as well. For instance, we're doing some SDK work for a client right now. That's all. It's Java. It's not Kotlin, but it's all Java. Richard Moot: Very cool. And so part of the reason that we wanted to, like, have you on here and chat a little bit is that you've recently for one of your clients, actually started exploring building within Square's ecosystem. I'd love for you to like, tell a little bit more about, like, what brought you into adopting Square and like, how's it going? Arielle Watson: Yeah. So we were approached by a prospective client last year and given what they were out to accomplish, we evaluated a few different vendors. Square was one of them. And for the functionality that we were looking to build, Square had everything that we needed. When we looked at your guys' documentation and looked at the different APIs that you had. And so that was I think that was part of why, from a technical perspective, we recommended going with Square and then, for our client, they had a previous relationship with Square for some other of their businesses. And so they were also leaning that direction. So it worked out really well. Richard Moot: Also. And like, what was it that sort of like, stood out for you in like, sort of meeting the needs of, like, what it is that you were looking for for a platform because, I mean, like, you know, there's I'm going to be honest, there's we know there's a lot of platforms out there, you know. So what is it that sort of stood out and like sort of meeting it? Was it like something within our product sets or like I'd love to know more about what really met the client's needs. Arielle Watson: Yeah. So it was mainly the APIs that you guys offer. So one of the things that they wanted to accomplish was, kind of this dynamic macro calculation as your ordering. And so when we were looking specifically for a way to do that, Square was really the only one that had something that we could leverage for that. So we're using the catalog custom attributes. Richard Moot: And so, can we talk a little bit more about the app in sort of like what it is that you're building. Maybe like we'll roll back a little bit and sort of like you met with a prospective client that like, to what extent you can like to sort of discuss this, like who are they? What were they actually like looking to, to build. And then how did you sort of arrive at, like what you're going to sort of create for that mobile experience? Arielle Watson: Yeah. So bull is a fast casual restaurant that's opening this year in Elk Grove, California. Their offering is to be fast, be customizable to use high quality ingredients. And so when they approached us, being able to appeal to really any user that's on any diet was something they wanted to be able to do. And so the app that we're building supports mobile ordering of course supports loyalty, their rewards. So one of the features that they wanted to support was group ordering. So that a group of people working in an office could just submit one order, make it really simple. And so that's one of the things that we've done. And it was really important to us from a technical perspective, to be able to rely on whichever vendor we chose as the source of truth, so that our backend server could be as lightweight as possible. Richard Moot: Very cool. I feel like you're describing something that's like a dream of mine, my own. I have been really into macro writing for a while. I won't go on like a whole tirade around that, but because I'm, I'm sure nobody actually wants to hear that this isn't like some sort of fitness podcast. But you had previously sort of mentioned Chipotle and like I they're one that like I've seen have like a form of a calculator. I'm not I'm not gonna pretend like this may be the one that you built for them, but like, I know they had like a similar sort of thing of like breaking down calories, like, as you add certain things in, but I think the gap that I've seen in most things is like, I actually want to know, like how much protein, how much fat, how much carbs are in this because I'm basically measuring myself to like, I can only have this much. I love budgeting, and that's probably why I work at Square. I love finance, I love numbers, I'll budget my own food. So it's really cool to, like, be able to leverage something like custom attributes within Catalog. I've been dying to get people to use the custom attributes in this way for this exact reason. I can't tell you the number of developers that I have come in and like, kind of like stuffed stuff into, like different places on the object or put it in somewhere else, or they might just be tracking it on their own somewhere. So it's really great sort of here that you can actually sort of leverage this directly on the catalog and have that kind of nutritional breakdown. Arielle Watson: Yeah, it's been pretty awesome because we're using it for things like macro values on modifiers and on items, but we're also able to utilize it for flags, on those same items for that, that tell the app how it should render something. And so that's been something we didn't necessarily expect to be able to do from the beginning, but it's been really useful. Richard Moot: So one of the things I'm curious about with the app that you're building, because I think, I'm kind of like trying to draw from memory when we sort of talked before the the podcast we're recording here is that there's both a client facing like a customer facing experience, like mobile app. They would have, sort of, on their phone. But there's also like an in-store experience that you guys are also building for them. Arielle Watson: Yeah. Yeah. So we're building the consumer app, which will be on iOS and Android. And then we're also building a kiosk app for them. So that will allow people to just come in and order without needing to log in. And if they want to, they can get their loyalty points. Richard Moot: One of the things I was like, kind of curious about it, like kind of, a little bit change directions or kind of like roll back a little bit, when somebody sort of, like, coming in, like, you have this prospective client and I really kind of want to, like, paint a picture for other folks because, you k

    31 分鐘
  2. Scaling Entertainment Centers and Transforming Guest Experiences

    5月5日

    Scaling Entertainment Centers and Transforming Guest Experiences

    Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moody, head of developer relations here at Square. And today I'm joined by Eric and Alex from Headpinz. Eric, tell us a little bit about Headpinz and what it is that you do there. Eric Osborn: Sure. Absolutely. We're a chain of entertainment centers in Southwest Florida. We have everything from bowling to laser tied, the game zones, multiple restaurants, bars, and, soon to be adding an indoor racetrack. The chief information officer for head beans. And then I'm also joined by Alex here, one of our lead developers. Alex Trepasso: I'm Alex. Piggybacking off Eric there with all those different entertainment options and attractions we offer. I pretty much take over integrating them and making our whole ecosystem kind of work as one when we're dealing with all these different systems, you know, from scheduling all the way down to buying a burger, basically integrating those and overseeing the IT operations side of it. Richard Moot: Awesome. And so I don't know if this is quite mentioned, but like how many locations are you guys in the Florida region? Eric Osborn: Right now we're operating two. Well, actually three, two in which our Headpinz, we're actually making a transition from a traditional type bowling centers to more of, a hybrid type environment where we have those leagues on Monday through Friday that people are used to, you know, seeing for the traditional bowlers. But then on late night, Friday night, Saturday, Sunday, we're very much an open bowling venue, open up for families and all that good fun with laser tag and such. Richard Moot: Very cool. And so part of the reason that we're, we're talking today is you have built an integration with Square and it's it's quite interesting, but I'd love to hear the story about, you know, where you using something before. What made you go into using Square. Like tell me a little bit about like, you know what drove you into, you know, using Square through your locations. Eric Osborn: Yeah. So a little bit of a back story. We're actually use Square before our current POS provider decided to do a partnership with Square. We originally started using it for to-go orders during the Covid era when the bowling centers were shut down and we needed to find a way to get our that working. So we were online, and they were doing to-go orders and meeting them right at the door and delivering that food that has since grown into where we've actually made Square our base, then our truth of everything. And that's been a multi-year project. But everything that we do now, including the front end point of sale, our kiosk, our web reservation, anything that is touching financials are now funneling through the Square ecosystem. So a big change over the past three years. And, and that matter of fact, just over the past couple of weeks, as we've finally moved our final processes over to the Square ecosystem. So that's been great. Then where, Alex comes into play and, and, and where the development actually came from was there was some third parties that just simply did not work with Square, such as one of our kiosks, and a couple other small little things like our group function where they actually sign a contract and actually take a deposit. Those things weren't working with Square Alex along and, and worked with, the Square ecosystem on a solution to that. He can speak a little bit about how our kiosks work and such, even though they're not a native, you know, Square partnership that we got to work in on our own. Richard Moot: Yeah, I'd love to like the I mean, that's one of the things that really piqued my interest is you know, you have, well, I don't want to steal thunder here at like, the front of the venue. You have these, like, sort of kiosks where, like, it allows somebody to be able to purchase, you know, various other things, like, other than bowling. And you built this all yourself, essentially. Like, tell me a little bit about, like, the integration that you built with these kiosks and how that all works. Alex Trepasso: Yeah. So it started from a position of when we first got the kiosks, one of their native integrations was another payment provider. And kind of where we came in was, okay, we have these two different systems. You have Square on one side and this other provider on another, both doing, you know, different transaction fee rates, different handling, different view of transactions. And it came up one day in our operations and kind of just our discussions of can we unify these systems. And that led kind of down the rabbit hole of the Square terminal API was kind of our first dive into everything Square developer. And it came along, okay, we know that Square offers this, that we can use this for payments even without sending, you know, a forward or, or doing a whole POS based Square install. Let's try some things from there. We used the terminal API to start listening for those transaction requests that our kiosks were sending to host those on a cloud provider, and it listens for those requests when it sees one, creates a payment request to the terminal and treats it just like any other would for the kiosk. The transaction is completely seamless and paid and just Square it, seeing the payment come through, you know, just as any other transaction, which started kind of our path of Square being our source of truth and opening up the doors of this could be our full ecosystem, even if it's not natively provided by Square, natively provided by our other vendors. Richard Moot: Yeah. And so for the, the kiosk itself, I'm wanting to sort of refresh and also highlight for those, those listening and you know, you primarily do these like a bullion venue and then you have like other things like arcade food and beverage, you're going to be having like the, the go carts. And what all does the kiosk cover in terms of like the guest experience. Eric Osborn: So on your kiosks are we basically covers everything from bowling. We actually have two different types of kiosks, one that is covering bowling and then one that covers all of our other attractions. Those are the ones that you see when you first walk into the facility. From there, you'll actually be able to schedule laser tag ax throwing. You'll be able to buy a Game Zone card, which is, you know, a card like POS system on the game, as well as schedule racing at our other facility. That'll be just across the parking lot that is currently being built. So it's really a one stop shop. Bowling is not handled there because a lot of that does come in through our web payment system. You're booking online ahead of time. These are kind of like those extra attractions when you walk in the door and you're still waiting for your lane or you know you want to find something to do in the interim while you wait for your food. That's kind of what these kiosks address. Richard Moot: I see. And so one of the things you sort of touched on is like, you know, using Square as a source of truth, what kind of like, drove the desire for having that? I mean, and I only ask because, like, you know, I've talked with other people, they might, you know, say they have an ERP system or like, you know, their own bespoke solution. And you know, what kind of started like getting you into the mindset of, of driving towards using Square as your source of truth for, you know, customer data, order data, that kind of stuff. Eric Osborn: Yeah. So we had a plan to, you know, keep moving in the direction of Square wherever possible. However, some things along the way kind of just started to kind of pick up and get aboard the, you know, the path and the ecosystem as we were seeing. It's just easier to funnel the data through Square. That gives us a centralized system to look up all those transactions. It's a centralized system to get all of our financial data over to our online provider. For finances was important to us. And then along the way, we discovered that we were writing all these different tools to make this happen. And we didn't need it. As long as we got the transaction into Square, it was going to do the rest for us. So it really has become that seamless experience. We've taken it a step further and Alex can, you know, mention a couple things about this, but we're even going as far as the Square Catalog is now, that centralized source of truth as well, because it didn't make sense to have to do, you know, before Square came along, I had to put in place keys into three different centers, three different POS centers, or three different POS systems. At each of those centers. And then get it all thinking back together. Whereabouts now, even those third party providers such as, you know, things that do our group function reservations are looking at the Square catalog. Our front desk bowling operation is looking at the Square catalog. So now we have one set of price keys, one set of financials. And you just have that seamless flow into our financial system. And if Alex you want to touch on the thinking because that is something that he custom built as well. For one of the providers to make that happen. Richard Moot: Yeah, I'd love to hear about that because, you know, it's like how often I end up hearing about people trying to sync things between, you know, various different systems. I'd love to learn how you sort of approached it here. Eric Osborn: It's so hard to do it by hand. Though, I'm glad this worked out. Alex Trepasso: Yeah. So it started as kind of a part of our discussion of we're a very report heavy company, and we really like to know what people are doing in our centers. We like being able to have an idea of what's going on. So it started with, okay, our reports at this point were just showing, you know, here's a customer amount transaction coming from a kiosk or this kind of uncategorized revenue that we we knew was coming in certain ways, but we didn't know what peo

    43 分鐘
  3. Integrating Phone Numbers into Brand Identity Verification

    4月28日

    Integrating Phone Numbers into Brand Identity Verification

    Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of developer relations here at Square, and today I'm joined by Binh Ly who's a member of our developer community and is the owner and operator of the company operating. Ben, thank you so much for joining us here. I'm so excited to chat more with you about what it is that you've built on the Square Developer platform. You're also a hackathon winner. I'd love for you to just tell us all a little bit more about how you first got involved with Square and a little bit about your involvement on the Hackathon. Binh Ly: First, thank you for having me. It's a pleasure to be here. So Square has been on my radar since around the time of the company's founding. I was working with a device that could handle credit card swipes, but I wasn't using that component of the device, but I was trying to think of a reason to use it. And then back then the thought was like it stinks is when you go to the restaurant and you're with your friends, so why can't you split that check? So we're like, let's try and build something to do that. But back then onboarding a merchant account was not that fun. So that lag time and making the sale and then getting the software activated for someone was too long, but we were fascinated that Square could do it in two minutes. So I was like, Square is pretty interesting. So I just followed the company's trajectory that whole time. And then I finally switched careers since I changed the thing that I was working on from shipping software to messaging software around 2017. So that was the first version of Operator that existed in a different company. And back then the idea was that you should be able to message any company, but how do you do that without selling software at every business in the country? So we had this really insane approach where if you text it into the system, we would call the business and ask them the information and then text it back, but, Richard Moot: Oh wow. Binh Ly: That was pretty neat that it worked that way, but ultimately wasn't scalable. But then once we realized that you could send text messages to the landlines, that changed everything because a majority of businesses have landlines and SMS is the most installed software on earth. So to get the customer you didn't have the two sided problem, the software was already on the phone. We just need to collect the text messages sent to the landline and present it to the business owner. Richard Moot: I mean, I always think that that part is fascinating to me because it's still, even after you submitted the hackathon thing and every time I come back to it, I think this is something that most people just don't think is possible of getting SMS on a landline. So for those who are not familiar with this, how is this able to work or to what degree could you sort explain how this works to us? Binh Ly: Yes. So the way it was explained to me about how it works is that you can picture a gigantic phone book and there's every phone number, every landline number is in there, and there's imagine two fields next to every phone. Number one says data traffic and one says voice traffic. So when you get a cell phone, the voice traffic says whoever your carrier is, AT&T, Verizon or whatever. And then the same for the data field, but for a landline, the data field is empty. So when you send a text message from your cell phone to a landline, it just goes to nowhere because it doesn't know where to route it. So by taking over provisioning the landline for voice traffic or data traffic, we're saying route that to the operator system. Richard Moot: I see. And so does this require any kind of physical component or is this actually something that's like they just, it's done within at the carrier level? Binh Ly: It's all at the carrier level. Richard Moot: I see, okay. Binh Ly: Yeah, so to actually utilize this capability, you just need authorization from the business that owns the landline. And so they just signed their name on a letter of authorization and we submit that to the carriers and then a few hours later, traffic starts flowing through. So that's one of the moments of delight for the customer is that they didn't realize this was happening. They signed up and they started getting traffic coming in and they're like, I didn't tell anyone we can do this. So I'm like, it's already happening all day every day and now you're getting access to it. Richard Moot: So what you're saying there is have some businesses signed up for this and suddenly without even prompting of people are getting text messages and didn't realize that people were texting them this whole time? Yes. Wow. Binh Ly: Yes Richard Moot: Wow Binh Ly: So a lot of missed business happens this way. We just saw, we signed up a window tinting business without telling any of their customers. They're getting requests, can I get a quote on this tint? If they didn't have the service, they would not know about that requirement. And the other cool thing is that it's not replacing anything. You get the voice traffic still and now you get the data traffic. It's up to the business owner how they want to respond. They can call 'em back if they want that hyper personal touch or just text back, which majority of the customers who interact with the platform prefer that just text, send text, and off you go. Richard Moot: I mean, I'm guilty of that. I've been so stoked in the recent years that more and more businesses are allowing texting directly to these lines because it's been able to reschedule. I mean, giving my car serviced at this local car shop, it's so much easier that I get a little text message, Hey, your car's ready and you text back and great, I'll be there by two and I don't have to answer a phone call meetings all day. Most of the time I just let that go to voicemail and then I hope that I can text 'em back to say, Hey, I'll be there. So it's so convenient. Binh Ly: That voicemail aspect is also a really interesting component of the customer communication. We found that people don't leave voicemails. So if someone calls you miss the call and then they don't leave a voicemail, it's really hard to have any context around that. So we invented this technique where if you call the landline, someone calls your landline and if no one picks up, the system will text you back from that landline number. So it's not a spooky experience with a caller. If you called one number, then you got a text back from another number saying, Hey, I saw that you called. It's kind of a weird experience. So you probably ignore that too. But if you call one number and you get text back from the same number, the response is pretty immediate. Richard Moot: Yeah, I mean it's so validating because like the phone number for a lot of businesses, this is a form of identity for them. And so by keeping it all within that one thing, it feels very cohesive. You can trust it. I've definitely had this spooky thing happen where I call one place and then I get a text back from another and I'm like, I feel like I'm being, this is a weird phishing thing going on. Binh Ly: Yes. Richard Moot: You definitely don't want to have more of that. Binh Ly: Exactly. And a lot of businesses don't realize until you point it out to them that their phone number is part of their branding. So if you drive by auto shops or something, you'll see the name of the business and sometimes the phone number is just as large in the typeface. So now you can maximize the utilization of that number, put a simple call or text this number in. In comes the traffic. Richard Moot: And so you have this technology of being able to do this SMS routing, and then you built an app for R Square hackathon and you won. Tell us a little bit about more what you built and why you built it for the hackathon. Binh Ly: Yes. So the project that won the hackathon was not the project that I started with. The initial project was digital appointment cards. So if you book through Square Appointments today, you'll get an email and in that email are a couple of links to add to your calendar. That's over email. But if you think about in real world scenarios and medical practices, for example, or dental, you go in, you do your checkup or whatever at a dental office and they say see the front desk before you leave. So you go out there and they say they want to see you in six months, they put it into their system and then they write down your information on a card and hand it to you. So it's on you to either remember that forever until the appointment or enter it into your own calendar. So I didn't know at the time that Square sent that email that lets you add to the calendar. So I thought, let's do that over SMS, but I built that those tied in Square Appointments and it sent you a text where you can add it to your calendar. Then we saw that you could do that over email. I was like, oh no, this is the saddest thing, all this work. Then I vaguely recalled an article I saw on your website about the number of no-show and cancellations, And it reminded me that it's like the missed call thing. Again, if you don't figure out how to respond to that, you're going to lose it hundred percent. So we looked into how do we, could we hijack that process? If there's a no-show or a cancellation, can we help the business try and recover that? At least take a shot at it, right? 50/50 chance of getting that business. So that was the genesis of that. Richard Moot: And to be honest, we were very inspired by that because being able to recoup even half or a quarter of those no-shows is that could be the difference between making or breaking it in a given month or quarter for a business. And I think the other part that you had mentioned previously that was also really impressive is say somebody has an appointment, they called in, they didn't leave a voicemail, maybe they wanted to reschedule, with Operator, you can actually

    41 分鐘
  4. Beyond the Network: Unlocking the Power of Programmable Traffic with Ngrok

    4月21日

    Beyond the Network: Unlocking the Power of Programmable Traffic with Ngrok

    Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard, head of developer relations here at Square, and today I'm joined by Peter from Ngrok. Peter, thank you so much for being with us here today. I'd love for you to just give us a little bit about yourself, a little bit about Ngrok, and let's kick things off. Peter Shafton: Sure, hey, thanks Richard. Thanks for having me. So my name's Peter Shafton. I'm the CTO of Ngrok. I've been with the company for a little over three years, and I actually learned about Ngrok way back from when I was at Twilio about 13 years ago because the founder of Ngrok, Alan Shreve, was an engineer on a team there that I was running at Twilio. So I first started the voice and messaging parts of Twilio, that was actually the beginnings of Ngrok. But I've been sort of bouncing around Silicon Valley for a lot longer than that. A bunch of companies you all have heard of, probably Cisco and Yahoo, those who are old enough, SGI, and then a bunch of little startups that people maybe didn't hear of as much. But yeah, that is my past. So I'm a developer at heart, an engineer at heart, and then somehow ended up doing architecture and running technology. Richard Moot: I feel like they always trick us and lure us into this in some way. I mean, it's very alluring, but then eventually you're just like, wait, what happened? I'm now the CTO of a company. Peter Shafton: That's right. As long as they don't take away the keyboard, I can still type code there. I'm happy. Richard Moot: Do you still get to occasionally write some code for things or do you find the time for it? Peter Shafton: I do. I do. I do it badly, and most of my engineers hopefully don't let me do that. I end up in the data space more than anything or through SQL or the data warehouse and data lake areas, but at times I'll write some low level code and networking code and things like that. Richard Moot: I mean, you got to find the time for it. It is kind of invigorating, but at the same time, I would agree that outside of Dev Rel, I am less inclined to build stuff that's going to be relied on in production, and I'm more inclined on building, here's how to do this particular thing, or here's a little script for pulling some data together so that we can make sense of stuff. Peter Shafton: Yeah, I think most of us got into this because we loved writing code. I think if you'd asked me, I was a young kid, an Apple++, and I didn't realize this was a career. I just thought it was a really cool hobby to have, and then the thought that somebody would pay me to do it, and so this is the piece that got us excited. If you left most of us alone, we would still be writing code. It's just nicer when you're doing it at scale and allowing other people to see what you built versus, Richard Moot: Yeah, no, I mean I think that it's really well put. I mean, most of the time I'd build tiny little automations in my house for like, oh, now it's much easier that when I want to go to bed, it turns all my lights off at one time instead of just me having to go through all of them. But now it's like now I can solve problems for thousands of people, millions people. Peter Shafton: Oh yeah. Richard Moot: So you used Ngrok a long time ago before you actually even joined the company. I'm curious, what was it when you first used, well, two things I kind of want to answer. For anyone who's maybe not familiar, we can give a quick little explanation of what Ngrok is and then what was it like when you first used Ngrok that made you fall in love with it, or I don't know if you'd call it love, but I mean I felt like I fell in love with it when I first used it. Peter Shafton: No, it's a good story. It's a good story. Yeah. So there was an engineer by the name of Jeff Program. He was one of the early engineers at Twilio at the time. He had come from NASA and he built a tool called Local Tunnel, and he built it for a very specific purpose. So Ngrok basically fit into the webhook infrastructure that was Twilio. So the early days of Twilio, it's still true today is all powered by webhooks, which effectively means you get an inbound phone call, you get inbound text messages, you want to respond to that and control the programmability. You had to respond with XML, with twiML at the time to an inbound web request because that looked very much like how the internet worked. They figured people were writing PHP scripts or Python code for a website. They were used to getting a form post and responding, they thought, you can just reuse that infrastructure. It just happens. It's a telephone that's calling you instead of a browser client making the request, which made a lot of sense because that was what the developers were doing and it was easy to build on. The challenge was if you're inside Twilio and you're building the product and you need to be able to test it or even iterate on what you're doing, a very slow loop is I build a thing, I deploy it to production, I let a webhook hit it and see if it works or not. What we wanted to be able to do was change the code, maybe even sit in a debugger and have the webhook come in and trigger our code. And so to solve that problem, Jeff built something called Local Tunnel, and it was a simple bit of Ruby code that effectively gave you a dynamic URL. So if you think about it, they call it reverse proxy, but you basically have a little sidecar sitting on your machine. It makes a network connection out to a server that is on the public internet and it tells that server a domain name to use, so fubar or whatever it is. If you hit that request, it'll basically tunnel the traffic back to your local machine so you can iterate and have something that kind of looks like it's on the internet, it's accessible on the internet, but it is not otherwise there. It's on your local machine and if you shut it off. So that was local tunnel and it was used inside Twilio. Alan was one of the engineers at Twilio using this, and it was fine when it was just a few of us. As it scaled up, we realized the Ruby implementation was not particularly scalable, didn't really serve our purpose at scale. And so he said, I think I can rewrite this and I think I could do it much better. And he started to iterate on it and go, and when he left Twilio, he said, I'm just going to make this a side project. It was, but it turned out it was a side project that went very, very far. So the early implementation of Ngrok was very much a tool for testing, for testing webhooks, for developing websites, developing APIs, and that was kind of the early history of the product and of the company. Richard Moot: And that's exactly where I probably first started interacting with it when it became this sort of tool that was put out there. And I remember even really early on, it was very, I mean, it was straightforward for signing up if you actually wanted to use it beyond the sort of free version of it. But I got to say that after just installing that CLI tool, putting it in your local bin folder and then just calling it from your path wherever you want. And I think the first time that really got me was when I was working on something at a company and I was trying to update stuff on a marketing page and trying to get whatever it is that they wanted, the way that they wanted it. And I just ran Ngrok and had a URL, and then I was able to send it to them and say like, Hey, is this what you are wanting it to look like? And they were just immediately giving me feedback and testing things and I could see all the traffic of what they're doing in there. And that was a really amazing thing because normally I would've had to take all of that, push it somewhere, put it up on a staging version, deploy it somewhere, and I really was not at that point, I was like, I'm just trying to move things from one place to another and I want to show you what it looks like on my machine. The ease of using it was just so great. Peter Shafton: Yeah, no, it made a lot of sense. I think in the early days it still does for different reasons, but the early days, sort of the aha moment, we have a tagline now we use that says online in one line, which basically meant you could download the Ngrok executable type in a simple command line like you might for Curl or something and you'd be up and running. And I think the fun part was both testing for folks like you and I iterating on code turned out, and Richard and I were talking a little bit before this about having automated home infrastructure and those of you who have put up stuff in your house and automated it and realized, well, if I want this to be accessible when I'm not at home, then I need to somehow punch a hole into my home network. And that often meant messing with the settings on an Xfinity router or AT&T or something else to figure out how do I open this thing up and allow access. And Ngrok made that really simple too. And so we found a lot of developers that were hobbyists and that were doing and automating things. And that sort of device gateway or access became the early days of how it was used. I think the scary part is once you put something on the internet, you're like, okay, this is out there. Then you forget that it's on the internet and everybody can hit it and use it. And so having other sets of capabilities that do allow you to put authentication in front of it, all of these became the obvious kind of next steps. And if you look at the history of the company, you can see where that progress happened. But it was always that sort of aha moment that I think got early developers and I mean, it's crazy sort of the scale of this hit. There are over 10 million developers that are using Ngrok and thousands every day that come down, which you think of somebody that was bootstrapped, it was hard to imagine that you would start that way. Richard Moot: Yeah, no, I mean the growth in the evolution of the product has really impressed me over the last f

    44 分鐘
  5. Codename Goose - Your Next Open Source AI Agent

    4月14日

    Codename Goose - Your Next Open Source AI Agent

    Richard Moot: Hello and welcome to another episode of the Square Developer Podcast. I'm your host, Richard Moot, head of developer relations here at Square. And today I'm joined by my fellow developer relations engineer, Rizel, who's over working on Block Open Source. Hi Rizel, welcome to the podcast. Rizel Scarlett: Hey, Richard. Thanks for having me. And I know it's so cool. We're like coworkers, but on different teams Richard Moot: And you get to work on some of the, I'll admit I'm a little bit jealous. You get to work on some of the cool open source stuff, but I still get to poke around in there occasionally. But today we wanted to talk about one of our most recent releases is Goose, and I would like you to do the honors of, give us the quick pitch. What is Goose? Rizel Scarlett: Goose is an on machine AI agent and it's open source. So when I say on machine, it's local. Unlike a lot of other AI tools that you use via the cloud, you have everything stored on your computer, private, you have control over the data, and you get to interact with different lms. You can choose whichever you want, whether it's GPT, sonnet, 3.5, whatever you prefer, you get to bring it. Richard Moot: Awesome. And so I'm going to hopefully give a little bit more because I want to just kind of clarify for Square developers who might be coming in, they're like, they're just building other APIs, SDKs, trying to extend stuff for square sellers. So when we're talking about an agent, an agent, I always end up thinking the matrix, the agents and the matrix. And from what I understand, it's not too far off. You give it instructions and it will actually go and do things on your machine for you write two files, edit files, run commands. It's almost like doing things that a person could do on your computer for you. Rizel Scarlett: Yes, exactly. That's a really good description. It doesn't just edit code for you. It can control your system. So I had it dimmed, the lights on my computer open different applications. You can really just automate anything even if you didn't know how to code. Richard Moot: Yeah, I mean that's one of the things that I didn't even really think about when I first tried Goose. So one of the fun benefits of working here at Block is that I got to have fun with it before it actually went live. And one thing that I didn't really think about until I tried the desktop client and I forgot to allow the plug, there's two different ways you can interact with it. There's the CLI and the terminal, and then there's a desktop client, which I think right now works on Mac os. Rizel Scarlett: Yes, Richard Moot: I know there's big requests and to have it work in more than just Windows. Rizel Scarlett: Yeah. Yeah. Right now, I mean we do have what I think is a working version of Windows, but the experience for the build time is not great. So we're still working through that. Richard Moot: Yeah, well, having my own wrestling with working with the Windows sub Linux, I only really think of it as WSL. I've had so many headaches of trying to deal with networking and connecting and when do I need to switch to the power show versus a terminal, and it's all the reason I end up falling back to doing all of my development on my Mac. Rizel Scarlett: Yeah. I haven't used the Windows computer since I was an IT support person. I don't even know what the new developments are now. Richard Moot: Yeah, I mean I recently got burned by that where I didn't realize that in order to do certain virtualization stuff, you had to have a specific version of Windows, like some professional version, and then that enabled virtualization to run a VM of something interesting. I think since then they've baked in the Windows sub Linux thing, which is basically just running Ubuntu in a virtualization for you. But that was an eyeopener, but thankfully Microsoft's working on fixing these things, but we digress. So coming back to Goose and what is it that most people have that you've sort of seen from the community as they've been starting to try it out and use Goose? Rizel Scarlett: Yeah, I mean I just see people, well, a lot of it is mainly developers. That's the larger side of just using it to automate a lot of the tasks that they are doing. Maybe setting up, what am I trying to say, the boilerplate for their code or just sometimes other different things. I see people wanting to build local models and just in general or doing things with their kids, but I've also seen people doing silly experiments. This is where I find a lot of fun where people are having Goose talk to Goose or having a team of different, I guess geese, a team of agents and they're basically running a whole bunch of stuff. So they had one Goose be the PM and it was instructing all the engineer agents to perform different tasks. So it's a varied amount of things, but a lot of people are just trying to make their lives easier and have Goose do the mundane task in the background while they do the creative things. I've just been doing fun silly stuff. Like I had Goose play tic-tac-toe with me just for fun. I just wanted to see if it could do that and that was cool. Yeah. Richard Moot: Have you beat it yet? Rizel Scarlett: Every time I'm disappointed. Richard Moot: You think it'd be way more advanced? I mean tech to can kind of, if I'm not mistaken, I think based on who goes first, it can be a determined game as long as you play with perfect strategy. Rizel Scarlett: Yeah, I told it to play competitively. I'm still working on the perfect prompt. You always let me win Goose what's going on. Richard Moot: Maybe that's part of the underlying LLMs is that they want to be helpful and so they think they're being helpful by letting you win, otherwise you wouldn't have fun. Rizel Scarlett: That's true. Richard Moot: Well, one of the things I was very fascinated by when first trying out the desktop client versus the CLI, because I habitually used the CLI version, but when I first opened up the desktop client, I had asked, what is it that you can do? And one of the things that it suggested that never even occurred to me was using Apple Scripts to run certain automations on your system. And I immediately just went, okay, can you organize my downloads folder and put everything? And it just immediately put everything in organized folders. And that's something I used to, I mean years ago, write my own quick little scripts to be like, oh, I need to move all these CSVs into someplace and PDFs. And it just immediately did it for me and it was just, that was amazing because now I can actually find where the certain things are. Rizel Scarlett: That's so awesome. Yeah, I think you might've been using the computer controller extension, and that might be my favorite so far just because of, oh my gosh, it could actually, it's not just writing code for me. I'm like, okay, cool. There's other stuff that can do that Cursor does that as well, but it can tap into my computer system if I give it permission and move things around. I did a computer controller extension tutorial and I was just making it do silly stuff. Like I mentioned, it dimmed my computer screen. It opened up Safari and found classical music to play it, did some research on AI agents for me and put it in A CSV and then it turned back on the lights. It's so cool. I can just tell it, go do my own work for me and I'll it back. Richard Moot: Yeah, that's great. And so you touched on something that I think is kind of an interesting part about it, and I feel like I want to come back to the part to really emphasize GOOSE is an open source project, and so it allows you to attach all of those various LLMs to sort of power the experience. But what you just touched on there is the extensions. So the way that it can do these things, could you tell us a little bit about what are extensions and how are they used by either Goose or the LLM? What is the relationship there? Rizel Scarlett: Yeah, so extensions are basically, I guess you can think of it as extending it to different applications or different use cases. And we're doing that through a protocol called the Model Context Protocol, which Anthropic and us have been partnering on. And basically it allows any AI agent to kind of have access to different data. So for example, there's a Figma MCP or a model context protocol, and you can connect GOOSE to that MCP and tell it, Hey, here's some designs that I have, and Goose will be able to look at those and copy it rather than when you're maybe working with something like chat GBT, you have to go and give it context and be like, Hey, chat GBT, I'm working on this. Here's how this goes. And it takes up a lot of time. It'll just jump right in. And like you were saying, it's open source, so anybody can make MCP, you can connect it to any MCP out there that, I mean, some of them have to be honest, some CPS that are out there since it's open source, they don't all work, but the ones that do, you can connect it to Goose. Richard Moot: Yeah. And so that's kind of like what you were originally talking about, the computer controller one. Richard Moot: I'm going to hopefully describe this in a way that can make this visual for those that are listening in. But when you're using GOOSE in the terminal, when you first ever install it, it'll run you through a configuration of, Hey, it's basically setting up your profile and it says, which LLM do you want to connect to? And then you can kind of select from there and then it'll say, give me your credentials. And then after that you can get the option to, well actually maybe I'm jumping the gun here. I think it just gets you through storing that. And then you can have the option of once Goose is configured, you can toggle on certain extensions, extensions that are included, and then there's a process to actually go find these other ones that are published elsewhere and then add them in, right? Rizel Scarlett: Yes, that's correct. We have your built-in

    40 分鐘
  6. Lessons in Leadership, Delegation, and Team Growth

    4月7日

    Lessons in Leadership, Delegation, and Team Growth

    Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard. I am the lead for Developer Relations here at Square. Today I'm joined by Dina Spitzer, who is an engineering manager at Square, has been with the company for coming up on 11 years now, has seen a lot of changes over time. Dina, I'd love for you to just give us a little bit about you. What did you do before you joined Square, and then let's talk a little bit about your journey as you've been here. Dina Spitzer: We can start back in 2010. So 2010, I graduated with my degree in computer science. Was really interested in the startup world in the Bay Area, and so kind of always knew that I wanted to go from Champaign, Illinois, glamorous Champaign, Illinois to San Francisco. And so I found a startup willing to relocate me out to the Bay Area, joined them, was super excited. And then I saw firsthand how chaotic startups could be and how for a while, every single year I was shopping around for a new job. Either I was laid off or was about to get laid off or the company was kind of flatlining. And so when I joined Square back in 2013, they were my very large stable company and I think we were at about 600 people when I joined. So still pretty small. Pretty small. Different world. And yeah, I've been on three teams at Square. First team was around building internal tooling for risk management. Second team was the team management team. And so I got the opportunity to work on the Labor API, which is one of our public APIs on that team. And then I kind of got pulled into this world of APIs and I'm like, oh, there's a lot of improvements I want to make with our Square developer platform. And so after building Labor API, I moved over to the developer platform to one of the infrastructure teams to help actually improve the platform for internal developers to be able to build APIs at Square. Richard Moot: And that's basically why I joined. I mean I think it was like Carl Perry who almost seven years ago and sort of convinced me with joining this team because it was very much, at least the way that it was pitched was it's a little startup within a larger company. And so it was very exciting, lots of new things being built, trying to figure out a lot of things like taking an existing product and how do we create APIs for it. And the team that you were part of is very critical to making that possible, building out the framework that was going to allow people to be able to expose the different parts of the Square point of sale system to transform into APIs and allow people to build on top of it. In that time, so you joined as a software engineer and then you evolved over time to being a lead within your team, becoming an expert in what it is that you were working on. And then more recently in the past couple of years, you transitioned to an engineering manager. So I'd love to chat a little bit more what the evolution has been and how at what point it felt like this felt like more of the same and then the point where it goes, okay, this is totally different. Dina Spitzer: Yeah, sure. Great question. So I joined the team that I'm currently managing, I think five or six years ago as an IC, individual contributor software engineer. Just joined wanting to make the world a better place. And then I had a vision, had a drive, really studied our platform from the ground up. And I guess I can't say specifics about our internal tooling or internal infrastructure, but let's see, I identified some improvements I wanted to make to our internal architecture, internal infrastructure, got the team on board and we really started building in that direction. And then a little over two years ago, my manager departed the company and literally overnight asked, Hey, do you want my job? You have 24 hours to decide. Richard Moot: Oh my gosh Dina Spitzer: And I'd always been like, it was kind of crazy and I had just had a baby too. I'd been back for two months after coming back from maternity leave and I'm still catching up and I'm like, okay, let's do this. Let's just try out this whole engineering manager thing. Never looked back and it's been an adventure. Every day is a different adventure. It's a fun job. Yeah. Richard Moot: Yeah. I mean, one thing that is, I similarly had gone through that transition from being an IC to being a manager. Granted, I know that I have had a very different role. I don't do traditional software engineering. It's a blend of things. But one thing that really stuck with me in that transition of IC to EM or management is I remember something that Carl Perry said to me before he had left when I was really thinking about whether or not to go into management is the difference between leadership and management. And that it's very easy for us to start to believe that in order to be a leader, you need to be a manager. And I think it's a very common misconception that just because somebody's a manager doesn't necessarily mean that they're a leader and it's actually possible to be a leader while being an ic. I think that's why we've seen the growth of the tech lead as a job that has come up is that when you become an expert or you inspire others, you help others, you mentor others, but you're not necessarily a manager. I'm just curious how you've seen this difference when you've gone from being an IC to being an EM and what you sort of see as that difference between leadership and management. Dina Spitzer: Yeah, definitely. I definitely felt more of a leader as a tech lead than as an EM. I feel like a tech lead is very much, here's my technical vision, let's get the team on board and it's very much individual leader, let's go. But also let's take the team with us. While management, it was definitely a shift in mindset, I would say, because with management it's empowering others to lead and only really stepping in and using your voice as a leader when there are gaps and when it's needed. But ideally, you manage yourself out of a job. Ideally you empower those and delegate and have others on the team step up and really I guess use their own voice, empower them to become leaders. And often in one-on-ones, those people will express, they want to step into that leadership role or want to do that tech lead role. And so then you start finding work to actually enable them to step into that leadership role. So you're very much supporting and empowering people to lead rather than being like, I'm the leader. Here's my voice, this is what we're going to do. It's much more of a supportive role. Richard Moot: I think that you put that really well because one thing that I found particularly different about going from IC, at least in the initial phase, I know that there's this phase where some people will become a manager but then still have IC responsibilities. So you're doing that player coach type thing. But the thing that you touched on there that I think is really important to learn how to do is the delegation piece. And I found that to be particularly challenging at first because I think as an IC, you get so used to being able to just take on the work and complete it or figure out how it should be solved. And I think the part where I feel I felt the most growth in going into management was being able to actually hand something that I know that I could do really well, but giving it to somebody else to be like, no, I want them to do it because they're going to grow more as an individual when they do it, and I'm here to be that resource. So yeah, I just love the way that you started talking about the delegation piece, but it just felt like that's a thing that you don't really do as an ic, you're, you're not really delegating things. You're just like, yeah, I'm just going to go solve this, or I'm going to go talk to my manager and they're going to help me unblock me. One other thing I was just curious about in the mindset shift from IC work to EM work, I'm curious, how has your idea of what success in your role has changed? Because as an IC, it's like, Hey, I completed this work, or I created this design and implemented this or launched this product feature, but that's not, you're trying to do enable a whole team of people doing this, but you're not actually the one doing it. So I'm curious if you could talk a little bit about how that mindset shift has changed in terms of what you think of as success. Dina Spitzer: Yeah. I would say that there are two components. There's the internal management and then the external management. And you have to think about both and you can be successful or not successful in either of those areas. For example, internal management, it is successful when I empower someone to step into the leadership role and they step into that role and I can reward them, I can promote them based on that. I would say that's more like leadership and internal management, and that's a success story. External management success story would be like we redirected and pivoted to align the team with the direction of the company, and we're now able to help the company hit a specific milestone in working with product and so on. So it's how do we fit into the bigger picture? And both are very different and very different skill sets and both kind of invisible work as well. Richard Moot: Yeah, no, totally. I mean, one thing is because of this shift, it's like I don't know how often you might feel this way where you can end up having a day where here's the things that I wanted to accomplish today. And by the end of the day you might end up just going, I have no idea what I did. You suddenly just jump into meetings or you're addressing firefighting and you look back and you go, I feel like I didn't do absolutely anything, but you know, did something. But I don't know, it feels disconnected at times because trying to just sort of unblock things for people and once it's unblocked, you're not seeing the result of it. You're just seeing like, okay, somebody has an answer

    30 分鐘
  7. Building a Closed-Loop Wallet

    3月31日

    Building a Closed-Loop Wallet

    Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of developer relations at Square, and today I'm joined by Sophia Goldberg, who is the co-founder and CEO of Ansa. Sophia, would you be so kind as to give us a little intro about yourself and Ansa to let all of our listeners learn a little bit more about what it is that Ansa is and about you? Sophia Goldberg: Happy to, and thanks for having me, Richard. So I'm the, like Richard said, the co-founder CEO of Ansa. I've spent the better part of the last decade building in payments. So I was at a company called Adyen across commercial and product roles. I also wrote the book, the Field Guide to Global Payments to help anyone learn payments a bit better. And here at Ansa we're a stored value wallet as a service or closed loop payments infrastructure platform to let any brand or platform launch customer balances. So that can look like the Starbucks in app payment experience that can also look like the backend of transportation systems, microtransactions for gaming and everything and the like, but especially we've been building the last few years in the food and bev and retail space. Richard Moot: Very cool. And so you've built a lot of your integrations on Square and built a lot of this stuff for square sellers, but one thing I want to dig into with that is maybe tell us more about what is a closed loop wallet? Sophia Goldberg: Yeah, it's a niche part of payments infrastructure and the payments ecosystem, but a really important one. And so closed loop really just means where funds can be spent and so a wallet like the Starbucks wallet say, or for some of our brands that are on Square that we've built for closed loop means the customer adds prepaid funds. The brand can fund that wallet with incentives and those funds in that balance can only be spent with that brand. And so in turn, that helps drive retention frequency, really stickiness, but also on the brand side reduces cost of payments, drives cash flow, and can kind of become this really virtuous cycle of retention, loyalty and customer lifetime value. Richard Moot: Yeah, that makes a lot of sense. I mean one of the things that I know for particularly say coffee shops is you have these low ticket receipts and so it's actually in terms of percentage of fees that you're incurring on each sale is a little bit higher when looking at it marginally. So I'm guessing this helps mitigate that in many ways because you can then preload with these things and you're not incurring this on every single sale that coffee shops making. Sophia Goldberg: Exactly. And so for brands that have high frequency and lower average tickets, we call them Holt Merchants, HULT habitual use low transaction Value, which coffee shops or bakeries are a great example of if you have a $4 latte, which unfortunately in San Francisco I can't find a $4 latte anymore, that brand might effectively be paying up to 10% in fees because the fixed fees of every payment really add up. You're paying probably 20 to 50 cents no matter how large of a brand you are. And so by having a customer prepay into a balance and say, add $25 to spend over five coffees over the course of a month, that means you're only hitting those fees on that first time. You have the benefit of that float in the meantime. And you're also guaranteeing that I'm going to come back four more times, enjoy my coffee, and you're going to be saving about a dollar just on that one customer that month. Richard Moot: And so I'm curious, you've been in the payments space for a while now. What kind of really sparked that motivation towards building onset and building the solution? Sophia Goldberg: It started to come up earlier in the pandemic when I was seeing more and more different types of commerce trying to catch up and meet us where we were all stuck inside our homes and apartments and it kind of tapped into an observation I'd been having that commerce and payments have continued to diverge, especially in the US there's so many more different types of brands, merchants, customer experiences, we're using our phones even more, even in-store payments have an e-commerce experience or element whether you're maybe at say a kiosk or on your mobile phone. So all of the lines are blurring and I saw time and time again merchants not being able to actually support the customer experience they wanted because payments was often kind of the stick in the mud for them of what they could innovate and build and launch. And I'm a bit of a purist. I really love payments and I really love that our role is commerce enablement and that just didn't seem to make a lot of sense. And so actually in the early days we thought this was going to be a creator economy payment platform use case to enable online micro transactions, so think busking in the subway, but how you do that digitally, which is growing and happening all over the place and we couldn't find an infrastructure platform to really easily build that on. And so started pulling its strings and realized there's a big there there and for many types of brands, but especially in the restaurant area, cost of payments is often their second highest cost as a business. And so any way that we can help realign unit economics but have technology that really works inside their ecosystem was kind of the gap we found and where we started to build and grow. Richard Moot: So I'm curious even digging more granularly to day one, week one, month one, whatever it is, when you have this idea and you were first trying to test this out, give us a sense for how you got that zero to one moment and how did you start to grow from there? Sophia Goldberg: Yeah, so we knew from early on our technology was going to be very API focused. And we also knew that we starting out, my co-founder JT and I were two people at a WeWork in San Francisco. And so the companies that implement APIs don't typically buy from companies that are two people. And so we started thinking about the very famous adage do things that don't scale. How can we help brands that our product can be useful for but maybe don't have the resources or infrastructure today to otherwise work with us? And so actually our first customer that went live is a square customer out of the East Bay who I mean phenomenal coffee, really awesome team, really great brand and really forward thinkers on experimenting. They care a lot about brand and their customers and their customer experience. And so we did the thing that didn't scale and we thought, okay, well if they would like to use our product and we would love to work with this team locally, what if we just do something crazy and build them and order a head app, which was not and isn't really our core business, but thanks to actually the Square Docs, we were able to build and order a head app that existed fully on top of their square stack. And I don't even think we had to talk to your team until quite a ways into the project and the build and we were able to build it in a way that they didn't have additional lift or process because it lived alongside their entire ecosystem, which for them obviously is Square. And for us it meant we had this piece of software and this really great early design partner to be able to test and iterate with. Richard Moot: That's great. And so I'm curious on the part, what part of that felt the most not scalable? Was it just that you're building this sort of bespoke app for one customer and then trying to figure out what you learned along the way? Sophia Goldberg: It definitely was. The initial impetus was, or the concern was we don't want to be this turn into a dev shop, which I think every or at stage software company, there's a fine line between building custom for your design partners because you need them to have a reason to take a risk and the fine line of what are we building that's scalable and can be used by a dozen, a hundred other brands like them. And so that was kind of a constant push me, pull you, but what we ended up learning I think was so valuable because if we had had a first customer who owned their entire app and use our APIs and docs and just ask some questions, we wouldn't have the same understanding of what that stack looks like for a brand. Those considerations are sometimes we call it, we can say it's really easy to integrate us, but we only know the iceberg above the water. We got such a great insight into what's below the water for a brand or a coffee brand of, I didn't know the acronym KDS kitchen display system and how all of those data elements flow and all of those learnings have compounded to help us grow with both other square brands or brands on Square, but also throughout the ecosystem and larger brands with more patchworked stacks. Richard Moot: Yeah, no, I mean it makes so much sense. I can definitely vouch for, I mean granted, I know that I probably have a different perspective doing developer relations here. I spent the first year not knowing what QS R meant and I thought this was just some sort of FinTech term that I'm familiar with. It's in digging into a real business and sort of getting your hands dirty with them, you really start to see the things that they're actually concerned with. I know here at Square we're very much about trying to get out of a business's way. They don't want the payments to be slowing them down or being front and center for the customer interactions. They should fade into the background and allow them to just run their business and save them time. But one of the things that I think because you say order ahead and the most eyeopening thing that I've even found with people who are having an Order ahead farm when they're trying to manage Uber Eats, DoorDash, Postmates, and seeing the tablet farms that they used to have in the back where somebody's just sitting there pressing buttons and trying to feed tickets and be like, oh yeah, accept orders everywhere. And th

    37 分鐘
  8. Scaling a Pop-Up Business to 120 Franchises

    3月24日

    Scaling a Pop-Up Business to 120 Franchises

    Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, and today I'm joined by Rhea Lana. I want to thank you all for being here today. I really, really appreciate you taking the time. If you wouldn't mind going ahead and giving quick little intros to tell us who you all are. Rhea Lana: Hi, Richard. I'm Rhea Lana and I'm the founder and also the current CEO. Erin Franklin: I am Erin Franklin. I am the CFO for Rhea Lana's, and I am also a franchise owner. Dave: And I'm Dave. I help Rhea Lana with technology. Richard Moot: Well, thank you so much. Rhea Lana, would you be so kind, tell us the story about what is Rhea Lana, give us the story of how this all started and bring us if possible to where we are today. Rhea Lana: Sure. Well, we host children's consignment events, and so families bring their gently used children's things and we sell them for them. And so it started when I was a stay-at-home mom actually in the early nineties. We had made a move from the corporate world and Dave was doing nonprofit work. And so I was a stay-at-home mom on a really tight budget. I loved cute kid’s clothes, but it was just hard to find good deals in a really high quality atmosphere. So the goal then, Richard, was not to build a business. I really was just doing this little thing for my friends. And so I invited moms to, and we did our first sale in my little living room. We moved the furniture out of the living room into our bedroom, and we had three racks of clothes and 11 consignors. A consignor is a mom who's selling her kids things. And so that was our very first sale in 1997. So that's how it started. Richard Moot: After the starting of that, what made you want to turn this into a full blown business? Rhea Lana: Well, after that very first sale, Dave actually is the one that said, Rhea Lana, we should computerize this. Well, back in the early nineties, stay-at-home moms didn't have computers in there. I didn't even know a mom who had a computer in their house, but we did. We computerized it and we said we had barcodes. And the interesting thing is that families just kept asking me to do it again and again and again. And so the model is just two times a year. And so for those first several years, we would have these little sales in my house and they would take over another room of the house and my daughter's room and the kitchen and the garage. And then finally we moved out of our house and we began to hold these events in locations around our little town in central Arkansas. And then we had families that were driving in from Little Rock, Arkansas, which is about an hour away. And I began to realize families love this, they appreciate it. It's helping them not only be able to buy high quality clothes, but sell things their families didn't need anymore. And it gradually was making a profit more and more. And so we began to realize, oh, this is something that could be a business. Richard Moot: That's awesome. And so where are we today with the size of Rhea Lana? Rhea Lana: Well, in, let's see, it was about 2008, I think. That's right. We decided we would franchise and we still were on a very limited budget. And so we knew that if we tried, it didn't have much to lose. We couldn't risk a lot is what I was going to say. We didn't have the money to hire some big fancy firm to help us, some consulting agency. We just thought, well, we'll just franchise it. I actually read the book Franchising for Dummies. That's not a joke. I did. And while my kids were swimming at the pool, I would check the things off and do the things. And thankfully I had a friend who was a really smart tax attorney, and so he helped me put our contracts together and then we just decided to see if anybody would buy a franchise. And so that's how we started our franchising company. And so today we have about 120 locations in about 26 states across the country, and we've served, now millions of families. And our heart is we love serving families and we love just adding value to lives to families across the country. Richard Moot: Wow, that's awesome. And so to hopefully give also how this all works, so you have 120 franchisees or franchises all throughout the United States, and this is an event based thing, right? There's two annual events. Tell me a little bit about how these events get set up and how big are they? Rhea Lana: Well, I'll start and then I'll let Erin share because she owns one of our early franchises, and I still own and operate our franchise in central Arkansas. But you're right, the model is that we hold semi-annual events. So we just do 'em twice a year. And when the franchisees start, they're like a baby, but they grow into these huge sales. And so we will fill up large like a Walmart or larger, and we will have several thousand families bring their things, but we just set it up, we take items in for about a week, and then we sell items for about a week. And so it's kind of a pop-up event, but it is all just run at such a high quality of excellence because we do have incredible technology. From our very first event, I always had a desire that we would guarantee items just from experiences I'd had and consignment stores and other things. I just felt like we needed to track where every item went. And so even in the very first sales in my home, we would hand our consignors a computerized report that told them exactly what sold and for how much we wanted them to be able to trust us. But Erin, again, was one of our early franchises. Erin, you should share about your event. Erin Franklin: Yeah, I'm in the Kansas City market, and so we didn't have Rhea Lana's until 2010. That's when I bought, there was another franchise kind of next to us that bought about the same time. And so we had competitors in the Kansas City market, but Rhea Lana’s was just so different. We set it up more like a boutique store rather than these long rows of clothes. It was set up pretty and colorful and we decorated and you just kind of made it feel like a store. And, just, I don't know. It really set us apart in the market, in our territory. So you do, you start out small, so you see now these pictures of even my event today, but really Rhea Lana's event in central Arkansas, you see these pictures of this massive space and all these items, but really in the beginning you start out and you have your little seven or eight racks and it just grows because these families, in the beginning, I might've had 50 families that can sign with me. I have well over a thousand now. And so just these families see the value in selling these items that are in great shape, but their kids no longer use. And so really the model itself is just such a benefit to the community and to the shoppers. We will have thousands and thousands of shoppers come through the door in the matter of one week. And so what brick and mortar stores tend to see in months we see in a week. And so just really the event aspect of it is really just so beneficial for the community. And so doing it twice a year, you get that spring summer event, and so you get all the swimsuits and all the tank tops, and then you do more. I do more of a back to school fall event, and so then you can get that colder weather, warmer attire kind of aspect. So yeah, Richard Moot: It's very interesting to sort of hear how it initially starts out, as you would expect with most businesses, whether it's a franchise or not, is that it's going to start out a little bit smaller and then it grows from there. So one thing I just imagine is it's very important to be able to to grow as you're growing, that you're able to scale with that growth. So I imagine that you might start off with only a few point of sales, and then as you're having thousands of people coming through, you're like, oh my gosh, now we need to have so many of them. Tell me a little bit about how it is when these events get really, really big. I mean, you were sort of giving this visual of filling up an entire Walmart almost. What does that look like on the event day? Erin Franklin: Yeah, for my event, I am now in an old Marshalls and home goods space, so it's about 55,000 square feet and we max it out. We use every square inch. And so we went, our first event, we had one computer, one point of sale, and now we run 15 plus point of sales and Square Terminals and all the things, but it is just massively full and Rhea Lana let her speak, but I mean her event has gotten to the size where she's outgrown the entire expo center in her town and uses the whole outside. And so you can speak more to that. Rhea Lana: We do actually, we have, we've moved outside. It is, it's kind of a covered area, but I have a really amazing team and we serve whether it rains or shines or snows. So that's what we do. But we also have many point of sales, like Erin said, I think, I don't know, we have about 20 now. Our goal is to give an excellent shopping experience. We don't want people to stand in line for a long time. And so we just are always thinking through what's the experience of the consignor, the families that are selling their things, and then what's the experience of the shopper? And we want it, like Erin said, we want it to be visually beautiful like a department store, but we want to make it easy to shop. So families have shopping carts to put all their things in, and we have this special big ticket item pickup because not only do we sell clothes, but we sell big toys and baby gear and furniture. And so we just have this system where they can just have a little claim ticket and they pull around the back and we've got these strong men that load the things up. So again, it really is all because we have a wonderful technology that we've been able to operate at such excellence, and we're always trying to improve that, and we really have enjoyed our partnership with Square. It's made our checkout process go even faster. We've gained even more respect from ou

    41 分鐘
顯示全部 (13)

預告片

簡介

The Square Developer Podcast dives deep into the backend of a business. Hear discussions about tech that fuels commerce innovation with folks who have built apps, integrations, businesses, and more on the Square developer platform. In each episode, we’ll chat with a dev about their real-life experience using Square tools — the good, the bad, and the buggy are all fair game as we go behind the build. Together, we’ll talk about the tech world at large, and how it influences their decisions or drives their ideas forward.

資訊

  • 創作者
    Square
  • 活躍年代
    2025年
  • 集數
    13
  • 年齡分級
    兒少適宜
  • 版權
    © 2024 The Square Developer Podcast
  • 節目網站
    The Square Developer Podcast