The Square Developer Podcast

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

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 requ

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: YesRichard Moot: WowBinh 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 tha

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 we

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 teamsRichard 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 j

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 goshDina 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 ac

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 ea

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

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 Ryan from Payable. Thank you so much for being here. Ryan, could you go ahead and just give us an intro of yourself and tell us a little bit about Payable?Ryan May: Yeah, for sure. Thanks for having us. So Payable Apps has been a Square partner for probably about three or four years now. We got started by making connections with Google applications, so everybody knows Google Forms and Google Sheets and how easy they are to use. And what we did is we made a payment connection for Google Forms and Google Sheets so you could connect them to a payment provider like Square, and then as while you're creating a Google form for somebody to fill out, whether it's a t-shirt signup or a membership or an order form, it can also take payment right inside that Google form for you and keep small businesses organized inside the software.Richard Moot: I've always really loved the idea of what you guys have built because it's taking something that is really simple and ubiquitous with a lot of small businesses and then allowing them to make sales using that make, it's really meeting them where they are and with something that they're familiar with.Ryan May: Yeah, I agree. Micro sellers are huge. There are so many of them out there. Almost everybody has a side hustle or they're doing something to try to turn their passion into a business, and they're all using free tools. They want to use free tools as much as they can. And so our goal was to take some of those free tools like the Google Suite, which has some handicap, some lack of advanced features, and try to just build it out just enough so that it is good enough for somebody who's doing five orders a day, 25 orders a day, until they grow that business into something more serious. It actually is a really good solution for them.Richard Moot: Yeah. So I'm curious, where did the inspiration from this originally come from?Ryan May: Yeah, I mean it as actually my co-founder real world situation, it was during COD, her boss tasked her with this task of saying, Hey, I need you to go around the office and get everybody's t-shirt size for this event, and you have to collect $20 from every one of them for this team outing event. So she was like, okay, well no worries. I'll use a Google form and I'll get your name and whether you're going to attend and if you have any allergies, what your food preference is, and ask for your t-shirt size. And she was like, why can't a Google form also just ask for $20? Because it became a nightmare. She had to get, some people were paying her with e-transfer, some people were bringing cash to her desk. It was all over the place and it was up to her to manage this collection of funds.And she goes to me, my background is in payments. She's like, well, Ryan, why can't we do this? Why can't a Google form also just have a pay with credit card button attached to the end of it? And I was like, there's all these PCI compliance and all these rules and it's not extendable in that way. And I was like, yeah, it's just not possible. But I sat there thinking about it a little bit one night and I was like, you know what? I think I looked at Google's developer docs and how you could extend it. And I thought if you were a little bit creative, you might be able to tack on an extra page and collect payment and do this in line to make it look very native and secure with the payment providers like Square or Stripe or PayPal. So we started with PayPal and we launched it and I said, well, if I'm going to build it for you, I might as well build it for everyone. Why build code once? So if I'm going to build this little solution for you, we might as well build it together.So that was the idea. And yeah, that was our first app called Payable Google Forms. And since then it's been downloaded over, we now have a hundred thousand different active small businesses who use it on a given month, and it's one of the more popular Google form payment and accounting add-ons that exist in the marketplace today, so it really has grown. It hits that one simple problem where people really know how to set up a Google form. Almost everybody has done it, and they just add Payable options inside of it. And it's live and easy for them, especially for things that are one-offs. Like we think about life and there are people who are creating a business and they want to have, I'm opening a t-shirt shop and I'm going to sell t-shirts all day every day. But for people who are tasked with these rare or seasonal or occasional projects, something like a Payable Google form is a really good way to set something up and go live quickly.Richard Moot: Yeah, no, I mean, it makes perfect sense. I mean, there's an interesting kind of parallel between, in that same Micro seller space that we used to see initially with Square was you go to a farmer's market

Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of Developer Relations at Square, and today I'm joined with Alex Hancock and Watson from Apollo. Feel free to just go ahead and give us a quick little intro. Tell us about yourselves, what is it that you work on? And let's start with Alex.Alex Hancock: Sure. Thanks for having me. I'm really excited to join this chat and talk with you guys today about all things GraphQL. I'm a Software Engineer here at Block. I've worked at Block for eight and a half years, and I most recently spent four years working on the GraphQL platform at Block.Michael Watson: So my name's Michael Watson, I'm head of Dev Rel at Apollo. I've been there for about seven years now, and I really just work on GraphQL projects and kind of everything GraphQL. So I'm really excited here to talk more about GraphQL because I have a big passion and I'm obsessed with GraphQL, so this is fun.Richard Moot: Awesome. I'm so glad to have you both here because we started on GraphQL here at, well, it was called Square at the time, but at Block for quite a while. It's been over five years I think. I mean, I feel like Alex could maybe keep me a little bit honest here. I just remember sitting in a round table with folks from Apollo and Strava and a bunch of others where we're just trying to figure out how should we build this and move forward. And so yeah, it's used pretty extensively here in some ways that we can talk about some ways that we can't talk about. But yeah, I think one thing I'd just like to kick things off with is talking about public GraphQL APIs and growing the adoption of those. I think that both of you have interesting ways of assessing that and looking at that. So I mean, either one of you want to tell us a little bit about public GraphQL APIs.Michael Watson: Yeah, GraphQL has been around for a long time and I think public GraphQL APIs is something that's been on the rise. There was a lot of early adopters, I think of Shopify, GitHub's V4 GraphQL API, and the thing that I really love about it, if you look at the world before GraphQL APIs in the public space, you had your REST APIs, let's say even Square’s documentation of their REST API. There's a lot of great information in there, but as a developer that's coming to maybe a developer portal starting up with that API, they really have to start understanding of what are the domain entities I need to get into? And then there's always the orchestration problem like, okay, I got this one thing, now I need to make a second API call to go get this other thing. And that's kind of some of the magic that GraphQL provides is as a developer, I'm no longer thinking of these different endpoints that I'm getting and how I'm orchestrating them together, although that provides a lot of flexibility, but really sometimes I just want to add a couple extra fields into the request I'm making and just get that information and I don't have to think about what are the details.And the magic sauce that I've seen in public Graph APIs that's really successful is this magic button that you click into the docs and it just logs you into that thing and then you could just start exploring and running GraphQL operations and seeing that right away instead of downloading a Postman collection. So I'm a big fan of that experience for developers just to explore to get up and building faster.Richard Moot: Yeah, I couldn't agree more. I mean, one of the things that I work a lot on our REST APIs and I've been doing that for quite a while. One thing that always feels like a huge unlock for GraphQL over REST, not like we have to pit them against each other, but REST is really great about understanding the semantics of what are resources, what a resource might be doing given certain things. But the biggest missing piece that GraphQL does really well on is giving you the relationship between these entities and these resources. And it's just completely evident as you start navigating it. Like, oh, an order works with a customer or works with a payment and works with items because I see this directly in here. Instead of having to go and like, okay, I see the resource, now I have to dig through all the docs to figure out what do I use this with? So yeah, it's very, very great to see in that way.Alex Hancock: Yeah, I would add I agree with all of that. I would add I think the most useful parts of GraphQL to me when thinking about public APIs are some of the most basic features of GraphQL, like field selection, just basic solving the basic problems of either under or over fetching of data depending on the client's needs. I think in the era of public APIs before GraphQL, you saw a lot of times some of those janky kind of custom built or half-baked ideas of adding field lists or something like that to REST API. And I think that how prevalent those were in public APIs speaks to the need for customization at the public API layer that GraphQL just

Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, and today I'm joined by Miles from DH Pace. Thank you so much for being here. Miles, can you give us a quick little intro and tell us about yourself and DH Pace?Miles Rush: Thank you, Richard. My name is Miles. I've been a software developer for over 20 years now and I've been working at DH Pace almost that entire time, developing lots of different projects and mostly focused in the mobile space. So for our field team doing field service and sales, DH PACE is a door company, so if it has a door, we work on it pretty much. So your garage doors, the doors to the front of your building, dock doors, if you walk through it, we touch it type stuff. And so we have a nationwide service and sales team and my job is to help them be more efficient and get their work done.Richard Moot: Awesome. And for those that aren't familiar with say the size of DH Pace, how large are we talking, and I'm assuming it's predominantly in the United States,Miles Rush: Correct.Richard Moot: But how many locations, what is the total reach of DH Pace?Miles Rush: I think, last time I saw, we were around 50 locations nationwide. We have probably 3,500 employees and about half of those are field employees.Richard Moot: And so you have worked on building the integration with Square for DH Pace. Before we talk about that actual integration, I'd love to paint a picture of what it looks like when somebody is interacting with DH Pace. You mentioned the field service technicians. What is the typical life cycle of somebody who's either buying a door or repairing a door? Tell me a little bit about that.Miles Rush: Absolutely. So one of probably our primary use case is residential service. You have a garage door and spring breaks or it just doesn't open or something like that. And so you call us up, Hey, I need this fixed. So our office staff will create the order, dispatch it to our field tech, and they come to your house and start using their mobile device to record what they're doing and see, oh, I need to, this is what's broken, here's the parts I need to fix it. They'll record those parts, record the time. And then as far as customer interaction goes, once they've completed the work, we'll have the customer sign off on what they did and then take payment right there in the field where they can use their credit card and take the payment and then we're out of your hair and moving along.Richard Moot: It sounds like you have a custom built system for actually handling this sort of interaction. I've had work done at my house before and mostly the other times somebody comes in, they do a quote, then they have to schedule somebody else to actually come out and then go and do all of the work. And then most of the time I get an invoice or I have to go write a check to them. But this kind of solves that, hey, we have a payment device right here. It's logging everything. We know exactly what was changed, what work was done. You can display this is how much you're being charged and then pay it right then and there.Miles Rush: Absolutely, yeah, so we have all of our pricing and everything sent down to the field on their phones and tablets that they use and they can invoice the customer right then and there and using the Square device makes it real easy for the customer to pay and for us to collect from them.Richard Moot: Tell me a little bit about the devices that you're using for doing this kind of payment integration or really for that interaction. You said that mobile devices, tablets, what do those actually look like?Miles Rush : Yeah, so our field team primarily uses Samsung devices. We're using Samsung phones and tablets for our field. Depending on whether they need a larger screen or not, we'll use a tablet. And as far as for Square, we're using the Square readers that connect via Bluetooth and they make it real easy to get those synced up and they'll just pull it out of their tool bag when they need to take a payment.Richard Moot: That makes it so easy. And previously you were integrated with a different payment provider, like you were using something before you actually started using Square. Tell me a little bit about what sort of things you were dealing with prior to that in terms of the technical issues and then some of the more logistical business issues.Miles Rush : Absolutely. Before this we were integrated with a provider that did not have any hardware. They only had a web API interface, and so we had to send all of our payment information through a web API to them. They would process the card and send it back. And while it worked, it wasn't ideal. It put us into the space where we were PCI had to take care of the PCI compliance because we were handling card information and then also was a poor customer experience. We were typing in their card number into our device and customers, a lot of our customers would get nervous seeing you type in their card

Richard Moot: 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 Adam and Cesar from MonStar Lab. Can you both give us a quick intro and tell us a little bit about yourselves and MonStar Lab?Adam Mack: Thanks so much for having us, Richard. Really appreciate it. My name's Adam Mack and I am the director of Technical Product Management here at MonStar Lab in North America.Cesar Aguilar: My name is Cesar Aguilar and I'm an engineer director here at Monster Lab based on New York.Adam Mack: MonStar Lab is a New York and Tokyo based technology partner, and we have a staff of over 800 engineers, designers, and product managers all around the globe helping our clients in all manner or different industries to solve complex technology and business challenges. And what we end up doing at the end of the day is building human-centered software that delivers results for our clients. That covers a huge range of activities. We build consumer apps and consumer app experiences. We help design process automation and new operational workflows for different businesses. We help educate brands and internal teams about responsible use of ai and we help technology teams select the right vendors and partners to work with. At the end of the day, all of it comes down to overcoming complex technical challenges, but without ever forgetting that there's a human end user at the other end of the experience. So we try to ensure that we're balancing technology choices and making cool stuff with always doing what's best for our users. And part of that is a huge focus on payments and payment integrations. We recognize payments as one of the foundational drivers of a good customer experience in a lot of cases, and it's obviously a core driver for platform businesses all around the world. So it's a little snapshot of what Monster Lab does.Richard Moot: You've been building and integrating stuff on Square for quite a while. I'd love for you both to just talk a little bit about one of the first big integrations that you've built with Square.Adam Mack: Yeah, so we have a long history with Square, going back to very, I guess you would call them simple payment integrations. Many, many years ago, going back to the beginning of Square's, APIs and SDKs, we had a long working relationship with Shake Shack and we helped to build out the majority of their online ordering infrastructure, including their consumer ordering apps for iOS and Android web ordering. And in 2017 they approached us with this interesting challenge of let's take the really great experience that we've been offering in our consumer mobile apps that really polished ordering brand first experience, and let's bring that to a new form factor with kiosks. And the destination was going to be a sort of, I guess you could call it an experimental digital first location, starting to experiment with different form factors for the brand. So we were charged with helping to bridge this user experience that we built for iOS and Android into a new form factor and a huge part of that, a huge challenge aspect of that was integrating Cart present payment, which was a new challenge for the brand. So we looked at so many different providers to handle our card, present payments for the Shake Shack kiosk and Square ended up being the partner that we worked with and Square helped us and helped our engineering team to really rapidly prototype design and prototype a solution that met all of the user needs, met all of the security needs, met all of the operational and business needs that Shake Shack was putting in front of us and doing it incredibly quickly.Richard Moot: So one of the things I've always been curious about when trying to build for these in-person type experiences compared to say, online, mobile, web, what were some of the more interesting things that people might not think about when building that in-person type experience? Because I remember that app does a really great job of walking you through a checkout flow but also displaying certain things where it feels very different than if you're just sitting in front of a person and just saying, oh, I'm just going to start reading off of this menu. You have a little bit more of a guided experience on this. So I'm just curious, what are the things that you'd say were the most interesting problems to solve or things that you wouldn't really consider compared to doing an e-commerce type build?Adam Mack: Sure. So what's really interesting about kiosks is in a lot of cases they are designed to alleviate the burden on operational labor or increased throughput in a lot of cases. For Shake Shack, that was absolutely an operational goal. I think everyone who has spent any time in New York and knows the brand, knows the long curling line around Madison Park for the OG location, so that was line busting is not quite the right term, but expediting the customer flow through the

Adam Stacoviak: Well friends, we're here episode zero of the Square Dev Podcast. My name is Adams Stacoviak and I run Change Log, and I'm here with Richard Moot, head of Dev Rel for Square. Richard, how are you?Richard Moot: I'm good. I'm so glad that you decided to help us out here in getting this episode zero of the Square Developer Podcast, getting everybody introduced to what it is that we're trying to do here.Adam Stacoviak: Yeah, I love the platform. I love working with you guys. Amazing team, big fan, many, many years, big fan. And I'm even excited about the podcast, believe it or not, and behind the scenes we're helping you produce it, helping you with some of the editorial processes and just making an amazing podcast, which is really, really hard. As you may know, Richard, it's not easy to deliver a world-class podcast, but here we are. We're doing it.Richard Moot: Well. I mean, when we thought that we wanted to do a podcast, there's nobody else that we wanted to partner with. I mean, you convinced us in all the years that we've been chatting with you, listening to the podcasts, definitely inspired to be able to come here and work with you and then ultimately tell the stories that we want to be able to tell, to get developers excited about our platform, understand what's possible, and really just showcase all the different use cases that people can have when it comes to Square and everything that makes it great to build on this platform.Adam Stacoviak: Yeah, I think even in Episode Zero should be more common for new podcasts because I feel like if you just start launching shows somewhere in there, you have to explain who you are, what you do, why you care, what they can expect. There's some sort of promise that a podcast delivers, and that's my hope today was just to sit down with you and talk through what is this podcast going to be about? Who will you feature? Where will it live on the internet? Do you even know these questions yet? I know as you begin something new, there's things that you iterate towards. You don't always have all the details figured out, so what can we answer about who you'll feature and what this podcast will be about?Richard Moot: I really want people to understand why they want to listen to this podcast, what they're going to be tuning into. We're really going to showcase some of our largest developers, some of our smaller developers. We have one person who actually won one of our hackathons, Bihn Ly, who builds the Operator app. It's a very interesting use case, allows SMS texting from landlines. It's something that has become more common, but I don't think we all really think about all too much.And the interesting way is that this can make a business run better, especially if you're a solo business owner and the phone's ringing, but you're working with a client. They have ways of solving how to get business retention and get in touch with folks. And then we also talk to a different hackathon, one of ours payable with Ryan May, and they have a really interesting use case of integrating with Google Cloud and Google Business Suite and allowing you to just take a payment from a Google form.It's so simple, but so useful and powerful because a lot of people use Google Suite for small businesses for doing their email and all that management. Sometimes they're just like, Hey, I want to be able to collect some info at an event and then have them pay for it right then and there. And it all started from really small things where you just had a group event where everybody was supposed to pay 20 bucks for a T-shirt and they had to fill out a form, and just thought, why can't we just take the payment at the end of the form? Why do we have to gather all this info and then later go, Hey, did you get the 20 bucks from each person? So it's just really simple. Things sometimes can be really powerful and unlock entire businesses.Adam Stacoviak: So developer stories of course is always fun. Will you be featuring some of the inside of the developer podcast at Square, like the API the GraphQL stuff you're doing a lot of the innovation you're doing to enable merchants to be faster, better, stronger, all the things.Richard Moot: Yeah, you're totally right. So we ended up also having the folks from Apollo GraphQL join us for the podcast and talk to one of the engineers that actually built our internal GraphQL endpoints that ultimately enabled us to publish the public version of the Square GraphQL Endpoints. And just really trying to talk about all the different things that we've leveraged of federated schemas, and we even start talking about the future of GraphQL as they're trying to solidify new standards and really trying to build a whole new community around this to get GraphQL to the same level of rest in terms of design standardsAdam Stacoviak: When it comes to the developers that should listen to this podcast, I know that I kind of have an idea who that might be, but do you expect the audien