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 know, I think I've mostly been in the realm of, like, I've worked for some company and like, I kind of just build software based on, like, their usual process.

And I want to sort of understand, like how you approach this because you don't just like, sort of like build apps, like there's a whole experience that you have to sort of walk people through, like what is the actual business need, what are all like the different metrics? I'd love to sort of paint a picture for listeners and like what agency kind of development looks like.

So, like, maybe we can start from, like, you have an inbound inquiry come in and you're sort of fielding a request, like what sort of happens from there as you work with the client?

David Foote:  So, usually we arrange for a half hour meeting, you know, a video conference meeting just to get a better picture of what their unmet need is what we're trying to accomplish. And, depending on kind of where they're at, what their experience in the software life cycle is, we might recommend that they come in for like a, a free three hour consultation where we, where we kind of build out a more complete definition of the product that they're hoping to build.

Or if, if they're very, very early or very new to, to software, we might recommend, a little bit longer of a workshop where they come in and really get, get situated and we can really help them develop, an intuition and a, an overall sense of what it's like to build software. So that might take, you know, we might do a few hours each day for, for three days in a, in a week span in that case. But often we can get somewhere where we're ready to talk about dates and schedules and numbers, in that first three hour workshop.

Richard Moot: Okay. So, like in the case of, like this mobile app where you have, like, both an in-person like or, sorry, like, a consumer app and then like sort of an in-store experience, is that something that was like sort of known ahead of time as I was sort of like found through discovery and like trying to figure out, like what it is that they were ultimately solving for.

Like, I love to like, sort of understand, like how you sort of like, the best way that I put this, like, when I, like, talk to people in my, my community, is like, sometimes I'm having to sort of, like, pull the, the actual problem out of, like, okay, like, what is it? It's like we're really trying to drive towards here.

Like we don't want to have like, really long lines. So you're like, okay, like maybe we want to have a sort of kiosk, like I'm sort of understanding, like was this something that was maybe known ahead of time or is like found through the discovery process?

Arielle Watson: Yeah. If I remember, I think Kyle came to us knowing he wanted to do a kiosk app in store.

David Foote: And in it definitely, you know, not having or giving people a shot, you know, to avoid the line was definitely a big motivator for that. Because it is an attended the concept is an attended sort of assembly there in the store where they can say, oh, I want some of that, and I want some of that. Like my pizza. I'd like Chipotle. Although my pizza's a bad example. They're kind of disappearing.

Richard Moot: I do love my pizza. It is too.

David Foote: I like them too, you know.

Richard Moot: Because like, I'm always curious. Also, like in the, approach to like user experience between the two of them. And I always have this, like, running theory. I'm maybe validating myself by, like, asking this in different contexts on the podcast. But, one thing I sort of learned was that, like, but it was very different to me, like, say, building an in-person experience versus a consumer experience.

Is it in-person? I do feel like a user has maybe like a lower tolerance for waiting on things or load times or like any kind of delays. Whereas like, you know, you would maybe even in a mobile app you might have something slightly more tolerant, like, oh, like it took a little bit like to fetch this data and like rendered in a view.

And so I'm just kind of, curious, like what are sort of like the little nuggets of things that you sort of had to sort of change when approaching for, like an in-store experience versus the consumer one.

Arielle Watson: I would say we really had to optimize for simplicity and efficiency, because it may be their first time using the kiosk, it may be their first time using any kiosk. And a lot of the kiosk experiences that are out there are really hard to use. So really, we tried to pare down what the user needed to do in order to create an order, even to like where they're entering their name. You know, we just wanted to remove as many roadblocks as possible for them.

Richard Moot: And like, are there like sort of in the, in person experience, I guess, like there is like always like a little bit of, like the record of like, oh, I can go because it's intended. So like you could be like, hey, I'm, I'm running into the issue that they can at least have somebody at the store there to hopefully help them in troubleshooting it.

If they did run into an issue. Do you have you found like having to implement any kind of like ask for help within there where they can sort of just say like I got stuck or is it kind of like just sort of a they hopefully just back themselves out and start over again.

David Foote: We're not open yet. So we haven't had a lot of user feedback for that kind of thing. And I know it's not clear to me yet what the staffing situation would be like for there would be somebody available to come out and help with the kiosk or not. So I guess we'll figure that out.

Richard Moot: Yeah. Because I've seen a lot of, like, some other people have built in store experiences. And I mean, I don't want to like, tell like the, the power of, of our platform or tools. I think we actually just get lucky that we have good developers building intuitive apps, on our stuff. But it's more often that like, they've just sort of had a way of resetting back at the beginning again.

The only other thing I've sort of heard is from when trying to sort of troubleshoot, I said, like the, a common thing that might that has happened for some folks is, wait a minute, why is mitigating this is like, you know, that for an employee to like, get trained on, like say, how do I reset the the kiosk?

That's actually fairly intuitive and not requiring a huge amount of training because, we provide some stuff on like, hey, pear, the reader does this and then it's, it's good to go. But I have heard that like that's like the only other thing that likes tends to need consideration. When, when rolling this out, the only other one I thought was like, accessibility.

I wonder, like, is that something that, like, is something that you're thinking about for the initial version of this app or something that's considered like an important requirement? Upfront.

Arielle Watson: I would say, one thing that we're kind of always keeping in mind is trying to kind of have multiple cues. So it's not just color, you know, we're trying to use different, different shapes or things like that. So in that sense, I would say it's part of this first version, but anything beyond that, we're definitely interested in.

Richard Moot: So for the consumer side of the app, that's mostly to sort of understand like the use case, it's like that's like for like I want to order ahead, maybe curious like is there also going to be a delivery component or is it primarily for like, oh, I want to order online.

Arielle Watson: Yeah. So there's going to be a delivery component. And actually the integration with DoorDash, this Square just kind of upgraded was perfect timing for us. Excellent. So yeah, they'll be doing their delivery option, their pickup option. And then they also can save favorites. They can track their loyalty progress. And then the group ordering is another big one.

Richard Moot: And then, kind of changing gears a little bit, I'm curious, like, as you're, you know, I know that like, success might be defined as like, hey, you know, we've found, like the right use case, we've landed the client, you've got the work done, we deliver. What does it look like in terms of like, defining success metrics?

Like once something is like live and running, and like to what extent do you like, sort of like, continue on in, like maintaining those things? Or is it usually that you would sort of build like an off boarding plan to be like, here's how you can sort of take on maintaining this for your, for you and your, your team going forward.

David Foote: So with a, a concept and a company is new is bold. I don't think it would be wise for them to take on the burden of software development, maintenance for some time to come. So, you know, when, when they've gotten big enough that it makes sense to staff that internally, then we'll help them. We'll try to help them transfer that to internal staff. But I wouldn't see that happening for a couple of years yet.

Richard Moot: And so like, do you usually sort of. Well, I'm sure it probably works both ways, but do you have a preferred hosting platform that you sort of generally like to build your stuff on, or is it usually just more determined by the client? Hey, I'm sure that some might be more opinionated. Some might be like, yeah, we don't have, we don't really care as long as the backend works.

David Foote:  Yeah, usually we're the ones that are recommending, a fairly strong recommendation because we've got, you know, our own routines and reflexes, you know, set up to, to work with certain platforms. Historically, we've been very likely to deploy on Heroku. But more and more, AWS is sort of our default. So in this case, we're using the AWS landers and gateway and probably a couple other things.

Richard Moot: Now, one thing I do want to touch on, since you mentioned it, and it's like a fun hot topic and a new personal interest of my own is, you know, working on AI, incorporating AI. I'm just curious, like, how much is it like sort of incorporating or building this for client projects? How much are you actually incorporating it into your own development flows or creative process?

David Foote: Well, if they took away ChatGPT tomorrow, we'd be helpless, I feel. Yeah, there, work. Yeah. And we're shifting more and more to Claude for actual coding, for generating code. But, we use ChatGPT for more general questions and, yeah, we use it every day. All day. It makes things possible that before we would have had to, you know, build expertise over several months to tackle, we've got one client that we're doing that we're doing really intricate camera work on, on the iPhone.

And that's that's fairly rarefied, you know, that expertise. But, you know, the AI is just helping us just tackle it and not have to be scared. Awesome.

Arielle Watson: Yeah. We found it to be really powerful. And as long as you can architect your prompts in a way to get what you need. And then I think David kind of alluded to it earlier, but we've found that, like ChatGPT, has been great for kind of our general questions. But sometimes when we run into, you know, troubleshooting, it can get a little stuck in the loop. And so then the cloud has been really useful for that.

Richard Moot: Yeah. I think one tip that I've heard and I'm, I'm, I'm actually starting to like to subscribe to it is that, at least when it comes to coding, it can be very helpful and sort of like building out certain pieces, features, functions, that kind of thing. But I have found that like when you start wrestling with it around debugging, I've had like so much headache and that I've, that's when I've kind of found like, oh, having my software engineering background has been very helpful in these instances of like, oh, if I just go fix the bug and then like, let it keep going, we're going to go ten times faster. If I try to sit here and be like, hey, can you go ahead and fix this bug? It's just going to keep introducing new ones and new ones and new ones and new ones. And then you're just like, okay, this is not. I'm actually taking more time than if I just wrote the function myself.

David Foote: You definitely have to wrangle it.

Arielle Watson: Yeah. And we found that the more rare the bug is, the less useful, really, any AI has been.

Richard Moot: I'm also curious, like for an agency, has it helped in sort of tackling areas where maybe previously you've been like, oh, we don't. It would take us too long to sort of ramp up in this particular area. But at least I'm just curious, like you use it as a tool or to see like, hey, can we maybe figure out like these, like, like what we would think are like hard unknowns to get enough to say yes to like, a certain type of project. I'm just curious, like how is it sort of like unlocked your sort of view of approaching certain types of projects?

David Foote: Well, I wouldn't say that. It's made more projects accessible to us. Exactly. So with existing customers where we already sort of have the right to, to work on, certain problems, you know, then we're able to expand how much of that problem we can tackle, maybe replacing some libraries we've relied on before. But, for new customers, it's not enough to give us, you know, bragging rights to say, oh, yeah, we can do that, you know, because we haven't done it yet. We just know that we have good tools to tackle it. If we do, it becomes necessary.

Richard Moot: I found like, it's like from a, from a DevRel side of things and just like, sort of exploring things, at least for like when I'm reviewing like code in the language that I'm like, maybe less familiar with, I've even found it, like, helpful to be like, hey, can like you convert this into, like TypeScript or like, explain how this function is working to as if I was a TypeScript developer and it's like suddenly like, oh, okay.

Like I see how these different ways that, like you say, rust is working. It's one it's a language that I would love to like, learn but don't have the patience for or, I mean, I probably should have the time, but I definitely realize I don't have the patience for it, so I've definitely found it like very useful for like exploring like these other areas where I would feel like absolutely no confidence to at least be like, well, I'll at least try and see, like what I can come up with.

David Foote: That's good to hear. I have a dream of taking one of our Swift UI apps and using AI to generate the Android version of it, so we'll see if that works out.

Richard Moot: I would love to know if it does because like, that's like for me, that's like the dream of like, oh, I wrote this example app. I wrote it in TypeScript. Can you go ahead and convert this into Python or Django or some other framework? Like that'd be amazing. And so it would be really, really helpful.

David Foote: I'm hoping it's the perfect excuse to spin up cursor AI, because I haven't used that yet, and I understand it has a little wider context across the project than just, single file.

Richard Moot: And I mean, I'm no, I'm not supposed to probably be, like, going over here, but I don't really care. That, plug in other tools, but I've definitely tried that one out. And it has been extremely useful. The other one I would recommend that you try out is a shameless plug is that we actually have an AI coding agent that's open source called goose.

And it's like it has a CLI and a desktop component. Highly recommend that you try those out. I think all you have to do is you just, like, give it an API key for your line of choice, and it works pretty well. Like you can just sort of say like, hey, I want to like, go do this thing and like, it will actually do what they call like a genetic behavior where it, like, will create files, edit files.

You can like, enable all different types of things. I do hope to, like, get, more people even like coming to build on Square to be leveraging that for like even just hammering out your initial proof of concept. I mean, that's the one thing that I found very useful for, like for AI in general, especially for using these agent behaviors.

It's not necessarily my default. But sometimes if I have a more complex idea that I want to convey to someone, maybe it involves something like having a small web app or a small website, it would sort of like put everything in a way that would better describe what it is that I'm trying to talk about.

It has been really useful for saying, like getting 80, 90% of the way there, where it would probably take me a couple of hours to like, create like a slide deck that would sort of describe this whole thing. And so that part I've actually found to be really handy, just in like a way of using it as a way of expressing the complex thought.

Arielle Watson: Yeah, I would agree. I think that being able to take an idea or even a design and turn it into not just an interactive prototype, which like you could do with Figma, but to turn it into like a working POC in a very short period of time. I think that's going to affect our industry hugely in the next few months.

Richard Moot: And so one thing I do want to bring this back to Square, just for like kind of coming up towards the end of this in in your experience of sort of building with Square for, you know, these initial like, you know, consumer app in-person experiences, I'd love to know like, and this, you know, be honest with us.

What's the good, what's the bad. I'd love to know a little bit more about the overall experience of like, you know, did it make a lot of sense at the beginning. And then you kind of got like a little you stub your toe in places like, I'd love to learn a little bit about, you know, your overall experience with Square and our platform.

Arielle Watson: Yeah, I would say overall we've really appreciated the documentation and the API explorer. That's been huge. And I've been leveraging your guys's postman collection a lot more in the last, last month or so. Nice. I think one area that's been more difficult is with using the SDK. Particularly because we are on React Native and we're using Expo, and so there wasn't really out of the box support for that. So it was a little bit of a learning curve to get them working and that we got there.

Richard Moot: Don't worry. I'm taking very, very meticulous notes here to remind somebody like you spoke to something that's very close to me. Like I've been wanting them to like have this exposed support. I can say that I've been told that this should be working for mobile payments. SDK should be working with Expo. I'm going to put like a little asterisks in this for the listeners, because I've yet to test this personally.

So I have a hard time saying like, yes, this totally works with Expo. But it has been told to me from the people who worked on the React Native, plugin for a mobile payments SDK that it should be working with Expo. I want to say that because like, there's a little bit of caveats when somebody on my team is building an AR tutorial for React Native, which I am preempting, but by the time this comes out, that video will probably be published and you can all watch it and like learn how to use mobile payments SDK with React Native.

And then we hope to follow on with another video on how to, how to make this actually work with Expo, specifically because Expo has been like a dream come true when it comes to making your app and your development process so seamless.

Arielle Watson: Yeah, kind of go more.

Richard Moot: And so I'm sorry for jumping straight in there. I don't know if there was anything else that you wanted to touch on in terms of, overall experience, as you said, Expo. And I got super excited.

David Foote: Yeah, yeah.

Arielle Watson: No, I think those were the main points for us.

Richard Moot: Well, I see that we have come up to our time here. And so I want to thank you both for coming on to the podcast. Big thanks to David, Ariel and all of Blue Rocket, really. And I would love to know if there's anything where folks can go to learn more if they wanted to talk to you about their own mobile app or their own project?

Richard Moot: Where can they find you?

David Foote: You can find us at www.bluerocket.us.

Richard Moot: Awesome. Yeah, yeah. And if you've got a project with Square, we'd love to hear about it. Reach out to us in Discord. Or X at SquareDev. Don't forget to subscribe and check out developer.squareup.com for more. Keep building and catch you next time.

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 people were actually buying.

So we started down that path and it came upon a point of, okay, we're managing three different centers of systems here. We're managing three different locations of different products. What can we do to centralize? This started with our group functions, especially because they were a really good example of, you know, you have hundreds of different price keys that each center might use, different pricing and all that.

And we began down the path of creating a system to actually synchronize the Square catalog to our group function booking system that my, my thinking there kind of started with. Okay, so Square organizes items by category and it can have these different prices, different availability locations. Whereas our group function system really only has like, you know, one category layer kind of it has the ability to do this price keys, but not as in-depth as Square allows.

So we started with the idea of every location that's available. We're actually going to treat it as an independent price key on the vendor side. Whereas the Square it's one we're actually going to create three prices. So if we create a group function price for, you know, an hour of bowling on the Square side, we're seeing, you know, that uniform price, the price over it, any overrides for the location where it's available.

And then I'm turning around and taking that information, including the category, and it's kind of the setup of it and creating three separate keys off of that and saying, hey, all three of these are related back to this one in Square. But that vendor system doesn't need to know that that synchronization handles all of that actual communication. So if we update the price for one location, it will only update that singular version on the vendor side.

But if we want to update all three at once in Square, that would just be one little change. And then the system would synchronize those changes over to the outside system. The biggest hurdle that we kind of ran into, is Square keeps everything very clean. And its catalog, it is very kind of intuitive. A lot of these outside systems have these layers of complexity that we didn't feel for.

At least our setup needs to exist. And Eric could explain more on that of just, you know, we don't need to go through five pages to find one price key where Square has it right ready to go. And we can set up kind of how intuitively a customer or a staff member would actually want to look at that.

Eric Osborn: And that now reminds me, Richard, the thumb before let us into a whole nother web of what we could do marketing wise as we were. You know, we originally only just using Square for food and beverage, but then as it grew into our other systems that grew into bowling and laser tag and the game zone, all of a sudden our marketing capabilities, the doors opened wide open.

We can now see that, you know, when a guest walks in the door, are they simply coming in for bowling or they coming in for bowling and and buying a couple drinks and buying food by and laser tag. We can see what portions of the building that they're actually utilizing and do more direct in particular marketing to them, like, hey, why didn't you come, you know, participate in Act growing, you know, with us who did laser tag but not actually showing.

Maybe here's a coupon for you to come back and give that an experience the next time. And it was really a, it wasn't something I was expecting at first, but once it all started flowing together, those transactions started coming from multiple different areas. That's when we really started seeing the power and what we could do with those different types of marketing campaigns.

Richard Moot: Yeah. I'm so glad that you mention that, because that's one of the things that, I mean, there's a period where it felt weird to like, sort of promote this to folks because, you know, it's like it sounds like, oh, man, this is like, you know, high level, amount of tracking, but it is like, really like, you know, I'm I'm gonna throw out some assumptions here.

Please feel free to correct me if I'm off-base on how this is working. But, you know, you can see a particular credit card come in and say you have no idea who this person is when they first set foot in the door. They may or may not have a reservation for bowling, but they go up, they go to the kiosks and they're like, oh, I'm going to go get some game zone cards for my kids.

And, you know, like send them on their way to go, like play in the arcade. And then I'm going to go buy some food. And you're seeing this credit card making each one of these purchases. So you're already creating a profile of this particular customer. And then when they go to say maybe they paid for the bowling online and you might already have like, you know, have this profile.

As soon as they do that first transaction, you're like, okay, we know we now know this person's here. You actually know how far ahead of their appointment they're there because they're immediately starting to do these purchases and like leading up to maybe their reservation time. And it's just like one of those things where like when you have this integrated throughout your entire system, you realize, like, you can see so much more about customer behavior.

And it just sounds like so much more interesting in a place where, like, there's like all of these different opportunities for like, you know, the go carts, the arcade, the food, the, the actual bowling itself that you can like really sort of see core to like the main things that certain cohorts tend to gravitate towards and like, I know that we, we, you know, like a pre call, we talked a little bit about like how you can like build different marketing campaigns of like, hey, how do we encourage a little bit more of like go cart usage.

Maybe we could send you something a few hours or a day or two before somebody like reservation to be like, hey, here's a promo for doing this while you're already at the venue. So it's just really powerful.

Eric Osborn: Yeah. Especially with the we do a lot of that through the smart groupings now leveraging that data. And when they were, they're left in particularly what category of stuff did they actually purchase. So you know, just to give an example, the stuff that we launched yesterday was just a basic survey to guess that were bowling and VIP because we want to know, hey, did you get your complimentary chips and salsa, did a manager check on you?

And we're already seeing within a 24 hour period, that we just launched it last night, dozens of these surveys coming back of people wanting to give us the feedback, and we're just simply sending them a Square gift card in return. So we're gathering data. That's a very powerful to the business and how it operates, and where we can fill in gaps of where we could potentially make more revenue producing opportunities.

And we're starting to feel it taking some time to leverage all that data. But it's working for us. And one of the things that actually encouraging them to give us more of that data is like our rewards program and thoughts. So you mentioned you're following the credit card, but most of our customers there's a good 20% or something now, which is really good for rewards program.

They're electing to give us more information. So we're getting their name, their email, their phone number and their birthdate, and they're staying in a part of our text programs. But because they want to get the rewards to come back and do laser tag, or if they've never done act throwing, come and do that. So we're leveraging multiple different things that are starting to come full circle.

And I don't think we realized that as a company a couple of years ago, I think you can even ask, you know, any one of our management teams, you know, what was the goal here and what did what did you envision this coming about? And I don't think they understood the full scope or the full circle, but we're there and we're now seeing the result of it, which is awesome to see.

Richard Moot: Yeah. I'm curious like to, trying to like, think of how exactly to phrase this, but like, you know, it started out with something fairly simple, like, you know, the curbside pickup, you know, during during a time where, like, you know, this is the this is the way to keep the doors open, keep some people employed is doing this like curbside pickup thing.

And then it kind of grew from there. I'm sort of curious about that evolution as you started to sort of plug Square into various other places, like how is that sort of mixture between stuff that you just sort of like had off the shelf stuff that you've extended on Square? Like, I guess I'm trying to like sort of understand, like, you know, how much like stitching together of things has gone off over time or is it like, really just like, oh, we just found like something within Square that we can actually replace something else that we were using and then just do like smaller extensions, like, I mean,

Yeah. How does that sort of grow over time in terms of trying to get Square working with any of these other tools?

Eric Osborn: It is I think it was, you know, we started with the simple stuff. Obviously, off the shelf, the food and beverage was the easiest to to get up and running because that replaced our, our, existing cards. Any kitchen printers, any more printers we had. That was a very off the shelf move for us. So right off the bat, we were able to move, you know, about 15 to 20 terminals per location over to the new system.

And our staff caught on to it quickly. It was just an easy flow. And then as that evolution started coming back around, we just realized that any time that we got that data into Square, it was making all the back end stuff so much more easier. So we talked about marketing. We talked about the web financials and all that whereabouts we were piece mailing it all together.

So if we needed up and from our front desk or we needed something from our our kiosks, we were writing custom dev to in order to do that, we threw out almost all of that and went to basically writing Square orders, and it simplified the whole process of not having to have our own categories, not having to have our own financial mappings.

So everything we're doing as of, you know, and we might have probably just made the decision at 2025, but we're going back and looking at why isn't that in Square. So if it is currently outside of Square like can we get it in there? And if so, how can we do that? And that's where Alex comes along. And utilizing all those APIs and and the resources that are available to us, to see how we can accomplish that.

Honestly, the main stumbling blocks or something, most of the time that third party partners are POS is that you have to work with because you got to make sure that they at least have the open mechanisms to be able to grab the data that you need and push it to Square. If that's not there, you know, it's totally out of the question. But, thankfully we've had really good partnerships with, with all of our plus companies and we're able to accomplish that.

Richard Moot: Yeah. That's great. I mean, like, it's one of those things where like, it feels weird to, like, start having the suggestion as a software engineer to other folks when you when you're basically sort of looking at the entire landscape of your business and saying like, okay, like in order for us to answer, say this particular question, it requires me to pull data from like 3 or 4 different places and like they're all in different types of formats.

And then I'm having to sort of do some data munging to like, kind of like, well, these are done in like the wrong time period. So I have to adjust it in order to work in the same time period as this other data set. And like once you actually homogenize everything into like a singular system, you're, you're writing less like throwaway code is like kind of like what I think of it because like, these one time reports are like maybe quarterly or biannual that you're just like, oh, well, we really need to answer this particular question because it's going to let us know, like, can we run this marketing campaign and expect it to be successful?

Eric Osborn: Yeah, I mean, there's dozens of one off code that we've been throwing out over the past couple of weeks just by pushing the data into Square. You know, I keep, you know, running into more and more of things that we're moving over. I said, we just moved to surveys and stuff over. We just moved to another POV.

But not even a week ago, while I was IPO, Alex moved to a game zone system over to Square as well. So yeah, we mentioned those games on cards that you're buying at the front on the kiosks. We're actually now grabbing the data from the video games, and every 15 minutes uploading those transactions to Square as well.

So we know how much video game play versus virtual reality versus laser tag. All that's now being funneled in. And that was a, I think for Alec that was, maybe a two day project. And we have another POS system that was linked in the Square. It's just it's been that easy for us.

Richard Moot: One thing I do want to kind of circle back to just, because I'm, I'm interested on a, on a technical level with the kiosk that you're using. If I recall, this is, like a kiosk system that you got through a vendor, but, the device itself, it's running on, like a windows OS as its base, which is kind of like part of the motivation for using terminal API versus like, say, our mobile payments SDK.

Yeah, yeah. Tell us a little bit about building the integration with terminal API and this device. Because from what I've understood, like, you know, thankfully the device that you have is like, you know, fairly open in terms of being able to plug and play certain things with it. But I'd love to just, you know, tell us a little bit about, like, the app that you built and how that sort of works and communicate with this kiosk.

Alex Trepasso: Yeah. So I'll, I'll kind of start from where when we first started designing it, where I jumped off from was, I know we had provided by the kiosk different payment methods that I could do. There's, you know, ones that are hosted on site. There were cloud providers. They had, none of which were Square at that time.

So we found a provider that they had set up that actually was using a Soap protocol to send out its transactions to what it assumed was a local server. And that transaction information was just a little here's the bill ID, here's the amount to charge, you know, charge it and move on. What we ventured from there was kind of, almost pentesting that of, okay, can I intercept this and act as that receiving server?

From there, it jumped to, okay, so now I got the request. I can take it in, I can serialize that. I know what my amount is. I know my bill information. I know what response it's wanting or expecting. That little piece in the middle that we've named, Mercury. Just because I used record naming for a lot of our software just for the fun of it, basically acts as just a messenger in between.

So it takes that so request translates what the charge should be, what any of the bill information sends that to the terminal API to create a transaction. And then basically sits and waits for the terminal to reply or that transaction update and say, hey, I'm complete or I'm canceled. From there, I translate that back into what the kiosk is expecting as a payment response that just says, hey, was it a denied?

Was it rejected? Approved? What's the status? I tell the kiosk, yep, we're good. We took the payment and it moves on just like it would request a normal vendor or the normal system that it thinks it's talking to. Basically just that messenger in between. So there's no creating of orders or trying to mess with the bill in any way.

It's just going, hey, here's my amount. Translate this into something that terminal API can understand, and then translate the terminal API response back to something that the kiosk can understand, and that that became the philosophy for a lot of the software was instead of trying to reinvent the wheel or make these throwaway reports or that throwaway code you were mentioning, we go, okay, what if we turn these into basically data pipelines and let Square continue to do what it's really good at with the reporting and the transaction handling and just get the data to Square, let Square do the actual work.

We just act as kind of this in-between data integrator of saying, see, here's the data Square can do whatever it needs or whatever it wants to do with those numbers for marketing, loyalty rewards, business tracking, anything like.

Eric Osborn: That, unless you're currently working on it. Good to mention that this integration was done well over a year ago, before we thought that, you know, Square was going to be that total ecosystem and where we were going to funnel all of our data. So it basically started as a custom amount integration on those kiosks. And Alex can speak a little bit about what we're doing now.

He's working on the full itemized integration for that kiosk as well. Now that we see the benefits of what we need to do there.

Alex Trepasso: Yeah. With the, I'd almost compare it to a snowball if we started very small in control and we started with this one off kiosk integration. And then as we integrated more systems and more features of the different systems, I realized and through discussion with Erik, realized we're doing a lot of the same actions over and over again.

So instead of designing, you know, five apps that communicate between the five different pieces, what if we do one that understands data and knows how to get it to Square? And instead of building everything from the ground up, every time we just build these essential sort of intakes of data. So we take the data from the POS, let this centralized system convert it to what Square wants and what Square's looking for, and open that door to when we have a new POS.

We're not trying to rebuild everything, we're just doing something that integrates. We got the data in this format. We already know Square wants this. Let's just take it and format it how we need, which is really spelled out development times. It's allowed us to, like Eric said, turn around an entire new POS onto the system in two days, rather than, you know, having to go all the way from floor zero or ground zero of where am I going to go with this?

Now we kind of have a set template of every time when we're moving forward. Yeah.

Richard Moot: Now that's very cool. I mean, like, you know, I had this, like, silly. I thought I might have this, like, this, like this Borg, like a simulator. That's just as you bring it in, like this new thing. It's just like going to go, I'm going to assimilate you to, like, funnel the data into Square and make this unified.

Eric Osborn: Yeah. And we would say no at this point if it couldn't funnel in the Square that but the amazing part about it, and the only reason those systems exist are because they're specialized systems, like a game zone or running a go kart or running bowling. So those are always going to exist in the entertainment world.

Richard Moot: I mean, like that part I still is, just like I feel is like very fascinating because, like, you know, I probably one of the few people in this world that, like, will ask random people who own a business, like, you know, what is it that you use to, like, operate various different components and like in an entertainment center like this?

I'm just surprised, like how many different types of systems that you need for managing different entertainment parts. Like, you know, I mean, most of the time we might just, like, take it for granted, like, oh, yeah, you know, they got cards for the arcade, you know? But there's got to be a whole system for, like, you get the card, you got to load the card, you got to track how much is on the card.

It has to communicate with each one of the game machines, which is then also going to communicate back to a server to say like, hey, does this person have credits or multi-location? Yeah, yeah. One thing I do want to touch on is even in like, you're, you're handling payments for the game. So cards you originally were had this approach where you were sort of like sending the revenue directly to your accounting software.

But then part of this, like migration you had like this, you know, win of going by having this go directly into Square and Square, then now sinks into your accounting integration. Yeah. And so that's kind of like sort of saving you even from having to deal with sending your stuff directly into the accounting software.

Eric Osborn: Yeah. We actually had some of those one off development things that were going on because a lot of them didn't have that native integration to the accounting platform that we were using. So Alex had these, these one off tools that would run in the middle of the night, basically exporting, you know, text or CSV files that could be ingested into the accounting software.

So we've eliminated all those little one off things. And as Alex was saying, it's kind of all using the same mechanism now for ingesting the data, throwing it into a Square transaction. No matter where it's going. So just overnight we, we eliminated all the actually within the past couple weeks, 3 to 6 different little one off, import export tools that are now just being ingested into, Square.

Richard Moot: And I mean, it's, it's like, I feel like you're just, like, telling my, my dream story to be telling about the ecosystem because, you know, we we love to talk about the, the ecosystem that we provide here. I think sometimes it's even hard to, like, really understand, like what the ecosystem of products really is. And I think you have like, just like the right mindset to, to be able to see like, oh, like, you know, it's working in this particular area and like, you know, it kind of could work for this other thing.

Let's try it over there. And like you know, you solve the small problem first and then you kind of realize like, okay, well, now that we solve the small problem, we realize we can kind of have it solve more than just that. And you keep growing it and all these different areas and eventually it's just like you're now at this point where, like, if it doesn't work with Square, we're not really that interested.

Eric Osborn: We're not going to use that. Yeah. Yeah, it's kind of amazing now that, y'all, I find myself scrolling through the dashboard or transactions. What funneling through there is pretty incredible. Now that we can link all these transactions together. And our staff and our managers, our team, they all know that, you know, anything that they need to manage now, as far as refunding or voiding or crediting a customer, they go right to a Square tablet.

It doesn't matter where they bought it in the building, whether it's a kiosk, a game or online or bowling, it doesn't matter. They pick up a Square tablet and you now have every single one of those transactions. Right there would be for us to go into three, 4 or 5 different pieces of software just to figure out where to refund it.

And at one point we were going into multiple credit card processors to figure out, you know, what went wrong or what needed to be refunded. So I find myself scrolling through the dashboard every once a while ago, and while this was actually really starting to come together for us.

Richard Moot: So I think the final thing I do want to touch on because, just to geek out on, is you built, the integration for the kiosk system. So you're running that, I'm assuming somewhere locally, or is that actually like a cloud solution? It's like connects with the kiosk software that you're sort of having, like, I guess I'm more curious.

Like, what did you build it with? You have like a little server that's probably like sitting there listening, waiting for, you know, something to come through. Tell me a little about your tech stack is really what I'm getting.

Alex Trepasso: Yeah. So the first point I kind of went with was knowing that it is a payment provider. It needs to be incredibly reliable because you don't want a customer having a failed transaction, as typically, at least with me, within FCX, a failed transaction or a pain point will push a customer to no longer use it. It's kind of an all or nothing of if it's difficult, they just simply won't go through that flow anymore, regardless of what the end result would be for them.

We then, using our cloud provider, found out we can integrate it directly into our network essentially. So while it's a cloud hosted server and they handle, you know, the uptime and making sure it's online, making sure it's reachable, making sure it's, you know, healthy as an app, it's integrated directly into our network. So that kiosk is sending out a request to what it thinks is a local server running in the building, that goes through our networking system and then gets to our cloud provider.

It processes that request and sends it back, without really any points in the middle that neither system thinks it's in the cloud. Essentially, they both think they're working locally and they both have direct access to these resources without any kind of pain points there.

Eric Osborn: It's funny that Richard mentions the, you know, the computer sitting in the office or the computer, the server sitting in the server room, because that is where a lot of this stuff started. When I first started and where Alec first started, there were a lot of these one off little servers, you know, sitting around. But, like he's saying, it's going through an SD-Wan solution at this point to the cloud provider.

So it's just there and there's multiple redundancies in place for that, to make sure that continues to happen in any way, shape or form, you know, for losing a number, we might switch over to broadband and then broadband. Unfortunately, we don't have great 5G connections, but we could switch to a 5G connection if we absolutely need it to.

Alex Trepasso: And I think, on the tech stack, a little bit of that app that provides some of that is we knew going in, we didn't have, you know, time to reinvent the wheel. We needed something that we could kind of develop quickly on, iterate quickly on, you know, if something needs change, change it, you know, on those one off scenarios.

So, that was kind of our first dive into Node.js and using TypeScript, Node.js and essentially an express server that's processing those requests and allowing us to kind of quickly get things working. And I got to give some of that credit to you guys over at Square for that your API is very developer friendly. Probably one of the most developer friendly we've worked with in our different vendors and with its multiple different kinds of integrations, both with its direct SDK for Node.js and its direct different integrations with these different platforms and tech stacks.

We're able to, you know, take something that normally would take a week because we're designing everything for it and quickly iterate and go, you know, overnight turnaround and have a solution to integrate these different technologies. And that's been carried forward into pretty much every software of the Square API has been very developer friendly and very open to working with different data formats that we've been able to quickly spit out these integrations and get things up and running without, you know, huge turnaround times.

Eric Osborn: I mean, that chaos integration. And looking back at almost all the integrations, it was a 1 or 2 days of dev, and we're writing the testing and, the chaos integration was one of the most flawless ones. The testing from day one, there wasn't one failed transaction. And then going into a weekend that has, you know, a thousand transactions in a week and then not having one failed was pretty amazing.

And that gave me the confidence and the entire team, the confidence to continue moving forward with this.

Richard Moot: I love to hear it. I mean, like, it's it's one of the things that I, I've heard time and time again. I feel silly because it feels like I'm just singing our own praises here. But, the ability to just, like, sign up for a developer account, get credentials, and immediately start building and testing. I can't tell you how many times, like, somebody, you know, started out with an idea where, like, they were at, like a baseball game or like the coffee shop and they see the payment system there and there's like, wait, what is this?

Can I and then they go look up the docs and within a week they have a proof of concept up and running and they're like, hey, I already like having a terminal device taking a payment. And, you know, they're shopping around within their company to be like, hey, we can use this. Like, this can actually solve the problem.

And of course, like, you know, eventually have to build out to scale. So, you know, you go through the process of getting Docker-ized apps in your cloud provider and getting, like everything strung up. But like, you know, you have that moment initially where you're just like, no, like, this can work. Like I've, I've always believed in that.

Like for developers, like you can convince them, like in that moment, this can work. It's working for you right now. Like, yeah, you got to build out the scale and the reliability. But it's going to solve the problem that you want.

Eric Osborn: Yeah, it's even more exciting when it's, when there's a known pain point in our operation that we can bridge. And a lot of times, you know, the staff, customers or management won't even realize the bridge is there. Making that a simple process. Where about if you go to, you know, a lot of the, the one off folks that are single train operators and that they might not have, you know, had somebody to be able to take that leap for them.

So they are still doing it all that multi transaction and the multi POS, it's really a seamless process at this point.

Richard Moot: Yeah I mean you know going going back to like what you touched on earlier of that still surprises me to this day of like you know a lot of businesses in or like other software providers or hardware providers for that matter, you know, have this expectation that you might have this like literal server setting in like a back office somewhere that's going to be connected to your network.

That's like, no, it's I'm going to try and find this thing. I mean, like, that's the whole reason that you're able to build this, this integration with the kiosk solution because, yeah, a lot of businesses have that. I've talked to that. Clinics, law firms, some of them have to for regulatory reasons like, you know, their system data has to be in this very controlled format.

But it makes these integrations like a lot more difficult when, you know, you have to then go talk to a vendor, get special documentation and like try to figure out like, how does this system actually work and how can we make it like work versus like, hey, here's like an open system where you can just immediately go in and build and test.

Eric Osborn: And that way a lot of our decisions at this point is looking for that open API. And what can we leverage and what can we do with it, rather than focusing on the front end, you know, the gooey and what that's actually happening is if we do need to do the one offs, or we do need to bring it over to Square, is that available for us to do so? And that's important at this point.

Richard Moot: I mean, it makes a lot of sense, you know, for something like, you know, an FCC like, you know, it's a very you want to have it how you build your business. Because what you build is very unique. You know, it's you know, it's your particular mixture of like having the go carts, having the arcade, having the bowling.

Like, you know, you're going to be able to, you know, find a solution and build something that works for you guys instead of just trying to like, you know, take stuff that's off the shelf and, you know, hobble it together.

Eric Osborn: Yeah. And our team hasn't seen it yet. But, you know, we're trying to focus a lot on selling packages and bringing the different attractions together so that when you're just coming in for laser tag, you're just coming in for bowling. It might be a little bit more enticing if you're, you know, getting 50% off on your next attraction by bundling it together or, you know, as I mentioned before, we'll fast Tracks will be our go kart place across the street or across the parking lot, essentially.

So you're going to walk in the Headpinz, you're going to be buying bowling, but you're going to be able to add racing to that all through one ecosystem. So you're going to be in one location while booking at location B, and that's all made possible by pulling these pieces together.

Richard Moot: Yeah. I mean it's like software. Is it like literally enabling the cross-sell?

Eric Osborn: Yep. Exactly.

Alex Trepasso: To jump in on that. I think a big part of that, at least for us, was a lot of these other vendors, you know, there's vendors like that do our games that have been in this business for 25 plus years. They know what they're doing. They've mastered their little niche. And while it may not be something that Square provides or would go down the path of writing, we can make that work because Square is very open to understanding.

Yeah, there are going to be things that, you know, especially in an FCC type environment or these large business environments. You have these multi different essential ways that a product gets old. You know, you have bowling. That's my lane. You have go carts. That would be by the time slot. The arcade is just money on a card that are all very different.

And how the user experience is in the business view is that just wouldn't exist together, that we can make work together. So for a customer, you know, they're checking out in one place and having that singular transaction rather than having to go through five different transactions to achieve the same result.

Eric Osborn: And it makes me think on the In the Square catalog side, like, one of our providers for bowling, they simply just added a custom attribute that decides is that price key for bowling shoes, price fun, whatever that may be. League bowling with just a simple dropdown that decides where it goes into that front desk. For bowling wise.

So it is really that simple when it comes down to adding those keys and utilizing them.

Richard Moot: Yeah, I really want to reiterate like what you said there that is very important to like sort of highlight for other folks or just like the different ways that you sell things. I have come through this time and time again, like just dealing with a catalog is, you know, different types of businesses have different products that they're selling.

But like, you know, bowling is by the hour, but like the shoes are like Purge Day and then like, you know, you're going to have all of these various, like, different things that like a very bespoke way of selling this particular product. And so having a flexible system that allows you to like, unify that and can meet your needs as you have different things you want to add or offer, and there's a programmatic way to do it.

I do want to thank you both, Eric and Alex for joining me here in the podcast. It's been very enlightening hearing how you have such a tech forward family entertainment center business. I would recommend anybody if you're in the Florida, Southwest Florida region. Definitely go check out Headpinz. You can find us at Square Dev on X. Or you can reach out to us on our discord. And if you have a project that you're working on, make sure to let us know about it. And don't forget to subscribe and check out developer Dot Square up.com for more. Keep building and catch you next time.

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 just send a message back like, Hey, what did you need help with? Or maybe even be smart and look up like, oh, does this person have a booking? Were they trying to reschedule? There's so many different kind of workflows that can spring from that touch point.

Binh Ly: Yes, and I think the recent advent of LLMs has really helped and how that is experienced because the hackathon project, and this goes back to why people pick Operator over other messaging providers I guess you'd say, is that in the hackathon you can project, you can see that the cancellation campaign, when it sends out the sequence of text messages, you can customize all of those to use your own language. And the interesting thing is whether we've been experimenting with using LLMs for is it turns out it's kind of hard and people also manage to mess up reply Y to confirm, or one to confirm they can fat finger that easily. We see it a lot in the logs when we're helping the customers diagnose why some of the automations aren't happening, but you can feed that into the LLM, like, look at this conversation, do you think they confirmed or not? And it turns out it's really good at that. That's one my favorite uses of it so far.

Richard Moot: And so the other thing I wanted to sort of touch on is that you have this product follow-ups, a part of Operator, but this is actually kind of grown beyond just sending messages for missed appointments, but there's many other use cases. I was hoping that maybe you tell us some of the other use cases that people have had for this communication style.

Binh Ly:Yeah, so like I mentioned earlier, the customization of the messages is one of the big reasons people keep contacting us, and that's not just over SMS. So one of the complaints, not complaints, I guess the feedback that we get about built-in appointment reminders is that they're all the same.

So we allow our customers to customize that initial message and the follow-up message so it feels organic and on brand with how they do business. But that didn't exist at the time of the hackathon project. And the other thing is that this capability has found, when we first envisioned it, it was for stylists, people we were most aware of with who deal with cancellation and no-shows, but the general awareness of Square's, APIs, the Square appointment products, Square payments has really opened the door for Operator to kind of transition into a consulting business. Someone will say, I have this technical need or this problem, and I can say, okay, I know how to solve that with some software and very specific integrations.

Binh Ly: So Operator is being white labeled essentially next year in an unexpected way with a company called BeamReaders, and they're a dental radiology company that will be using Operator’s infrastructure to communicate with patients. They have this new, this need where currently they operate kind of like an Uber for dental radiology, someone who needs a ride and Uber matches you with a driver. So in the current business for Beam readers, someone has a cone beam scan of their head, they need a radiologist to interpret it. So BeamMeters connects the two.

Richard Moot: Interesting.

Binh Ly: So now there are a plethora of these cone beam devices across the country, underutilized. So they'll be launching kind of like an Airbnb, but for the cone beam.

Richard Moot: So for anybody who's not familiar, give us the quickest way to understand what these cone BeamReaders are, what they're used for.

Binh Ly: So typically you go to the dentist and you get an X-ray done. That X-ray is in 2D and dentists go to school and they're trained to interpret 2D, but the cone beam technology is 3D and it captures more of you, not just a chunk, so maybe from the chest to the top of your head. So in that range of coverage, there could be diseases that the dentist is not trained to identify or address, but by law they are liable for that. So if you go get a cone beam scan, there's some cancer somewhere in you, but the dentist doesn't tell you they're liable for that.

Richard Moot: Wild.

Binh Ly: BeamReaders exist to shift that liability, so you send the raw cone beam files to BeamReaders, they have radiologists on staff who will read through it and then write up a report, let you know that there's something wrong or if it's all good. So that's the core business around that cone beam technology and if they're getting adopted in other industries too. So we're seeing it happen with chiropractors. So if you have a 3D view of someone's neck, that's really powerful and helpful.

Richard Moot: No, I mean as somebody, I have a pinched nerve in my neck and I had to go in, get an MR, I get steroid shots and I'm sure that somebody, at least with a better analysis of doing a 3D of my neck would see like, oh, is it the actual bones? Do I have bone spurs? They could rule that out much more quickly, and so yeah, I mean I definitely see there's plenty of use cases there

Binh Ly: And that technology is being installed all over the place, but it's very expensive. So by allowing other businesses that don't have a cone beam to kind of rent the cone beam for a bit will just help grow the adoption and care coverage, essentially. More people will have access to this because of this software, but they're thinking about using Square Appointments.

So if a practice has a cone beam and they want to sign up for BeamReaders Airbnb type product, they're thinking maybe they can also sign up for a Square Appointments account. And those appointments, if someone's referring a patient to your practice, you can put that into the Square because it's not really your, so it doesn't make sense to put them into your patient management system. So you put them in maybe something like Square and then facilitate all the communication over SMS. Because in my experience with Airbnb, at least, you book the place, you send the initial message to the property owner, but when you check in, they're switching the SMS right away or iMessage, no one wants to log back in.

So the same thing we think will happen with the dental stuff. The patient does not know the practice that they're going to get this cone scan. The more friction you can avoid, the better. So just send a text message directly to the patient from your landline and you'll cover that communication gap immediately.

Richard Moot: Yeah, so one thing I want to circle back to is that issues around the liability, and then I'm curious on the Airbnb type component to this. Is that in part to maximize utilization of the cone beam? Because from what I would understand, they're probably not cheap. So you still want to recoup the cost of it and maximize the use of it in order to make it worthwhile to have. So is this to make sure that people can find out where these things are and get these scans done? And then also to touch on the shifting of the liability there?

Binh Ly: So there's actually two parts to the answer to that. So yes, the cone beam device is very expensive and dentists will acquire a machine and they don't always use it because of the liability risk they have to pay for the report. So to provide the most amount of care, the best care, if you have this equipment, you have to incur a cost as the provider.

So the Airbnb model will help, hopefully at scale help to reduce lower that cost because you're recouping some of that. But the other thing that BeamReaders is doing that will be doing that's pretty innovative is that they will allow the provider to offer the patient the option of paying directly for it.

Richard Moot: I see.

Binh Ly: You'll go in, they'll say, look, we took a cone beam scan of you, but to ensure that there's nothing wrong, we recommend that you get it reviewed by a radiologist. If you want to do that, then they'll slide a Square terminal in front of you, the patient sticks their credit card in, and then the appropriate charges and fees get distributed. Everyone wins in that scenario.

Richard Moot: So shifting the patient in this instance is paying for this directly, that kind of shifts the liability that's like no, it's their scan that they're paying for rather than something that the dentist does and orders and runs through insurance.

Binh Ly: Yes.

Richard Moot: That kind of helps in sort of shifting the liability that it's now on the patient to sort of follow up with a radiologist or others?

Binh Ly: Yes

Richard Moot: I see. Well, I'd love to see the Square terminal device, just put it right in there. I know we have plenty of workflows to make that a little bit more seamless, but yeah, that's really interesting that you can just do one simple change in the ordering of things or who's paying for it can make that far more viable. Because one thing I know that we had talked about before doing the podcast here is the actual impact that this particular technology can have for people because of what it can see that you normally couldn't. I don't know if you want to sort of speak to that a little bit more.

Binh Ly: Yes. I asked, I think recently, what percentage of scans come on a day-to-day basis. When a scan comes in, how often do you see something dangerous? And the staff said every day, multiple times a day, people are just getting their scans sent in and there's cancer or something else terrible. But it's really wild to think that only a small percentage of the scans get sent in for this kind of review. That's really scary. So anything that we can do to make it easier on all the parties involved to be like, this is a good thing to do, you should do it all four. And it has really huge implications for child development too. We've seen a couple of examples where you'll see a child, it's like bags under their eyes, they're lethargic, bad, poor grades, they go get a scan, you can see the airways obstructed. So their devices that you can give to the child to help aid in the development of their face improve the airway. And after these things are administered six weeks to three months later, no very noticeable change in the child's appearance and behavior

Richard Moot: And all just from being able to have a more detailed view of the whole passageway from using this 3D scan.

Binh Ly: Yes, and I used to really, I've been scanned twice and what I was able to see about myself was really eye-opening. So Asian people I guess naturally have smaller airways, but my airways are exceptionally narrow. It's 72 millimeters.

Richard Moot: And what would be sort of a normal to just give us an understanding of the difference between 72 millimeters.

Binh Ly: I doubled that.

Richard Moot: Okay. Wow. Wow.

Binh Ly: Yeah, so I remember one year I put on my Christmas list to be able to run a mile. So I thought it was all kinds of fitness things, but it really is obstructed up here. The oxygen can't come in to begin with.

Richard Moot: Yeah. Wow. That's something I just wouldn't even really think about.

Binh Ly: And it's only possible because we have good tools now to back up someone's educated guesses.

Richard Moot: Yeah, and it has me wanting to go get one because I've been diagnosed with a mild sleep apnea and I'm sure that it at least helped me rule out, do I have any kind of actual obstruction in here? Is there something that can be done about that? I'm sure something like that would be super helpful for that.

Binh Ly: Tremendously helpful. It adds up the longer you are apneic, the more damage to your body.

Richard Moot: Yeah, no, I mean I've learned over time, it feels silly to say this because of course sleep is important, but it's when you don't have good sleep that you start to learn how really, really important because it kind of just affects every other component of your life. And that's why you talk about these children who are having obstructed airways and it's just causing a perpetual issue and they're at the most critical stage of development that to have an obstruction is just so much more dire.

Binh Ly: And as a parent, I've reflected upon the times where we thought that there was just bad behavior, but it turns out the body is signaling. So for example, bedwetting, night terrors, those are all signs that the child's body is giving to you that it's not getting enough air. So it's trying to wake up the child to get more air. I've heard from a lot of parents, yeah, they just can't stop wetting the bed or they're frustrated for some reason their child is not developed, like all the other kids, I dunno, why they can't grow up. It has nothing to do with that. You got to look at the airway.

Richard Moot: So weird segue, but I do want to circle back to some of the stuff that we talked about earlier with, because you mentioned about LLMs and I do recall we had sort of touched on some of the ways that you sort of evolved your product over time because as we know that SMS has become more regulated and so being able to go and get an account, I mean I think some of us has had this with the various API messaging companies, you have to go through a little bit more of a process. But then also you've kind of innovated on ways to help mitigate certain types of issues to enable your users to use your product in the way that they expect it to. So I don't know if you want to, first let's talk about the regulation piece. How has that sort of changed things for your business and how have you sort of reacted to it?

Binh Ly: Yeah, so around the start of the pandemic there was the formation of this entity called the Campaign Registry. And if you wanted to send SMS traffic from your software, you would have to register the phone number with this organization and then also specify the message payload. So give them a sample of what it is that you're sending and then they approve it and once they approve it, you can start sending messages. But if you don't do that, you can still send, but you'll be charged a higher fee. I believe, at some point in time next year they'll finally block it. If it's unregistered SMS traffic, it'll get blocked completely.

And it really seems like what they consider spam traffic feels more restrictive now. And so despite that, real businesses have real needs that they need the software for. So we started to notice that for one customer that uses it as an alert system, the first person on the pool of numbers gets alerted, and everyone else gets blocked. So that was causing a lot of frustration since these are moments of importance for business and they can't afford to have these messages not be delivered. So that was the first time we ever used an LLM for anything. It was to rewrite the message, so it says given this recipient, this is their full name, rewrite this message and then send it to them. So the business, they compose the alert message however they want and then the LLM will rewrite that for each recipient and we cycle through three different providers for that. So to try to maximize, because even if you change the temperature sometimes you'll still get back the exact same message and then it'll get blocked. So it goes 1, 2, 3 anthropic, Open AI, Llama, and then just cycle through the numbers that way.

Richard Moot: I see. And so in your case of the alerting thing, it might be like say I'm going to give a contract example because I'm not going to mention what the specific case was, but say that we had an alert that a service went down, you want to message all the engineers who were on call previously, you'd be like, it's just going to get to the first one of the list list that one goes through the rest from our blog. This would actually try to rewrite the message to make it more bespoke to each person on the list so that these look like a series of individual SMS, not one massive one.

Binh Ly: Correct.

Richard Moot: Yeah. I mean it's a very interesting way of circumventing that because it's like obviously there's a need here, but at the same time, I know that in the last year I think that we've all gotten lots of SMS from political campaigns or from other organizations. And so it's interesting to see how you can help a business be able to use this for a specific use case and not for something malicious, like sending a weird spam text to a bunch of random people.

Binh Ly: Yes, exactly. And the other interesting use case along the same lines was that we had one customer who would send out really long messages like up to 1200 characters and you can't send that large of a message over SMS reliably because the carrier will break that up and then they'll come in out of order. So they'll compose it. Then we ask the LLM to break it down into bullet points and it can construct more sensible breaks in the long message that the carrier can. So that has both increased their throughput and if the message makes sense or not. So that was pretty neat that it can do that.

Richard Moot: And so one of the other things I want to just touch on just for the sake of having people understand how to go about building basically to help inspire those in the Square developer community, what did you first build Operator on in terms of backend languages, front end stuff, and how has that sort of evolved over time?

Binh Ly: Oh yes. So the very first version ever of the system was written with an elixir.

Richard Moot: Oh wow.

Binh Ly: Using Phoenix because it had really strong web socket support. That was 2018 I think, and we had a mobile app that also connected. Since the Apple push notifications weren't guaranteed, we also applied web socket usage there, but then the guy Elixir and Erlang and the Beam, they're kind of exotic technologies to me even to this day. So when I had to need it to rewrite the whole system, I did that in Ruby with Rails the fastest way to get it up. So it's a webhook heavy system. So that's how the carriers communicate with us. So thousands of webhook calls an hour.

And so despite that, the system is still really small. It's a pretty small instance, at Amazon, we store every webhook message that comes in and process that on a background queue because the luxury of SMS is that the receiver doesn't know when the message is coming. So it's not like WhatsApp where you give them the little dots that someone's typing that's kind of unnecessary for business messaging.

They just know that the message is coming, so that buys us a little bit of time. So it's a Rails app that uses Sidekick behind the scenes. So small Rails app with the Sidekick machine is kind of large.

Richard Moot: Awesome. And are there any other components? So it's just staying with a Rails app. Are you using anything for any kind of front end components of this?

Binh Ly: In the newest or the latest version of Operator, it's Rails. We just upgraded to Rails 8. It uses a lot of tailwind, but it tries to be as vanilla rails as possible though, because should something go wrong, I want to be able to just picture in my head where the problem could be.

Because my thing is I played a lot of hockey growing up and there's this saying in hockey, if you're a defenseman and you play a good game, no one says anything. No praise or anything, you play a bad game, everyone brings you up. So the messaging service is kind of the same way on a day-to-day basis. It's quiet, there's just message traffic, no support tickets. But when there's a delay or the customer knows that someone's texting them but they're not receiving it, then it gets crazy real fast. So the system's designed too, or I implement it in a way where I can quickly diagnose or try to quickly diagnose where the problem could be. So storing the webhooks in the database for 30 days, I can always replay things.

Richard Moot: Right. Well, I think you have a really, I can't speak even more to how much your approach to that aligns in terms of that. As long as you're doing everything that you're supposed to be doing, everything should be quiet. But as soon as things go wrong, things are going wild. And I know from a design perspective within Square, the whole ideology was like to get out of the way of people running their business, the point of sale and all these things should not be hindering things. They should just be folding into the background. They should be seamless because we want, I mean, business owners just want to run their business and showcase what it is that they're trying to sell or what it is that they're trying to offer. And having stuff that gets in the way of that is not helping them. It's hindering 'em. So it should be saving time and be reliable. And I'm sure with SMS, that's what you're trying to do. You're trying to save them time and be reliable.

Binh Ly: Exactly. And I think a big influence on how this perspective on how to build it came from was actually visiting the customer on site. So if you go into a dental office and poke your head over the counter, they're not using Studio Display and MacBook Pros, they have square monitors back there. These are people on older machines that they don't really care about real-time refresh, but they know if they switch the focus to your browser and they refresh the page, they better come back up. That's the bar. You cannot fail at that part. So we try to ensure that every single time.

Richard Moot: Totally agree on that. I mean, the amount of times that we end up looking at a redesign of a webpage and we just go, oh my gosh, this looks so amazing on this giant 4K ultra wide. And then you realize, yeah, the JavaScript payload on that is way too large and it takes forever to reload when you're on this tiny little machine that is on a very unreliable wifi connection that's not saving somebody time.

Binh Ly: Not at all, the other thing that really influenced the decision to go with Rails is the rails console. Whenever something seems off, I can just SSH in and connect and start looking at the data that way. That's a really helpful tool for me. I think that's why I don't choose other tools. If they don't have that ability, I can't do it.

Richard Moot: Yeah, I mean there's a power to convention over configuration. I think even as a developer, as I've evolved over time, I used to be really into building something with Express and Using React, and I love the customization of it. And as time has gone on, I'm like, I really wish there was a little bit more convention here. Everyone kind of develops their own conventions and it saves you a lot of time in your decision making because it gets you closer to solving the actual problem of you're building a business, you're building a service, that's what you want to do, and convention gets you there much more quickly.

Binh Ly: Yes, for sure. And also the other hard learning was customers don't really care about your stack.

Richard Moot: Yeah, no, they don’t.

Binh Ly: When I first graduated university, I worked at Real Networks, the makers of the Real player and my boss there, this C++ master. And he was really into generics and C++ templates, so that was kind of my worldview. Everything has to go through the C++ pipeline, otherwise you're not a real programmer. But when you're talking to a business owner, any mention of that kind of stuff, right over their head, they don't care. They just want it to work. And so I just try to pick the thing that is the most solid that gets me there.

Richard Moot: Yeah, I could only imagine going to a Square seller and be like, Hey, do you want us to build this with a serverless technology stack that has edge functions? And I'm sure they just be like, I just need to work. I just want to take a payment and make a sale. I don't care how it works.

Binh Ly: Yeah, exactly. Especially with Square merchants, they have the Square on their phone, so they always say, can I use it on my phone? They don't want to have additional hardware or anything. It needs to meet them where they work primarily.

Richard Moot: A hundred percent. I mean, I think I've regularly had, when talking to members in our developer community or people who are wanting to participate in our hackathons and they're building out all these web dashboards and other things, and most of the time I'm trying to encourage them understand that the Square seller spends most of their time sitting in the point of sale or sitting in the Square dashboard. That's how they're running a good chunk of their business. And so you don't want to be trying to pull them out of this. You want to find a way to be injecting or hooking into this to compliment their workflow, not pull them out of it.

Binh Ly: It's also really funny with the younger workforce, maybe this is not okay to say, but in talking to the owner, they talk about some of the friction that they have with their staff. They're willing to do certain operations. I think having a mobile app for Operator is a big win because the staff is already on their phone doing whatever it is that they're doing. If they can do their job from their phone, that's one less battle you have to fight. It's a job.

Richard Moot: Yeah, well, there's something also I think sometimes interesting about, so I've talked about this, people on my team, and this isn't necessarily with phones, but I feel like there's times when working from home and having multiple monitors can suddenly be very distracting. Whereas if I pull my laptop out, I have single view, I'm single focused on a task, mobile devices that actually really lend well to this. You can only really be in one app at a time. And so when you're in that app, you're focused into what you're working on there. Granted, I know we all switch between apps. I mean maybe not, but I know I switch between apps all the time on my phone, but at least when you're in there, you're focused and you're working on this particular thing. So I do think that there's a power to that to allow them to work in a constrained environment that keeps them focused

Binh Ly: A hundred percent. And recently, maybe in the last six weeks, I've discovered a super mode that I installed Linux on an old MacBook Pro, an M1 MacBook Pro, and it's like my favorite development environment now because there's nothing else on there. It's just BS code and the Kitty terminal and that's it. But you get the nice hardware feel. That was always a big barrier. I didn't want to use a think pad with this weird track pad and things like that, but.

Richard Moot: Yeah, I've done that. I've done that all on a Linux build and I thought it was going to be great for me, and I ended up just quickly reverting back to my MacBook. So I think there, there's definitely a power to having the good hardware component, but then the simplicity of like, Hey, all I have here is all my development tools. There's nothing here to distract me.

Binh Ly: And then the dev containers were introduced in Res-7-2. Once I learned about that, I was like, I can't imagine doing things without this.

Richard Moot: Yeah, I agree. Well, I see that we are coming up on our time here, so I'm going to say that that's probably it for today. But I want to give a big thanks to Binh for joining us. Just so interesting, every time I've chatted with you to learn more about SMS, how landline SMS can work. If you could just let us know where can people go to learn more about Operator or follow up?

Binh Ly: Yes, so Operator is, like we mentioned before, it's kind of white labeled and hasn't been, you can't sign up for Operator yet, but that will range in 2025 as we add sales staff to go out and evangelize some of these developments with the rest of the world. But I'm online at Binh Twitter and Instagram, just BINH. And then in 2025, you can go to Operatorapp.com to sign up, to start.

Richard Moot: Alright, well I think people should definitely go and check this out. For all of those listening, if you've got a project with Square, we'd love to hear about it. Please reach out to us on Discord or on X at SquareDev and don't forget to subscribe and check out developer.square.com for more. Keep building and catch you next time.

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 few years because initially it just seemed like, oh, it seems like such a simple straightforward tool. And when you're a developer just trying to say like, oh, I'm just trying to build and test my webhooks and I have to expose those to the platform that's going to call them if I want to do any kind of local testing. And then you just go, okay, that's it. But then I think there's other people who just went like, well, what else can I use this for? And you really start, tell us a little bit more about how those use cases started to really evolve. Because I think it's very interesting to sort of understand, yeah, I'm punching a hole. I can do Webhook testing or I can let somebody see my local development, but this ability to communicate within the same network in a secure way is pretty common for a lot of really large apps.

Peter Shafton: There's a lot of things that are really interesting, and it paralleled a lot of the story of the time I had at Twilio as well, which was if you build a platform, it was sort of built of these basic primitives, but it was programmatically driven like you had an API to manipulate it or set it up and you could scale it from anywhere. It enabled all these use cases you're alluding to. And so that is sort of the fun of what Ngrok has become and continues to become in the simple sense you're testing, but if you think about it, at some point you have to handle webhooks in production. Often you're connected to Square, you're going to handle webhooks from that API, they have to go into your infrastructure. You want to manage them and why stand up another infrastructure to do that?

The benefit of being able to shut things down or keep them up or scale them. A lot of the things that we've built and continue to build echo the problems I had at Twilio, if you think about when you first put an API on the internet, you're like, well, my first problem is just making it accessible. You're like, great, I've got it up there. People can hit it. This is wonderful. And then there's sort of that uh-oh moment where you say, well, wait a second, a lot of people are hitting it and I have to probably rate limit them, right? I don't have capacity to handle all these people and I don't want to throttle my request to one customer because another customer doesn't have enough bandwidth. And so I need rate limiting. I have to rate limit by customer ID, and maybe I have some customers that pay me more and I want to give them more capacity.

And at Twilio, I had to build an API gateway team. I had to build a team that could do that. And then the other problems you start to have is, well, gosh, I have customers that aren't just in my city. They're actually hitting me from all over the world. And the latency some of them are getting is quite bad because they're coming in from Asia or from Europe or from somewhere else that don't have infrastructure there. And so at Ngrok, we literally had infrastructure to support that so that you could go from just running it locally to running it remotely. But I think the fun part about having a platform like that is, and I think you alluded to this, is people just auto discover it. I'll give you an example of a story. There was, and I won't tell the name of the company just to make it more fun, there was an IT guy who works at a company that sold a food product and expected to receive mobile ordering, but they didn't have a mobile ordering infrastructure yet.

What they had was a bunch of brick and mortar stores people would come into and order things like coffee. And he was tasked with trying to figure out a way to make this work, and he grabbed the Ngrok Executal and stuck it on his point of sale system that was running Windows. And lo and behold, not only did that give him an API web endpoint that he could hit, but it gave access to his database and he could look at the end of day sales for the store location by pulling down the database at night and he could push updates for discounts and product in the morning. And lo and behold, he could drive all them over. And he sent an email to Alan. He said, I just did this thing. I downloaded Ngrok, I can do this. And Alan said, sure, it wasn't what I thought about when I first built it, but it works for that.

And lo and behold, that store grew to 28,000 locations and that company does millions of dollars a day of mobile ordering across Ngrok because those store locations, if you think about it, have home networks like you and I do. These are not, they often use some cases, a cellular connection. In some cases they were using AT&T or Comcast or whomever. And so he needed to be able to have a reliable network connectivity. Then he didn't want to go and update the routers on each of those locations or convince the IT team. So it was sort of a fun, interesting use case. I've seen people control smart mirrors, remote control boats and planes that they remote into and give access. And these things just have cell cards in them. They're going over the cellular network. So it's sort of fun to see both the things people have done that are hobby and interesting and unique, but also the places where people have used this and built entire businesses on top of it because connectivity was key for them.

Richard Moot: Yeah, I mean, it is one of those things where it's like, I think it's like when thinking about the layers of an app, and I think it's often that the network layer is one that, I mean, I know when you're dealing with really large scale apps, you inevitably always think about the network layer. But I think when we're first building out a web application, we kind of just take the network layer for granted of just like, yeah, it's going to be exposed in some way, and then we have an auth model. But there's so much more that you can do there that, I mean, I'm just imagining that with Ngrok, that it's so much more possible to say, yeah, we have a private network that most of our application infrastructure is communicating on. And occasionally it would be great if for something that's say existing in a more hostile environment, say a storefront with their own networks that are connecting to devices, we can only trust so much.

And it's like, but you have this one machine, the point of sale where you're like, I want to be able to punch a hole for just this specific device and it can talk to my private network through this particular endpoint that I've created here for it to communicate. And that is actually, not a lot of people have to deal with this, but I feel like it's one of those things, it suddenly goes, oh, this makes this so much easier than having to think about mobile device management and certificates and certificate pinning and all these other security mechanisms that you have to employ when you're dealing with all of these different devices.

Peter Shafton: You're exactly right. And it's interesting because we really saw, what we have seen is about four or five use cases or traditional, the device gateway, that sort of connectivity to remote devices. An interesting one, an API gateway has been another interesting one. I'll give you an example. When I was at Twilio, we acquired two companies that a lot of people had heard of. One was called SendGrid that sent email, and another was Segment that did data processing. And imagine you acquire companies that are fairly significant. They each have significant data infrastructures. They already had a footprint in GCP or AWS or in SendGrid's case on-prem, like a private data centers in Colorado. And when each of those companies set up their infrastructure, they created private IP ranges. And when Twilio acquires them, gosh, we should have a single API, right? You should be able to send email to SendGrid via the Twilio API. And you think about that, well, that's hitting the Twilio endpoint. And you might say, well, okay, all we'll have to do is things that are slash twilio slash email should go here. How do I do that? They have their own ingress points, they have their own, and they're in a different environment. I can't just take the DNS that goes to one place and send it somewhere else. I can't split it in the middle and say things that are -V1 should go here. All the complexity of the network and the great intelligence we had ahead, we had totally overlapping private IP space.

So I couldn't just route for one infrastructure to the other because the IPs were redundant that it was not clear where I was going with the traffic. And so Ngrok, if we had had it at that time, would've enabled me to basically say, Hey, listen, I want to shard this anywhere I want. The network is effectively as programmable and configurable as the other parts of my software stack are. And I could have said, Hey, my V two version of IAPI, which will be somewhere in this path, is going to route to my new infrastructure that guess what I've stood up in the Azure Cloud or things that match these headers or these parameters, I want to send this other way. And so being able to do that through a programmable network interface was really what is powerful and interesting about Ngrok. And there is an infrastructure today that we built that basically uses traffic policy.

And the idea is that all of the information that's available to you on an inbound request can be used in rate limiting, in routing decisions, in decisions as whether to force somebody through authentication flows. And that allows customers of ours to solve problems we hadn't even considered today. So we see customers who are doing exactly that, sending some traffic to different infrastructures to challenge certain users with authentication or add special headers or modify their payloads either inbound or outbound based upon what they see. And one of the fun things we worked on was to scrape the web for public data sets about IP addresses. So you know, have geo-data, everybody's kind of familiar with Maxmining, and other places, well listen, given an IP, I can figure out the country. But it turns out people publish the IP addresses of TOR exit nodes, they publish the IP addresses of block lists or the ranges of IPs that belong to Square or Amazon or Microsoft for their services.

And you can annotate those IPs as they come in and you could say, Hey, listen, not only am I going to validate the square authentication token and signature of their webhooks to know it came from Square, I can also tell, Hey, it came out of a Square IP address. And so it's really hard to spoof this and all of that information. Not only do we use ourselves to protect our platform, but is available to our customers to use in really interesting ways. And so that's been really fun to see. Some people are used to blocking countries, but you can imagine doing things like when a request comes in, I can look up based off the authentication, which customer that is. Are they a VIP customer? Should I send them into another infrastructure? Should I provide to them a different rate limiting rate? And that's been sort of fun to see for us. It's a platform for everybody else. It's a playground.

Richard Moot: Yeah, no, totally. And I mean, I feel like one thing that is interesting about what you've sort of touched on in there that when I first joined Square seven years ago, one of the first things I did was I was immediately starting to build something that's going to be making use of our webhooks. And as my knee jerk reaction was to use Ngrok to expose an endpoint and then register that and then start seeing my feed of events happening in the system. And one of the things that I think most people might not understand at first, because when you first say, Hey, we're going to punch a hole in the network and it's going to be publicly available, you're exposing something onto the internet. I think that the reality is it's more secure than you might think. It's, and I'd love to touch on the ways in which Ngrok is sort of, I don't know if I'm stretching and saying secure by default, but I think what ways is it sort of secure by default? So when people use it, they're not necessarily worried like, oh my gosh, somebody's going to be able to call into this and start seeing stuff on my system.

Peter Shafton: Yeah, there's a bunch of different levers you have. So you think about it, and it's interesting because it kind of depends on people's, you see in the old days or the first early days, you could have an HTP or TCP endpoint, which kind of meant you could basically have an IP domain name and a port that was open to everybody and well, that's very powerful. If you're fronting a thing that you just want to get online, we already know about HTPS and TLS and SSL as a mechanism to know at least you're talking to the thing you think you're talking to, right? And part of that is, is there a certificate for it? Is that certificate up to date and valid? And if you've been running network infrastructures, sometimes your certificates expire and you have to renew them Ngrok takes over all of that part of the management, right?

The second thing you can think about is the traffic transiting the Ngrok network secure in another way, sorry, secured through TLS, but where is TLS terminated, right? Do we terminate on our edge? Does it need to be terminated all the way back at the service that's actually handling it? And at Ngrok, you can choose where you want. So we have customers that do zero trust, that basically we don't see their certificates, we do not terminate the traffic, we route it through and it's up to them to terminate. But in the world where, and there's a bunch of protections you can do with that.

One example is you might know the IP addresses, these requests are coming through and you can whitelist those and say, Hey, listen, these are only IPs I'm going to allow or there's a set I want to deny. And with the IP intelligence, you can effectively say only from this ASN or other pieces that make it even more flexible. There's DDoS protection if you think about it. It's like, okay, put this thing up. Am I going to get hit with a packet flood? And so we have a firewall layer that does detection of SYN packets and it does it globally. So it has to basically know, okay, maybe it's an attack that's actually being spread wide enough across the world that any single node doesn't kind of see it, but in aggregate I do. And so that is a piece that we have both to protect ourselves and to protect our customers.

The other use case, we talked a little bit about authentication, you can turn on authentication and say as an example, Hey, I want to use Google Auth and they have to match this domain as an example. We use Google Auth for Gmail and other pieces. And so if you don't come in with an Ngrok.com domain and authenticate through Google, I don't let you in, but you can imagine you can also use a subset of emails within that domain. Maybe it's just mine, maybe it's just me and you, Richard. And so that's another way. And then when you're doing machine to machine communication, obviously the machines are not going to authenticate through that, but they can do mutual TLS and in that case they have a certificate that they have to mint on the client side and validate that that's coming in. And so all those are the building blocks that kind of allow you to secure the edge that you have.

And then the last piece of it kind of becomes observability. And so if you've used Ngrok in the early days, you kind of remembered you could hit port 40-40 on a local port and you'd have this browser window and the browser window showed you, Hey, this is the traffic. Not only could you see it, but you could actually kind of replay it. So as you alluded to, somebody was testing a webhook, you're like, great, my code is broken. Can I just replay that? And you could, we've moved effectively all of that logic server side. So now if there's a team of developers, you can see all of the traffic that is coming through, you have the IP intelligence on that data too, and you can kill sessions and block sessions. So if you're doing authentication through us, you can say, no, I'm going to take Richard's token away.

And any track that he had will cease to be functioning right now. And I can see the history of what he had done. And all of that was pieces that we thought were really interesting. And then conceptually, you can replay through that same interface. And all of these were built effect to solve the problems Alan and I and others we're seeing in our history over the last 30 years. But the stuff that developers are coming to us and telling us like, Hey, I'm seeing this. I need you to be able to do this. I need you to be able to scale this way. That's really the power of the platform.

Richard Moot: No, I mean it's really impressive. I mean, there was several years ago when we had acquired Weebly, and as part of trying to get them integrated into the rest of our infrastructure is one of the primary ways that they would communicate was through our own APIs. So as you could imagine, one of the things that most of the engineers working on that integration process was having to integrate with our webhooks and the go-to thing was like, yeah, you spin up Ngrok. And then once we were able to actually get it working within our networks, it was a more secure way for them to be able to just spin up, start seeing feeds and building into our systems to sync databases between Weebly and Square online. But yeah, so when Weebly was onboarded, I mean one of the things that we pushed really hard for was having better tools for doing these integration processes.

And it is really great to finally be able to use this more predominantly and also recommend it to people coming onto our platform externally. So third party developers who are like, Hey, I really want to build an app on the Square developer platform, our top recommendation is usually to just use something like Ngrok to be like, if you run this, you can start building against our webhooks. I know previously we've all probably used, what was the name of that site, I want to say it was website.webhooks or webhook.website, or it was basically,

Peter Shafton: WebHooks.fyi

Richard Moot: Yes, where you would just can drop it in and you can see events come through. But the problem that I've always had with that is, yes, I can see the events coming in, but it's not running against my code. My code is not reacting to any of the webhook events. And so I'm not seeing the additional parts of this of actually seeing is my code that relies on the Webhook events working appropriately. With that, I also wanted to just plug one other thing that I'm excited to try out. I will be forthright in that I have not tried it out, but the SDKs that you have for actually using Ngrok in application code, which I will admit it kind of hurts my brain a little bit to think, okay, so the code itself is not going to be aware that it's actually really tunneling out traffic and responding to stuff through here. But tell us a little bit more about these wrappers that you have to enable that kind of integration directly within somebody's code.

Peter Shafton: Yeah, there's two fun pieces here. So the first is you alluded to, most people who are familiar with Ngrok or have used it in the last decade are used to downloading an executable. You're like, Hey, did you download Ngork? And that's this traditional thing. It's a separate executable startup. For those of us developers that might not be a big deal if it turns out you're building with Ngrok and you want it to be part of the infrastructure, you're standing up sometimes you don't want your customer, maybe as you all alluded to, you're building a Square app. You don't want to tell your customers, Hey, go download Ngrok to use this. And so we built SDKs in a bunch of different languages, Rust and Java and JavaScript and Go and Python that you can just build the capability. And what Richard is alluding to is we did it in a way that effectively in most of your code, you're used to standing up like an HTP server or something like that, and those servers are often based on basically a TCP socket, a listening socket. Effectively they open Ngrok for all intents and purposes, looks like a listening socket. So effectively these libraries provide a socket that just can be handed to the HTP server objects in Java and Python and Flask, Restful and all these things that the framers you're used to playing with. And so your code isn't aware and conceptually could choose on the fly to be Ngrok enabled or not. And the interesting part about that is often when you're running locally, you have Ngrok there because otherwise you're not accessibly can't get requests from the outside world. And when you push to production, the incentive is like, well, now I'm re-architect the thing. I'm going to put engine X or some other form of ingress in front of it and talk to the IT team to get it all set up.

The answer is, if you built it this way, you don't have to do that effectively. You can just push the executable up and it is actually internet enabled at that moment because it is an outbound socket that's powering it. And so that's really cool for the SDKs and the use cases that people ship it. There is another part of that story that I think is really fun and interesting is a PCLC called the Ngrok Kubernetes Operator. So in this world, you basically have a helm component that you install, and there effectively is a service within your Kubernetes cluster that acts as the ingress to that pod. And so when people are used to using Kubernetes and using the Gateway API or setting up an ingress or load balancer, they basically leverage Ngrok to do that load balancer. So now you don't have to worry about, is my Kubernetes infrastructure running in AWS and I should use ALBs and NLBs, is it running in Azure or GCP?

Is it running on my local machine? So you can basically have ingress to services and the same definition of endpoints. The other fun part about that mechanism is you can effectively tunnel traffic from your local machine into a Kubernetes cluster. So imagine you have a Kubernetes cluster running in production or in staging and it has a bunch of services running, but one of them you want to iterate on that workflow normally would look like I work on my code, I write the Docker file, I deploy it to that cluster, and then I test it and realize I broke it again. In this world, effectively that service endpoint that's in that cluster just tunnels the traffic through to your local machine. So it's sort of how you were using Ngrok today to say, my service will be visible on the public internet. Now you can say my service would be visible in a Kubernetes cluster, and that allows you to do things what we call private or internal endpoint.

So if you think about, Hey Ngrok, I put this thing up, it's on the public internet, you can actually say, Hey, Ngrok, I put this thing up, but it's actually not publicly accessible. It's only accessible from within this Kubernetes cluster and other services and pods within the cluster can hit it, but people from the internet cannot. And if I want to expose my local machine, then we manage the mutual TLS certificates that guarantee that the traffic coming into hit your machine is actually coming from that cluster. And so those pieces are really interesting building blocks as well because we see a lot of people who, their deployment model actually is Kubernetes, right? They're actually deploying pods, they actually workflow, and this works much more elegantly for that use case. And so that's a piece that's been fun as well, and it works in a similar fashion to how you think those SDKs work. And guess what? It's actually using our Go SDK, right, so it is both a consumer and Ngrok. The fun part is we dogfood everything. So our API, our website, our docs pages are all fronted by Ngrok. So they are really limited and protected and globally redundant by our own platform. It's a little meta if you think about Ngrok's behind Ngrok, but it is.

Richard Moot: But I mean, I find it hard to find a better way to really iterate because on a product, because you're customer zero constantly. And so if it works, it's working for you, it hopefully is working for everyone else and you can continue to improve and expand, but you're still serving customer zero, so you're not breaking yourself otherwise you're going to be in a lot of trouble.

Peter Shafton: We had a funny story. So we put the website, we had a lot of the components behind Ngrok already, the API and the dashboard. We hadn't yet put the website Ngrok.com. And when we did that, four hours later we got hit by a DDoS attack and we were like, okay, this unexpected. At first we thought we had done something wrong in the deployment. Turned out, no, we were getting hit and we looked in our observed, really realized the traffic was coming a lot from block lists, a lot from Russia and China. And so we said, well, okay, we flipped on a bunch of the traffic policy protections to block tour exit nodes, to block things on firehole or other block lists and Russia and China explicitly. Four hours later we got hit by another DDoS attack. And lo and behold, at that point, it had no effect on our infrastructure.

So it was sort of fun to see how quickly we got inside and I would say it was about 7,000 times the amount of normal traffic we see on the website. So it was clear as much as I know Ngrok is popular and I love to see spikes of traffic, that was not something that we expected, but it was a funny use case. Normally that would've taken days to figure out how do we thwart this, how do we spin up enough infrastructure to protect it? But the pieces were there, we just had to turn the ball.

Richard Moot: Yeah, no, I mean that's amazing that you can be able to react so quickly and make those changes on the fly like that and then just immediately see a result of like, oh yeah, we see the next wave coming and suddenly we're not affected anymore.

Peter Shafton: Yeah, no, it was fun. It was cool. I mean, as much as it's not fun getting attacked, that was fun.

Richard Moot: Yeah, I mean I think with time we can realize it's more fun, I'm sure in the moment it's like, no, we got to get this problem solved and we got to get it solved fast. So I think the final thing I want to touch on is sort of switching gears a little bit, as succinctly as I think we can try to do it with the time that we have remaining, is I'm curious how things have changed for you over time as you've gone through the years of as an IC engineer moving more into architecture and now as the CTO, how has that evolution sort of changed for you in terms of how you approach engineering problems? And tell us a little bit about that.

Peter Shafton: Yeah, it's a good call. I mean, I think as an IC, you're sort of in learning mode. Everything you're doing is your first time maybe, and your goal is to absorb from everybody around you. There's no illusion that you yourself are going to build everything. You're just going to learn from the people around you. And I think as I've grown, that's what I've done both learn how do you grow an organization and how do you grow an infrastructure and what kind of things, what is important when in a lifecycle? When I joined Twilio, there were 20 people, and when I left in 2022, there were 8,500. And so there was that arc that was how does the org grow over time? But it is also what decisions do you make as you're building the infrastructure? And I think those are the pieces you learn. How do I build an organization?

What kind of engineers, what skillset sets should they have early on? What do you want to tell them to optimize for? When you're building a product like Twilio or even Ngrok, the reliability at scale is very, very important. I remember engineers coming to me and saying, I want to build this in Ruby, it'll be much faster for me to execute on it. And I had to tell them at Twilio, you can't build in Ruby because this has to scale for hundreds of thousands of phone calls, calls we build in Java or C, Go so that our customers can write in Ruby. And so there was that part of a learning of which, but that's not always true, right. There are some things that's better to just build quickly in a scripting language because you don't yet know if it's a good idea. You don't yet know if it's going to work, and so Ngrok has been interesting. For me, it's a little bit of a chance to step back into technology and into things with the foresight of what will happen five years out and seven years out, what would it look like if our traffic quadrupled or we land a single customer that's bigger than all our customers. And I think those are the learnings that allow you to make some decisions that you know you can revisit. You'll hear people use the word two-way doors, and if it's a thing you can kind of back your way out of in a reasonable amount of time, then don't wait and think about it a bunch. Just do it.

Richard Moot: Yeah, just go.

Peter Shafton: And if it's a thing that like, okay, this is going to be a really expensive decision if I'm wrong later, those are the ones you sit and haggle about because as an engineer, especially building a company, time is the only enemy you want to move quickly.

You want to try things out, you want customers to get, they love that, right? That sense of, and I see this at Ngrok and I saw it at Twilio. Jeff Lawson, who was the CEO, used to joke. He's like, I want to be the train that's a mile ahead and pulling away. And that is very much true of a startup. You want to be building features and capabilities and listening to your customers iterating quickly. And so as a CTO, my job is to keep priorities front and center to the engineers and let them know this is a thing you can do fast and this is a thing you gotta think about, but that part is fun.

Richard Moot: Yeah, I think one thing, and tell me if this sounds true to you, is as time goes on, you start as an IC, you're focused on the engineering problems of what code should I write, what language should I use? And then as you start going further and further in the architecture, it's like, oh, well what services and what should the architecture of this be? But I feel like there's this moment where you start realizing the biggest problem to solve in this equation is the human element. And you have to start figuring out how do I actually structure teams so that they work together better and organize them in ways that they can focus on the most important problems? I feel like sometimes people can get really hung up on like, oh, but if I write it in this way, I can make it work in so many other ways.

And I think you touched on it right there of saying, well, we can't write code and Ruby because as we go through the abstractions, it's going to be too slow when we have a customer down over there writing stuff in Go. And so we need to be in the fast, reliable, low level type thing because somebody else is going to abstract on top of it. And that requires that human element of helping people to understand there's a bigger picture and there's layers to this whole thing. And how do I organize people to make them come together in the right way?

Peter Shafton: I mean, you're very much right. People love to think of software as this technical endeavor that you can use AI and build your way out of that humans will no longer at some point be necessary. And the reality is these systems are still very much human systems. And so you have both the learnings of the people you hire, which experiences did they have that you didn't in technologies or solving related problems, how do they interact with each other? Who is listening, who who's interacting, and what gets them excited? An engineer's going to do a good job if they're excited about the problem they're solving. They like the space they're working in, they feel like they're doing something that they themselves would've used or leveraged. So it's fun to work on developer tools. Your customer is probably your friend or even you, which is ironic. And then the second motivation is do I feel like I have freedom to kind of solve within some confine as an engineer myself, there's an instant ability for me to look at something and say, I know how you should write that, but I know as a leader, I can't do that because that's disempowering to engineers.

And so they need to be able to be given the context of what has maybe a suggestion of where I've seen walls historically myself, but then the freedom for them to think and solve the problem in their own way. And that's what builds really powerful teams as leaders, as ironic, it sounds your job is to make yourself obsolete and unnecessary, and that's where it has to be. Allowing smart people to run and grow allows me to step out of half of those problems, right?

Richard Moot: Yeah, I think what you said resonates. It just resonates so much with me because I had an engineering manager that I worked with previously, and I had discovered this architectural problem that I realized it was like we were seeing reflections of it in different issues that were arising, and I finally was able to go like, no, this is the root cause of why we're having this problem, and it was this inherent design problem. We're just actually designing these models in the wrong way, and I figured it all out. I wrote it all up, and I even had several proposed solutions, and one of the things that he said to me, which is what you just said right now, is that even though I figured out the whole problem, I'm not going to win people over or get anybody wanting to work on it if I tell them the solution that they need to go implement.

I just need to present the problem as well as possible so that a team gets to go and grasp the problem, see things that I didn't see, but the joy as an engineer is coming up with the solution, and that's how you empower and allow people to grow is that you might see like, hey, there's this huge problem over here. I'm not going to solve it, but I am going to figure out what the problem is and put the right people on it, and then they're going to go figure out how to solve it. That was a huge unlock to me of it is not enough to just be right. It's not enough to just find, oh, there's this thing wrong. You have to figure out how am I going to rally people together to believe that we should address this problem and get them to want to solve the problem and show why it's going to be valuable. Those are all the human part of engineering that it's a form of problem solving, but it's not with code.

Peter Shafton: Yeah, this is the hardest part about going through the engineering ranks. You miss the days where you were coding the solution. You have to be okay with that. You have to get your satisfaction from some other place. It's not going to be you writing all the code and solving all the problems yourself. That is not how you grow.

Richard Moot: Unfortunately. Well, and I've actually, I've heard, I don't remember where I came across this, but it was an interesting take on why the problems that you solve actually never get easier. Because as you get better and better at solving these problems, it's only the most difficult problems. As you've grown as a leader, you go further up and you're zooming further out, and the problems that eventually make their way to you always feel like the hardest problem. And it's like, well, for good reason because you've built these teams that are going to solve the easier problems. So only the hardest problems are coming up to you, and those are the ones that you're having to solve.

Peter Shafton:No, you're exactly right. It's funny, but true.

Richard Moot: Yeah. It's one of those things where it kind of hurts because you go, it's never going to get easier. It's actually supposed to just continually be just as hard or harder as it goes on.

Peter Shafton: Yeah, somebody told me as a CEO, you only get presented the hardest problems at the company. You have to be okay with that.

Richard Moot: So I see that we're pretty much up on time here. I want to thank you again, Peter, for coming here teaching us a little bit about Ngrok. I'm super, super excited to go and try out the TypeScript SDK, and my dream is to actually put this into a CLI that somebody can use and immediately spin up test their webhooks with Square. If people are interested in learning more about Ngrok, what is the best way for them to actually go and check it out and try it?

Peter Shafton: Certainly, Ngrok.com is easy. You will find our docs. You can just search for Ngrok SDK if you want, pick the library of language you want. They're available on GitHub. So our GitHub repo under Ngrok also has all of this code. These are open source, so you can grab 'em and look at 'em if you want, but pull 'em down and play with 'em and give us feedback, right? They've been out there, they're heavily used by a bunch of folks, but it doesn't mean there aren't places to improve and make them better. So definitely reach out, let us know, and we have support at Ngrok.com if you run into challenges and you need help, and I might even be manning that support some of those days. So you could talk to me.

Richard Moot: Excellent. Well, you might be hearing from me. If you've got a project with Square, we'd love to hear about it, reach out on Discord or X at SquareDev, don't forget to subscribe. Check out Develope.squareup.com for more. Keep building and we'll catch you next time.

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 extensions, like the developer extension, computer controller memory, and then you have the option to reach out to other extensions or even build your own custom extension and plug it in as well.

Richard Moot: Gotcha. And so the one I know that is the key one that's included with GOOSE is the developer extension. That's what does all the basic developer actions that you would think of, and then computer controller, that's kind of the one for doing more. Maybe tell me how is computer controller different than developer?

Rizel Scarlett: Yeah, so developer extension, it has the ability to run, shell command Shells scripts, so it'll go ahead and you say, create this file. It'll say touch create this file. It'll add the code for you in the places that it needs to. Whereas the computer controller, the intention of that is that it's supposed to be able to scrape the web, do different web interactions, be able to control your system, and then this is all automating things or even do automation scripts like you had mentioned before. These are all automating things for people who may not feel as comfortable coding, but they want to automate things within their system. That's the intention of the computer controller.

Richard Moot: Gotcha. And I'm curious, as this has been out there and having two different versions, I don't really want to say two different versions, two different ways of interacting with Goose with the desktop and the CLI, the desktop is really great for those that might not be more comfortable opening up a terminal. Have you seen folks coming in who are maybe less technical, who've been trying to actually use it through this way?

Richard Moot: Just curious all the various types of people that have been coming in and adopting or playing around with Goose.

Rizel Scarlett: Yeah. Well first side note, even though I'm comfortable with the terminal, I like using the desktop. I just think it looks more visually appealing for me. But I have seen people in Discord, I think there was a set of health professionals that they were part of a hackathon and they were using GOOSE to build whatever their submissions were. I don't know exactly what, but I thought that was interesting that they're going to build tools and submit to a hackathon even though they're not solely software engineers. So that's one example.

Richard Moot: Interesting. So it's been really interesting seeing all of the different ways that people have building on it. And I mean it's been pretty exciting seeing how people have really started to just start using it. One of the things I thought was interesting was it seemed like initially some people just didn't quite understand, and I'm sure there's just work to be done in general, not just for us, but for people trying to use agents that I think a lot of people have assumed initially like, oh, where's the LLM? Why is there no thing bundled with this? I feel like I can't do anything. And we're like, no, you have to connect it to something else. But the one that got me the most interested was trying to get it to talk to a local LLM. And so I've tinkered with this over the past couple of weekends of running a llama, getting a model running. But I will admit that I hit my own endpoint where I was like, okay, I have an LLM running, but it doesn't really work with the tool calling.

I think that's something maybe we talk a little bit, what is it tool calling is like that thing that how it uses the extensions. But maybe you can tell us a little bit about what is tool calling and why is it so important?

Rizel Scarlett: Yeah, I mean a lot of things you said that I want to touch on. First off agents, I think from not understanding how Goose will work, I think agents are still a fairly new concept and everybody is saying, oh, this is what an agent is, and they all have their different definitions. So when I first used Goose as well, I was a little bit confused. I was like, what is this supposed to do? I think similarly when Devin came out, people were like, this is not working how I thought it would. So that just happens. But yes, open source using Goose with an open source LLM is so powerful because Goose is an open source local AI agent, and then you have the local LLMs that you can leverage it with. So you can own your data and you don't even need internet to have the LLMs running.

Rizel Scarlett: But it is difficult. And like you said, tool calling. I am excited about this. I just came off of livestream with an engineer from alama. First off, the way he described tool calling was interesting. He said, it's not how I thought of it, but he was saying it's kind of how the LLM learns what it should or can do. So it's kind of like, oh, I have these set of tools here. Which one should I use for what I'm going to do? So let's say you told somebody I want to look up, or I want to go on a flight to, I don't know, Istanbul, I don't know why I picked that. What flights are available, how long will it take me? So then

Rizel Scarlett: An agent will be like, oh, tools do I have? And it might say, oh, I have a find flights tool and I have a MAP tool and I have this. So in order to find the flight, it might use that flights tool and in order to figure out the distance, it might use the MAPS tool or something like that. So that's kind of how it would work and it, I think it refines the results that it would have rather than looking at all these different things, it's like, okay, I'm going to use this particular tool and get this particular output. I learned a lot about open source models working with Goose or any agent, you have to, it's a lot of different prompting tips. First off, it's best probably to ask the open source LLM what access or what tools do I have access to? Because Open Source L LMS are much smaller, so they have a smaller context window and they're not able to interact with an agent like the cloud ones. They have so much more larger content with those, so they're able to take in more memory and stuff like that. So it's like I only have this amount, so let's get to what we need to do. Show me what tools are available. I'll grab that particular tool that's needed. And then another suggestion for when building an agent, and I think Goose will probably go in this direction to help improve the experience of working with open source. LLMs is having structured output. So the structured output would tell it kind of what it can and can't do and how the format of it would be printed out.

Richard Moot: Interesting.

Rizel Scarlett: I know I said a lot.

Richard Moot: No, no, no, that was great because it had me wondering with certain, when I started messing with one of the open source models and then I was trying to use it, I think the open source model I found was from somebody within Block who actually tried to fine tune a version of Deep Seek to be like, oh yeah, this one will work with tool calling. But then I think I was realizing I still needed probably an extension for it to actually make use of it because, and I think that's the part where maybe I misunderstood how these things work, but I'm sure that there's things that Goose does that it maybe tells the LLM almost pretext that is sent in the context. So before you even write your prompt, it has things that it will sort of give to be like, Hey, you have tools available to you or there's these tools. And so you might not see that in the terminal or in the desktop, but it's actually sort of adding these things at the beginning or maybe the end of the context to say, Hey, here's some tools available to you. Make sure that you use them. I'm oversimplifying, I'm sure, but that's kind of how I'm guessing that that might work.

Rizel Scarlett: That's how I seen it. So I looked at the logs because I wanted to really demo. I had no clue coming back from maternity leave that there was this little not necessarily working or trying to say obstacle, a little obstacle to work with open source LLMs and the agent. So I was like, oh, I'm ready to go. I'm going to go ahead and demo this live. And I realized, oh my gosh, it doesn't work perfectly. So I was looking at the logs and it does have a system prompt in the beginning where I didn't use deep seek like you did. I used Quinn 2.5 and it'll say in the beginning, you're a helpful assistant, you have access to computer controller and developer extension, and you can do this, this, and this. I think another limitation is our hardware as well. So even though it's on a local device, and I mean it's supposed to work on a local device, our local devices might not have enough RAM or memory. I have a 64 gigabyte, but the person that came on the live stream with me, he had 128, so that worked much better. So that might've been a limitation for you as well. And even though the system prompt already told it what extensions it would have, we both had a better result when we started off the conversation saying, Hey, what tools do you have access to? And it probably referred to the system prompt and then went ahead and printed it out to us.

Richard Moot: Yeah, yeah. And when I was tinkering with this, I actually was putting, I took an old gaming laptop basically set it up with, I converted it from Windows to Linux and it works reasonably well. It's still a little bit too slow for what I would actually want to be using it. So I have my regular gaming computer that I've actually, so when I want to mess with this, I actually just run a alarm on that when it's on, and then I use it as sort of a remote server and it's usable at that point. I think tokens don't fly through with the cloud LLMs. I mean it's still kind of slowish, but it's usable. And I think it's really fun to try out the local LLM stuff just, I mean as a developer, it gives me this mild peace of mind of my data's not going anywhere, so it feels safer somehow.

Rizel Scarlett: Yeah, you're such a tinkerer. I love that.

Richard Moot: Oh, I tinker with way too many things, network configurations, running clusters locally on my home lab, all stuff that I don't think I've ever used professionally, but I just love learning about this stuff.

Rizel Scarlett: I love that. I love that.

Richard Moot: So that kind of leads me one other thing that I'm interested in and I want to clarify. Not going to try to go into the realm of tips about using LLMs in augmenting our development workflows. And I think we're both in a similar camp of being in Devereux. It's really fun to just be like, I'm going to use this to start a new project or work in a language that I'm not usually familiar with and maybe see what I can build. I'm curious in terms of unprofessional tips, just things that you're sort of learning intuitively as you interact with it, how has it changed for you when you first started working with LLMs with doing software development to now? Have you ever noticed how you approach things a little bit differently?

Rizel Scarlett: That's a really good question. I haven't thought about it. I know when I, let me think because when I started using, my first experience with LLMs was like GitHub copilot and I made this whole playbook for people to use. I was like, make sure you have detailed examples and stuff like that, but how has it changed now?

Richard Moot: I'll give you an example. So to maybe help get your creative juices flowing on it. I know it's kind of coming out of left field, but when I first started using LLMs, I would just be like, Hey, can you build me this particular function? I think my first interaction was probably similar when I first used GitHub copilot and I was just doing tab completions and be like, I thought it was really cool that I could write a comment and describing the function that I want, and then I would start to write the function and then it would complete it out, and then I'd maybe have to edit a few things. And then once, I think it was when I first started using Goose is the first time I really tried one shotting things to be like build me an entire auth service for this app. And then I have now kind of swung back the other way a little bit where I tend to want to do a little bit more prompting when I want to do more of those one shots.

Rizel Scarlett: Interesting.

Richard Moot: But I've found that if I scaffold out half of it, maybe create the initial files and a single function or something and then it kind of fills in the rest, I have found it tends to work a little bit better. There's a few other tips that I can go into, but I don't know if that sort of helps. And that's how I've changed a little bit in how I've been using it because I've found that when you try doing the one shotting, it can just be too much that it's trying to do. And I feel like also it's too much context, especially I think one tip that I've heard continually with Goose and with others have a very clear what you considered a finished point and then move into a new context. Otherwise you can kind of go off the rails pretty fast.

Rizel Scarlett: Yeah, okay. I'll say this. I think my experience might be a little bit different just because when copilot came out, I had to demo GitHub copilot. So I was already thinking of, okay, how do I do this one-shot prompt that'll build out this whole thing so that people can be super impressed with me? So I think I was doing a lot of one-shot prompts and I probably brought over some of that learning from there. But

Rizel Scarlett: I think one thing I've been learning with building out the tutorials for Goose is kind of like what you're saying, how do I not let it get the context mixed up but still do a one-shot prompt? Because a lot of our tutorials, it's like we want to keep them short and sweet, so how do I make it do multiple things without overwhelming it or making it just fail? Sometimes it's like, I don't know what you want me to do, or it goes over the context limit. I leverage Goose hints a lot. So a lot of those different, most AI agents and AI tools have goose hints, cursor rules. I think Klein has its own thing as well. I dunno if you say Klein or Clean or whatever, but I dunno.

Richard Moot: I don't know what it is either.

Rizel Scarlett: Oh, okay. But they all have their own little, here's context for longer repeatable prompts. That way I use up less of the context window and I don't have to keep repeating myself like, Hey, make sure you set up this next JS thing. I'm already writing. We're going to use next JS and types script. We're going to use Tailwind or whatever it is, and then I can jump directly into the prompt that I want to do. And another thing I do, I don't know if this is weird, sometimes I ask Goose, how would you improve this prompt? I'll be like, I wrote this prompt and it failed. I'll open a new session. I'm like, how would you have improved this prompt? And it might give me a shorter one. So I don't know if I have these rules in my head, but I kind of just been really, really more experimental than I was in the past, I guess.

Richard Moot: Yeah, I think that's a really good thing to call out. I think that that's something that I had learned over time where even though I try to figure out a way to codify an approach, but I end up realizing these are just, I mean, it's weird. I feel like I'm going to describe this, I am the LLM, but they're tools and then you figure out, yeah, I try this one and it's not quite doing what I want, so I'm going to go try something else. And then I think what you said there was one that I've even tried and I didn't really even think about is so go, sometimes I'll switch LLM providers and I'd be like,I'm trying to do this over here and it's not working, and I give it, it gives me something else as a different context. I'm like, well, let's try and see if I feed that back over here, if that gets me the result I'm wanting. And so yeah, I think that's the biggest importance right now is to just be continually experimenting with it because I think as time goes on, we're going to end up learning different, I don't know, heuristics of shortcuts of trying to get what we want done. Sometimes I really like doing the one shots and then other times I'm like, I maybe scaffold something out and then I'm like, I'm just going to progressively iteratively work through this because I don't want it to. I think when I was trying to have it build an off service for an app, I was just too worried about it in one shoting it that I'd have one or two tiny bugs that are hard to catch somewhere.

Rizel Scarlett: That's true.

Richard Moot: And then I was just like, I really don't want to have to be going back through all these different methods and figure out like, oh yeah, I'm actually handling the Jot token incorrectly here. I'd rather just sort of progressively work through and feel confident in it and then be like, okay, I'll give a concrete example of one where I was using this library, I think it was called, it's a one-time password library for node js. I didn't realize that it was kind of really outdated and not maintained, and I implemented it in this app that I was working on, and I realized it wasn't working in the way that I anticipated, and then I was like, oh, there's an updated version of this library somewhere else that's more well adopted and being maintained. And so I was writing out the conversion, but I only converted say one of the sign-in function, and then once I had that one converted, I basically told my LLM, Hey, I'm switching from this library to this library and I've already done this particular function. Can you go through and update all of the other ones to use this new library?

Richard Moot: It did it, I would say nearly perfectly, which is pretty amazing. So I always find there's these little ways that you can be like, yeah, I'm going to do some of the manual work because it'll give me that confidence, but then lean on the LLM when I'm like, okay, I feel like I've done enough that it can finish it for me.

Rizel Scarlett: You know what? Now that you say more, it does make me think, I think I use a different workflow if I'm building versus I am doing developer advocacy work for it demoing or doing a tutorial. So if I am building, you're right, I probably first ask it what is its plan? And I do go more iteratively and I do try to do more of it and then let Goose jump in at certain areas. But if I'm doing a demonstration, I want it to be I do a one shot, which is an art in itself for it to be one shot and for it to be repeatable because AI is non-deterministic. So it could have worked with me once and I tried to demo it and then it never works again, and people were like, this didn't work. But yeah, I think that iterative process is really helpful for me when I say like, Hey, how are you going to go about this? And Okay, I'm going to do this part. You do this. And I always open up a new session when I feel like the conversation's been going long because I think, well, I know it loses context as it gets too big.

Richard Moot: Yeah, totally. I couldn't agree more on that part, and in fact, I've talked with some coworkers who've had mixed experiences with trying to use LLMs in their development work, but I think the thing that we just touched on there is that you have to just be dynamic in how you would use it and understand that you might not use it the same way in every context. And that's definitely what I've also learned when I've built out a fun example app for developer advocacy, just to build a proof of concept for the rest of my team to understand, hey, we can build an example and say next JS or Nest js or view or something, and I'm just using it to be like, Hey, I want you to one shot this out to basically get this mostly working to share something, but that's not how I build it When I'm like, Hey, I want to make this published and official for people to consume to say this is the way that you adopt Square. I would approach that very differently when using the LLM because I'd probably be curating my function signatures a little bit better and like, oh, this looks really good and understandable, and then have it fill out the rest

Richard Moot: Versus just one shotting things. If I was just going to have a one shot things, I would just probably tell people coming to our platform, so here's Goose, here's your LLM, go ahead and one shot your app.

Rizel Scarlett: That's all you need, just Goose. There you go. And I think you had mentioned a little earlier that different, sometimes you'll switch to a different LLM in addition to experimenting with those prompts. Different LLMs have different outputs, and I know on the roadmap we're planning to come out with, I guess different products come out with benches of here's how well this LLM works with our tool, so we're coming out with Goose Bench to say, okay, maybe if you want to do this type of process or build this type of app, then maybe Anthropics models might be best or maybe opening eyes or whatever.

Richard Moot: That would be really helpful because one other thing that I've been tinkering with when I try using an LLM for doing any kind of development work is I've actually, I think there's certain tools, I think one called Cursor New, but it basically just runs you through a series of give the project name a description, what libraries are using, and then it basically gives you prompts to feed in to create certain documents. But what I found interesting was the first one we'll do is say it'll help create a product requirements document, which I think we all call PRDs, but I'm just want to be super clear for people who might not know the lingo. And so I usually have it start out with creating the PRD, and then from there it'll create the code style guide and then it'll create your goose hints or cursor rules, and then I think finally it'll kind of create, I don't know how useful this one is, but it'll create a Read me of a progress tracker.

Richard Moot: That one I've found it's cool, but I've not found it to be totally useful because usually the only time it is useful is when I finally get to say the end of a task where I'm like, Hey, build out, scaffold out the project, and then at the end of it I say, go ahead and go update the progress file to clarify what has been built, what should be built next, and where are we at. Then I use that as the start of the next session of, Hey, check the progress thing to see where we are and what we need to build next, and then work from there. That's so smart. I like that it's really been useful for me, but at the same time, I would say by this fourth or fifth session, I don't know why it starts getting a little, I run into too many errors and I don't know if it's actually specific to the number of sessions or the particular feature that I'm building is maybe too complex and I need to spend more time breaking it into smaller pieces.

Rizel Scarlett: Interesting. I definitely, I want to try that on my own. I didn't think about saving it. I think the memory extension would do that as well for you maybe.

Richard Moot: Yeah, to be clear, I think in this instance I was using something like Cursor.

Rizel Scarlett: Okay.

Richard Moot: But I think I was wanting to try this with Goose. I do have the memory extension enabled, but I just haven't actually gotten to this is sort of what I've been doing on my own at home, but I definitely want to try this more with Goose, especially because Goose has goose hints and I can very easily convert my other rules to work for Goose. But yeah, it's been very useful for larger, more complex things that I've been building, but I still feel like it has its limitations.

Rizel Scarlett: Yeah, I like the challenge of figuring out what's stopping you and how do I get around this? And you're right, you did say you were using Cursor or some type of tool and I heard Goose in my head,

Richard Moot: But yeah, I found it really helpful just trying to just experiment with all the various different tools. There's a lot that I think all of us don't know. There's a lot of stuff to just keep figuring out. I just think that it's weird to say to someone like, Hey, I could tell you the different ways that you could use this, but I think right now most people should actually just figure out how it can work for them because I think if you go online, you can find people on all ends of the spectrum. There's some people they work on stuff that's so bespoke complex that they go, oh, LMS are just not useful for me. They're too bug ridden or the performance of the functions it creates isn't useful. I think those people are one end of the spectrum versus other of us who are like, oh my gosh, I spend most of my day doing architecture stuff like API architecture stuff, and so having an LLM to do the actual implementation of a design is huge unlock because I might come up with a great API design, but then I'm like, this is going to take me so long to code up and an LLM feels like a huge unlock,

Rizel Scarlett: And I really resonate with your point of figure out what works for you. You really just got to tinker with it and be like, I want to get this done and figure out how it'll apply to you because like you said, I could tell people one way, but I might not work in the same way as they do or I'm not working as complex stuff as them. Yeah,

Richard Moot: And not to anthropomorphize it too much, but I feel like it's probably not too dissimilar if somebody just said, Hey, out of nowhere they said, Hey, we gave you an assistant. You'd be like, I don't even know what I'm, you'd at first be like, what do I use the assistant for? Can you organize my files? It takes you a while to even figure out, okay, what can you do? What are you good at? You don't know until you actually have that, and so I think we all have to just start interacting with it and then we'll figure out where we actually want help. You might find out there's certain areas where we don't want it to help us in these things, but we do want it to help us in those other things.

Rizel Scarlett: Get to know the lm.

Richard Moot: Exactly. Yeah. Even the people who think, oh, I don't really like it for coding. You're like, yeah, but you might find out you hate writing super long complicated emails or reading super long, complicated emails. You'd be like, Hey, can you go ahead and give me the TLDR of this or write an email form? It can be that simple.

Rizel Scarlett

Sometimes I use LLMs to make sure my emails sound polite. Sometimes my emails don't come out polite, even though I'm not even throwing any shade, so if it sounds like I'm throwing shade, take it out.

Richard Moot: That's great. I think more people should be using that. Maybe I'm biased because being in the Devereux space, you get to interact with all kinds of folks.

Rizel Scarlett: Yes, that's true.

Richard Moot: And they all have very different communication styles, not to name names. We did have one person who in this square community who I actually was very thankful for them, but they spent so much time just finding every single bug in our APIs, and it drove some people a little bit crazy like, oh my gosh, he found another one, but then I'm just sitting here just like, yeah, thank you. This is free qa. This is amazing. I'm going to keep encouraging this person to keep saying this stuff. I don't find it annoying in the least

Rizel Scarlett: I could get it. I could understand it on both sides. As an engineer, you're like, no more work, but as a developer advocate, you're like, yay, my product's getting improved,

Richard Moot: And it's validating. They love the product so much, they want it to be better, so of course, let's go do that.

Rizel Scarlett: It's true. I love that.

Richard Moot: Yeah. Well, I think we're coming up on our time here. Thank you so much for coming here and telling us a little bit about Goose. I think here's probably a good point for us to sort of plug where can people go to learn more about Goose Blocks Open source or if they want to just sort of follow you to learn more about any of this stuff.

Rizel Scarlett: Yeah, I would, if I were an engineer or somebody interested in open source itself, I would go to github.com/block/goose, and if you wanted to go on the website or install it, I would go to block.github.io/goose and to find me on the internet, on any social media platform and Black gobys.

Richard Moot: Perfect, and I will also just do the extra plug of check out the Block, open Source YouTube, and if you want, you can also check out the Square Developer YouTube if you're interested in things on Square Developer, and if you are working on a project or you want to learn more about what you can build or what is available on Square, go to developer dot square up.com or you can follow us at Square Dev on X. Thank you so much for being here, and we'll see you next time.

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, they can move forward and forward. I'm going to see the result of this a week or two from now.

Dina Spitzer: Yeah, I definitely agree with that. And a skillset that I've had to learn is living vicariously through others accomplishments. So if somebody on my team was able to accomplish something because I unblocked them, because I delegated the right work, I had the right conversations to set them up for success and give them that work, it's their project, they're running with it and they succeeded, but I'm like, yes, I played a role in that. And you kind of just have to take those wins where when your team succeeds and when the individuals on your team succeed, you're succeeding.

Richard Moot: I think that's very well put. You no longer try to look at, it's like you have to redefine your personal success through your team's success. And so on those days or weeks where you feel like I didn't do anything, but all of a sudden you see all the updates from your team on like, Hey, look, we shipped these three, five things and look at what kind of impact they're having. And you're like, wow, I'm so proud of my team. I can't believe that they're able to do all this stuff. So yeah, I definitely say that's probably one of the more rewarding parts in trying to make that shift. One thing I want to go back to a little bit is, and this is probably more true now that you're the engineering manager on the team, when first starting on the team that was building out the frameworks for our developer platform, we were having a big shift in terms of how we were actually building APIs.

We used to have it all built by one team trying to build it into all these different services and we realized this isn't scalable. And so we then shifted over to this decentralized way of, Hey, we're going to build out a framework and we're going to give this to a bunch of teams and say, Hey, you're going to use this in order to go and build out those services. I recall that that period of time was a little bit rough because there was a lot of heavy on call firefighting type stuff. I'm kind of interested in how that has changed for the team over time and how do you help build that resiliency for a team to be able to work through the constant firefighting and then now be in what is a much more stable place?

Dina Spitzer: Yeah, great questions. I think the biggest thing that we did early on, I'm trying to think back, but the first year joining the team was actually dig into what are we getting paged for? Why are we waking up at night? We actually found that the majority of our pages were not real. They weren't actionable. I mean, our monitors and detectors were just a little skewed. They were just a little off or they were detecting things that weren't actually real issues. And so we put a lot of effort into actually reducing the page volume and the noise around that. And then we did a lot of work around what are the noisy parts and how can we extract them out? We did that for logging. Yeah, I'm trying to recall because it was like five or six years ago, I know. But we did a lot of work upfront to basically figure out why are we waking up in the middle of the night and how can we get that page volume down? And after, I would say a quarter or two of working on that, it was much more balanced on the team. It was a much, much nicer team to join and a team where you're not regularly woken up in the middle of the night and it was great. And then we could kind of continue with our vision after that. But there were fires when I joined, lots of fires.

Richard Moot: It was a very interesting time. But I mean, I think that the work too actually, and I think something that can get overlooked quite easily sometimes is how many false positives are we really getting here? And let's actually block time to go back and see are we trekking the right signals? Is there anything that we're actually fixing here or are we just creating a lot of noise? I mean, nobody wants to be on a chaotic on-call rotation.

Dina Spitzer: No. And also another thing I'm recalling that we did was we used to all just swarm. We would stop our project work and swarm on on-call issues, and that means that your project work doesn't really move forward. So there were just a lot of process changes that we made very early on and we were like primary on-call, primarily digs into the issue. They can leverage secondary on call if they really need to. They can pull in someone else from the team. But having that separation of concerns on the team really helped us to actually continue pushing our product work forward will also fighting fires.

Richard Moot: Yeah, I mean it's crucial because it's too easy, especially when you're in that firefighting mode to just be dropping everything and being like, oh, we have to go put this out. And then you're in this context switching and trying to go pick up the old work and it's much harder to move things forward.

So one thing I wanted to ask about is as you've now been in the EM role for a while, how is it that you have approached or, I mean this is going to feel like a weird question, but what is it that you noticed or look for in some people who are starting to evolve into that tech lead role and how do you think about fostering that or trying to fan the flames on that interest?

Dina Spitzer: Yeah, I've definitely worked with a couple people on my team who've expressed they want more leadership responsibilities. They wanted to step into that role. The biggest thing is identifying a project that they can actually use to step into that leadership role or sometimes asking them to identify a project and working with them and product to figure out what that really senior project is going to be. And sometimes there is no project for a little bit, and until you identify that project, you coach them and mentor them on leadership traits within their given work

So that when it comes time to actually take on that really senior project, they're ready, they're there. But I also really like the primary and secondary DRI model. So let's say that somebody really wants to step into the tech lead role. I have them be the primary DRI, and then I have someone a little bit more senior than them be secondary DRI to provide coaching and mentorship as we go. And I found that that's really effective so that they have that support when they need it, but really they're the ones leading the and leading the project.

Richard Moot: Oh, that's really great. And it's so funny to hear that because on our API design team that I lead, we actually kind of followed organically a very similar route that when we have somebody that's going to be pairing up with a team that's working through an API design, we always have a primary and a secondary and we kind of treat it. One person is kind of run it and then you have somebody's backup. Part of that is to handle when somebody's has to go on leave or something that somebody's able to immediately pick up on it. But we found that when onboarding people into that process, it was super valuable to have the more senior, more knowledgeable person as a secondary. So it feels like there's a safety net. So when you get to that unknown uneasy area, you have somebody who you can consult with on the side, you can be like, oh, here's the things that you should think about. So it's great to hear that great minds think alike in terms of these approaches.

Dina Spitzer: Yeah, it's an effective model and it's also really awesome to see that less senior engineer who's assigned as primary DRI. It's really awesome just to see them grow and improve and receive that mentorship and really take that mentorship and lead. It's one of my favorite things about management, to be honest. Just seeing that growth of everyone on your team and enabling that.

Richard Moot: As you sort of foster growth for individuals. I had this kind of conversation with one of the Mikes that works here, and there was an interesting thing that he talked about when trying to help somebody level up say even in just their software skills is I'm just wondering how much this might ring true for you that when somebody's going diving into an engineering design or trying to interpret a product requirements document that, how often have you found to, rather than giving somebody the answer, just giving them another question or another direction to have them investigate in order for them to go learn it on their own? Because I think it's very tempting to just be like, oh, I know the answer to this. You should go talk to this person, do this thing and do this. And you kind just go, well, why do you think that's happening? I mean, do you find that happens fairly often or what are your sort of different tools for fostering that type of engineering growth?

Dina Spitzer: Definitely that. Another tool that I use is if there's someone a little more quiet on my team, but I know they have the answer, I'll be like, oh, person A, what do you think about this? And I know they have the answer, but I know that they don't really always feel safe or comfortable expressing in a big group setting. And so redirecting conversations to get focus on people who otherwise wouldn't speak is a tool that I really like to use.

Richard Moot: Yeah, I think that's a really good one. I think it's an interesting thing too because you learn the ways in which you can do that because for some it might feel like being put on the spot, but when you know that, oh, this person totally knows the answer to this, I'm just trying to give them that moment to shine and be like, Hey, go ahead and tell us all so that they can basically express that. I think another one that I've used, I don't know if you've used it as well, is whenever somebody on the team actually has done something and you're trying to share it with others, I always am very egregious about just giving credit to people all the time. I'd much rather say that Anthony and my team did this. Jordan and my team did that, and part of it is to direct people to be like, Hey, when you want an answer on this stuff, you actually don't have to come to me. You can go to them and they'll give you the answer for that. But I felt like it just helps boost the confidence of, these aren't me, these aren't my ideas, this is my team. I'm just here to empower them.

Dina Spitzer: Yeah, I definitely grew with that. And something that I'm doing right now is some of the more vocal tech leads on the team. I'm actually coaching them to try and play that role. I'm like, you've had your time in the spotlight. You're a very powerful technical leader. Let's now shift your focus to actually empower these other people to actually step up because there's only so much air in a room. There's only so many voices that can be heard. And so it's interesting that I've learned to do that through management, and I'm also currently having conversations with some of the more vocal people on the team to coach them to actually empower their peers as well. Yeah, something I'm doing right now is just coaching the more senior technical voices on the team to actually shift and empower other people on the team and to kind of shift the spotlight over from them to some of their peers, which is a different kind of leadership for them.

Richard Moot: Well, and to harken back to something that you actually said previously where that's kind of teaching, that little step of going into an engineering manager is when your work as an EM becomes more invisible, and so the more senior, the more of a voice that you end up having. You have to learn to be more reserved, more careful with it. Because sometimes it's like you say something and people are like, okay, that's what we're going to go do. And you're like, well, that's not what we want to happen. But also it's like you allow other people that space to grow, and so when it's dominated by the more senior people, suddenly you can develop this culture of like, oh, well, there's no mentoring, there's no advanced projects to work on. The more you coach more senior people to be sit in the background, let other people discuss and only kind of dive in when it feels like, Hey, it looks like we're veering off, or, Hey, actually I think this might help a little bit more. So I think that's wonderful in terms of trying to really balance the seniority

in your team in that way.

Dina Spitzer: And honestly, one of the best things I ever did for my team was had a kid three years ago, I left the tech lead and I came back and there were all these leaders in my absence, and there was so much room for the team to grow in my absence too. And so timing worked out.

Richard Moot: That's really funny that you say that because I think he just immediately gave me a flashback of when I joined the API design group was because my manager went on paternity leave and was gone, and I had to cover for them and leave this other group or at least participate in this group. I wasn't leading that at the time. And that I would admit as an IC, I was like, this is wild. For three or four months of just like I have to answer all these questions, I'm completely out of my comfort zone. But I mean, in the end, it's really good growth. In all honesty. I think what convinced me to actually that I wanted to do more management type stuff was being able to be thrust into that tried in this place where I don't feel like I'm completely committed to this. There is a timeline where I don't have to do it anymore. And so it's great that there's these ways to sort of inadvertently create that space and you come back and you find out like, Hey, the team didn't fall apart without me. In fact, they're stronger and better than they were previously.

Dina Spitzer: A hundred percent. And on that note, I'm actually starting maternity leave for baby number two next week.

Richard Moot: Wow, congratulations.

Dina Spitzer: Oh, thank you, thank you. And my tech lead from my team is actually going to be covering for me in my absence, and I think this is just an excellent opportunity for him to step into the management role and to really learn and grow in that area.

Richard Moot: How have you approached preparing somebody? It can be this one person in particular, but it's sort of thinking, how do I, it's not often we get these opportunities and they be like, how do I explain to somebody else to do what I do? Most of the time you just start doing it and you build your own process and mentality and framework, but then it's in this moment you have to go like, wait, now I actually have to codify this to some extent. How has that been and how have you sort of approached it?

Dina Spitzer: Yeah, great question. So I literally started a brain dump doc two months ago, and anytime I was asked to implement some sort of process or do some sort of process or think about some sort of question, I just put it in the doc. And then last week I actually cleaned up the doc. I was like, okay, is my wild random brain dump? Let me actually clean up the doc and then have a really long conversation with this person. So I can give you some examples of things that I put in the doc. So the easy stuff is like, Hey, every quarter do something with this spreadsheet. It's like the very standard process things that managers have to do. Okay, fine. That's the easy stuff. And then there's the other thing where it's like, here are the ongoing conversations that I'm having with these people and these teams. This is the status of each of those conversations, and I want you to continue these conversations. And then another category of items that made into that doc was more taking a step back and very high level questions like things that I'm thinking about with my team in that moment. So it's how does my team align with the goals of the company right now?

Richard Moot: How is this person going to get promoted? Just very high level questions that I'm constantly trying to get data points for and constantly thinking about. So it went from very do these steps and do these process things to very high level. What are questions that we should really be thinking about? And I really trust the person that is covering for me. I think it's just a slight shift in his mindset. But yeah, I think I'm leaving my team in really good hands.

Yeah, it's interesting in that reflection where there's the bullet, the task list or the priority list that we build of like, oh yeah, here's the things you got to do on this particular cadence. But then it's also great that you, you're creating those more abstract. Here's your north star things. Make sure that you're following these things. And when you're feeling lost or confused or if something out of the ordinary happens, as long as you're kind directing towards these things, you're going to be going in the right way. But I mean, these are all things that you sort of built into your team over time. Anyways. This is what's important. If it's not in this realm of things, it's not that important. Don't worry about it. And that's I think, how you end up building a team that you can trust a lot.

Dina Spitzer: Yeah, definitely. I agree.

Richard Moot: Well, I think that's probably a place where we can say that's it for today. I want to thank you for joining us here on the podcast and helping us in getting the very first episode done. And I think that it was a great conversation talking about the evolution of going from IC to EM and how do you foster growth and trust and seeing others become better software engineers.

Dina Spitzer: Yeah. Awesome. Thank you so much. Thank you so much for your very insightful questions. This is a lot of fun.

Richard Moot: Great.

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 that's when we saw a solution around order manager, but you're never going to understand that until you actually see, well, what is it that you're using and how do we help augment that and enhance that?

Sophia Goldberg: Yeah, I think one mean for that, what always comes to mind is that scene in the recent season of the Bear where they accidentally turned pre-orders on for.

Richard Moot: Yeah, that felt way too real. Way too real.

Sophia Goldberg: I think the other really interesting learning as someone who's always been on the tech software side and not often even dealing with customers that had physical operations was how to deal with the food items and how to have up-to-date inventory. And I think it's a problem even Starbucks hasn't been able to solve and we had so many roundabout conversations being like, well surely this is something software can solve. And then being like, it's really hard for software to solve that because the bakery says they send you 20 croissants, there's actually 19 in the box one falls, another one, someone hands to a great customer. And so your system says 20, the box is actually 17, someone orders it ahead, but someone else in line gets it before them. All of those things we wouldn't have understanding or empathy of if we hadn't had to actually go bare metal to launch with them.

Richard Moot: Yeah, no, I couldn't agree with you more. The amount of times that I've actually talked to various square sellers or friends who are running businesses, doing inventory counts is one of those things where I think everyone thinks that there's got to be some sort of awesome solution to this. It's, I mean the human element is a huge factor here of like, Hey, you messed up on this order or Oh, actually we accidentally spilled something on all these cups so we had to throw 'em away. So yeah, there's all of these wonderful little things that you can learn about and then you can start to find, hey, this is actually something where we can actually build a solution and help. And so I'm going from the coffee shop to a closed loop wallet, where was that sort of light bulb moment in there that kind of went like, oh, this is actually where we think they can actually really benefit from this.

Sophia Goldberg: So we always knew at the start it was a payment solution that we were building and where people, I'm a giant payments nerd. I think what we learned along the way was that, and I think another Great Square customer was another early customer Compass Coffee out of the DC area. And I remember getting this Gchat message from their CMO basically saying, and this was maybe over a year ago now, Sophia, you're the only one that cares about payments. We care about retention and I need to frame it because it was such an aha, like what you said a few minutes ago of it's a payment tool, but really it's a retention solution. And so a lot of what we've ended up building in the past year is what we call our incentive engine. And so it's all of the, or we sometimes call it loyalty with a little L, but all of the tools that a brand needs to help drive adoption of the wallet to make it a no-brainer also for the customers to adopt. And so I think we knew it was never going to be the type of tender type that's set and forget offering Apple Pay and Google Pays is a lower bar to drive adoption than a closed loop branded wallet might be. And so we started building more and more into what tools can every brand that we work with use regardless of say loyalty platform, but we do use the square loyalty APIs for our square merchants as well.

Richard Moot: And so as you got through those first few customers, where did you start seeing the ability to really start scaling this to more and more types of businesses? It sounds like you initially sort of figured it out with the quick service smaller coffee shop type thing, and then how has that changed as you've gone into different verticals?

Sophia Goldberg: So we're still pretty heavily focused on Food and Bev moving up market a lot more to hundreds of location franchised brands.

They have more resources in terms of people to focus on individual niche aspects like core loyalty program can have a whole team, but the day-to-day and the pains of that kind of brand is the same whether you have six or 6,000 locations and you just have different resources to deal with it or to scale it. I think that other use case we saw and started coming up for us that was a bit more unexpected was platforms and marketplaces, which hadn't been one that we initially I think had a list of 14 verticals. We could serve everything from toll and parking through to micro transactions online and fuel, but that was interesting inbound we started getting and have launched with and that's pretty interesting for how can a platform and as you guys know spectacularly with Cash app pay, which is both closed loop and open loop and maybe more of a 201 payments topic. Then this podcast is for there's real value in a platform like say Square, having their own wallet for funds to be used across the platform. And so we're seeing use cases like that come up and then marketplaces like a seller is also a buyer on a lot of marketplaces because there are a lot of niche interest group marketplaces like trading cards or knitting musical instruments and how can they build that flywheel and keep funds on the platform drive that retention and repeat usage.

Richard Moot: Yeah, no, definitely. And so I'm curious what the things, what would you say is the lesser known benefit of adopting a closed loop wallet for a brand? What would be the unexpected benefit that they might get and not really initially be thinking about?

Sophia Goldberg: I think the data, honestly, we haven't figured out the perfect way to talk about it, but it's another lens through which to view data and your customer's behavior and that is really powerful when combined with all of the other data a customer has or a brand has with a customer, sorry. And so what that means in reality is you have a new tool for your marketing team to engage with a customer to drive spend and usage. And so for us, the way we've kind of productized that a little bit is we call it the ons a portal, but that's where our customers log in and manage everything from reconciliation, reporting, triaging customer complaints and say refunds to also creating incentive campaigns. We have a data platform that we call custom user segmentation and they're able to go in and say, I want to look at all customers with a balance over $20 who haven't spent in 30 days.

So that's high intent. They have funds, it's basically from consumer psychology, whether we call it girl math or sunco fallacy, it's free for them to come order again, but soft churn risk if they haven't visited in 30 days. And so being able to create that segment and push that out, so for example, we update segments into square segments every night, so we've used your APIs for that so they can create wallet based segments in our platform, push that into their square marketing stack and specifically target those customers with incentives, reminders they can know based on the data they know in your platform. Hey, Sophia really loves the, I really love the Rose mocha in February, the rose mocha, you didn't see her in January reminder, it's coming back and she's balanced to spend. I think that data piece is so much a powerhouse part of it that is pretty delightful when we get to start showing our customers how to use it and how to utilize it.

Richard Moot: Yeah, I mean that's just so powerful because I imagine that you have a much more direct connection on tracking your ROI on your marketing campaigns because you're like, Hey, we know what their total balance is. We know they're totally able to purchase these things, so it's there and we just need to give them that little nudge. And so it's so much more powerful to be able to draw that direct connection.

Sophia Goldberg: Exactly. And on that ROI point, another tool within our system is expiring bonus dollars and so everything we do in our system is dollar or currency based rather than points-based. We live alongside points-based systems really well. And so what that can look like is, Hey, Richard, haven't seen you in a while. We threw five bucks in your balance for Patreon us next time you visit, it's good for the next week. And that means it drives fomo, it drives some urgency for you to go spend it, but if you don't, that can flow back into the marketing budget. And so from an accounting side, you don't have ballooning liabilities of outstanding balance that you've spent, but also that means they can try that five bucks elsewhere and see if maybe someone else is more likely to reengage.

Richard Moot: Yeah, that just sounds so powerful. Changing gears a little bit, I wanted to talk a little bit about your tech stack. So how did that first start? What were the technologies that you were initially building with?

Sophia Goldberg: Yeah, so both my co-founder and I had done a lot of covid thinking solo before we linked up, and so we kind of like to say day one we hit the ground running with a lot of intention. He had had an indie hacking project on the side while he was at Google before we started on so full-time together. And so he had a lot of experimentation with stack, so we knew what we wanted from Day Zero, which was awesome on the business side to have someone that was really high conviction and knew why. And so our database is we built our core ledger from the ground up and have a Postgres database and backend is fully in Go and we really picked that because it's highly performant, easy to learn and maintain and has built in typing, which is really helpful for building financial products. And so we were high conviction in building our backend and go and then our front end is TypeScript and next JS and deployed using Versal because they're really technologies that are recent enable a lot of fast prototyping and shipping, which at an early stage startup you have an idea, you want to experiment, you want to get it out, you want other people on the team to be able to go in and know what's happening.

But we did that. We chose kind of that front end stack from an experimentation lens and then the app we built is built in Swift,

Richard Moot: So it's like a native Swift iOS app and then you're using a NextGen sort of React web frontend.

Sophia Goldberg: Also from our perspective, the frontend stack isn't just for the mobile app we built, it's also for the ONA portal. And so we knew it's something that would have to scale for various size brands, whether you're six or 6,000 location coffee brand able to add stuff like SSO access controls, really easily be able to do reporting and linking out and walk to run in terms of what that front end looks like and really being able to care about the speed and flexibility as we built out the portal.

Richard Moot: Yeah, no, I mean it's so important and I think one thing that makes total sense to me here at Square we use Go Java, Ruby, we are using a lot of React and Ember and other places. I know that for Go as a backend when you have a financial product, I mean you're going to find a lot of people within the FinTech space are going to be familiar with Go. So as you scale up, you're not going to have as much difficulty in recruiting people and get them up to speed on your tech stack. So I imagine that's just another nice benefit of choosing that from the beginning.

Great. So in terms of features that you built and added over time, what's the newest thing that you have that you're working on with Ansa?

Sophia Goldberg: Yeah, so a lot of new things, I'll talk about two really. So one is our SDKs, so for brands that already have say a mobile app and maybe don't have the resources to build a direct PI integration, we have both a core SDK if they want to own front end and our full SDK that they're able to brand and color but has the full front end experience built out for them. So if you're a mid-size brand, you can get live in minutes. We had someone implemented in 10 minutes, which is super exciting. And so that's one piece that we're really proud of on the developer experience side of making sure no matter the size or scale of a brand, they have a way to benefit from closed loop wallets in our product. The other side we're really proud of and announced maybe a bit over a month ago is what we call Onset Anywhere, and that's how you're able to accept a customer's digital wallet in store for a tap to pay payment at the point of sale.

Richard Moot: Very cool.

Sophia Goldberg: And so what we've built there is it looks like a virtual card in Google Pay and Apple Pay and is fully point of sale agnostic. And so obviously it works seamlessly with the square ecosystem and that means a customer rather than having to pull up a QR code that may or may not load and front of house staff having to buy scanners and remember to plug them in correctly and deal with barcodes and QR codes and everything there, it means you're able to line bust, have a really slick and easy customer experience and just walk up and pay with your balance. And so we're really proud about that because we care a lot about when you're trying to change anything about customer experience like adopting a wallet, we want to change nothing and so tap to pay with onto Anywhere is a really exciting development for us.

Richard Moot: I mean it sounds awesome and it makes so much sense from a, sorry, not developer experience, but from a buyer experience because I think we've even learned that and we've had our own fractionalization between different point of sale apps that we have that there's a confusion. We should definitely dig into it because I think we even learned that trying to scan a QR code or a barcode, we didn't even have that consistent between different point of sales and that creates this level of confusion that the employee might not understand why this isn't working. The buyer for sure is just they assume that it's the business itself refusing to accept this thing that they have. And so being able to just have it very simply in a wallet, you're just using Apple Pay like you normally would and it just deducting creates the exact kind of experience that you want to curate for a buyer. Yeah, I'd love to touch on the experience that you ran into with the fractionalization that we have within our various square for retail is not the same square for restaurants, which is not the same as the basic square point of sale

Sophia Goldberg: Classic. Yeah.

Richard Moot: Yeah.

Sophia Goldberg: We always call it Square Classic. I don't know what the formal term is. We ran into it actually pretty early on because we had a customer that was running different apps in different locations and didn't know and we also didn't know until we hit a product gap.

So we learned actually a lot about the core of the Square platform as we were running around different product teams trying to figure out is there a reason why there's this product gap? Is it coming soon? Do other people know and that side of things. And so what we were trying to do was call up the QR code and try and find an easy way about a year ago for in-store payments because what we built with Onset Anywhere took about a year and a half to build and get out. And so we wanted a quick win solution for a lot of end customers wanting to use their balance in store with some square merchants and we found that you could pay with QR code I think on Square Classic, but not on square retail. I think it was this kind of interesting experience standing in the cafe with the head of operations from this brand us. We had our laptop opens I think with Square dev support and everyone, because I think so much of your tech does work so well and because so much of the dev experience works so well, we all just gaslit each other being like, there must be a reason, there must be a reason or we're clicking the wrong button or we just can't find it. And so that was kind in retrospect now that we kind of know a bit more about your systems a bit comical because

To your benefit so much does work so well that when there's a gap, our first assumption was we are doing something wrong then rather than there's a product gap here.

Richard Moot: I think that you said it so perfectly right there because come across this in the various sellers that I've talked to and I've helped try to solve something personally, I would be the first to say that I'm not well versed in all of the various point of sales and their interactions because I mostly think and deal with the API side of things, which is very agnostic of all of those interactions, but I've helped people who are like, Hey, I'm trying to do this barcode scanning in a particular thing and I'm following the instructions here in our support documents and I point out to 'em like that's square for retail. You're a restaurant, you're in the wrong support docs. But the design is so similar and I think the thing I always like to say about this is it's a great user experience, but it's really great until it's not and then all of a sudden you realize all of the magic is kind of fading away and you're like, but I just really want to do this particular thing and I feel like maybe I have to be wrong, but sometimes it might actually be that there's a miss on our side and I know that one of the big things that we're working on here is actually trying to unify a lot of the various point of sales and trying to consolidate into one more consistent experience because I think at the end of the day you're going to end up realizing a lot of businesses are kind of fluid in the way that they operate.

We've seen this in some of the health and beauty space where they're both a service, but then they also have a big retail component, and so what kind of point of sale are they supposed to use? I mean, who knows? So I think a lot of the time, I mean even coffee shops, they're going to have a retail component in addition to the food and beverage that they're selling. So of course they want to be able to operate in both.

Sophia Goldberg: Yeah, exactly. But it's exciting to hear that there's some more unification coming soon because I think that'll benefit a lot of folks.

Richard Moot: Yeah, I'm very excited to get that out there to get a better streamlined experience. I mean, we've been doing a ton of work on just trying to optimize even just the onboarding process to get things initially configured in a way so that you're like, Hey, I can at least figure out how my system works more easily. In terms of the SDKs and the developer experience that you're offering to other folks, I'm curious in terms of what the desire is for a customer is to be able to more seamlessly fold ansa into their own custom applications so that it's more fitting within their brand. What level of customization or are they really looking for with onset?

Sophia Goldberg: So we really have four integration paths and it's kind of choose your own adventure and choose your own effort is maybe a way to put it. So on as custom as possible side, there's our API integration where a brand owns all the front end experience, can build their own user flows, everything there. The next is the onset core SDK, and so that's for mobile specifically, and so they don't have to wrap our APIs into the mobile environment, but they still own the front end experience but can get live a bit quicker. Then there's the easy button version, which we spent a lot of time on, so is actually a really powerful front end experience as well, but that includes the screens the customer sees and the brand can add their own logos and colors and some cosmetic effects to make it feel branded, but they don't have to choose what the reload page looks like or choose what the auto reload toggle shape is. We've decided all of that for them. And so from what the mega enterprise might want to use down to the 40 location brand with a custom app, but no front end developers full time, that's what that looks like. And then the fourth is we have some integrated partnerships, and so living within a lot of white label app platforms as the wal of choice that they can turn on, the app provider builds that experience using our APIs, but from the brand perspective, they don't have to invest any technical resources, which is really awesome.

Richard Moot: I mean, I love to hear it because I've always seen in a different case of there's, I don't say it's necessarily the 80 20, but there's always that balance between those that obviously in the enterprise size want the heavy customizable, fully brandable, they want every feature that they could imagine type thing. And then there's the other people who are like, I could not be bothered to build 90% of this. Please just give me the fully baked solution where I can just add in a couple things here and there. I'm curious on that, how do you balance prioritization between the two? I mean, I always find that's the most difficult thing to really strike the right balance on.

Sophia Goldberg: It's difficult. I think focus is everything at a startup. And so we started with a very enterprise heavy approach. I think we were SOIA compliant as five people. We've been basically PCI compliant actually we've been PCI compliant since our first transaction. So we knew that we were building for enterprise scale longer term and enterprise software. And for us the decision of where to balance is really from a go-to-market perspective of how can we help drive urgency and help reduce objections. And so

Sophia Goldberg: For SMB and mid-market and mid-sized brands, a lot of that is around technical resources and prioritization. And so we realized that actually spending additional time on not just building a core SDK but building UI components was we worked with one brand it and realized we spent even, our team spent so many hours in a room helping them with design decisions that our head of solutions, myself, one of our lead engineers and my co-founder of the CTO probably spent a dozen hours walking them through and seeing all the decisions they were making in real time of, okay, what screen should go next? Should this be a toggle or a tick box? All of those things. And we realized every customer we're going to work with is going to have these exact same conversations and probably land at things that look pretty similar because there's a lot of new and delightful experiences to build in the world of mobile. The checkout page is not one of them anymore. And so there was a lot more of an aha moment. And then for us, we really prioritized it from the perspective of timing of we knew we were going to invest a lot more heavily in this vertical and helping them launch quickly, and so we were able to go out and find a really great iOS and Android developers to work with and bring it to market and design.

Richard Moot: I think that's so great because it kind of goes back on that idea of we'll worry about payments so you don't have to, and we'll worry about customer retention, so you don't have to, it really tries to really strike that part of we care relentlessly about this for you, and so you don't have to be sitting here making all of these decisions. And it ultimately saves time because they can have a better product, they can have a better experience, and they're not having to sit there and go through this whole, I mean, to have that many people for a dozen hours or more. It's expensive. Yeah, it's very expensive. So it's great to be able to codify that in a way that you can actually give to people and be like, Hey, here's your 80% solution, and you just have to make smaller branding decisions.

Sophia Goldberg: Exactly, and I think one thing we talk about a lot at any size of company, but especially true on the enterprise is with the right investment, a company the size of, say, Chipotle could build anything,

Anyone can go hire great engineers and build anything if you have enough capital, but is that really where you want to invest it? Do you want to invest it in a feature like expiring balances, which we actually have a developer blog post on, which is really complicated, how you have different treat balances, different ways can expire, certain funds have different funds in the same wallet treated differently, and then also have to bear in mind accounting and financial regulations on top of it. We like building that stuff. We're good at building that stuff. There's not many restaurant brands that need the knowledge to know how to build that on top of a ledger. And so that's also part of our perspective as well is we're able to free up a lot of time around the edges as well where they can invest those time and resources on core differentiating product or expansion.

Richard Moot: Great. This is probably a good place for us to wrap things up. Big thanks to Sophia Goldberg for joining us. I truly appreciate you being here and teaching us more about Ansa and where can somebody go to learn a little bit more about Ansa if it's something that they want to, they're interested in a closed wallet, maybe they're running a business or maybe they just want to look at you guys' SDKs and figure out, hey, maybe this is something that's for me. Where can they go to go learn more about that?

Sophia Goldberg: Yeah, you can go to ansa.dev (a-n-s-a dot d-e-v) to check out more, or you can just email [email protected] and it's probably me who'll get back to you.

Richard Moot: Awesome. And for anything else, if you're interested in learning more about Square, be sure to reach out to [email protected]. You can find links for our discord. You can follow us on X and be sure to subscribe here to learn more and hear more about stories from people like Sophia. Thank you so much.

Sophia Goldberg: Thanks for having me.

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 our customers, and so it's just really helped us continue to just in one more area, go to the next level.

Richard Moot: Yeah, I mean, one thing that just immediately comes to mind is given that it's consignment, so I'm going to guess that there's thousands if not millions of unique items that you're having to track across all of these different franchisees, and they're all using this one centralized point of sale that you've built. I guess, I don't know if this is a question for you, Alana, or if it's for Dave, but what kind of was that initial inclination to computerizing it as you sort of put it at the beginning of building out? Was it initially just doing inventory tracking or was it wanting to have just all of this point of sale type thing in one space? What was that initial inclination to build that?

Dave: Yeah, so we can imagine that item is unique. It is one of a kind. And so from the beginning we had to create a sort of a customized inventory system. Even now at a large event, you might find 10 strollers that look identical. They're owned by 10 different consignors, but the wear and tear is different. The pricing is what every consignor wanted for the item. And so from the beginning it had to be unique, one of a kind. And so that's really served us when scaling. It really hasn't changed. So every item, whether there's 1,000 items or 250,000 in an event, each of them are cataloged individually. And so the system, you can enter them in that way and then you can sell 'em that way coming out of the point of sale system.

Richard Moot: Yeah. What motivated you to initially build this? Is it just you had a background in tech and you knew, oh, I can build the first version of this and how this should work?

Dave:Yeah, I mean, I've got a little bit of a tech background, and so at first it was sort of a hobby. Obviously we didn't think we were going to be doing a business, so I had the only barcode scanned garage sale in the neighborhood, maybe America. But anyway, so it was sort of a, can we do this motivation as a challenge and as something of interest? And so that went well when we gradually scaled up, we just would take on the next challenge and make it continue to work.

Richard Moot: Yeah, no, that's great.

Rhea Lana: And I think it was combined with I've tended to want things to be done excellently, but I didn't know really how to do it except that first sale, I was counting little string tags and I would've just only thought about doing it manually. And so as Dave, I think as he thought through my desires, he's kind of always figured out a technical solution to solve whatever problem we were dealing with operationally.

Richard Moot: Well, I would also just sort of imagine that at the time in the nineties that there's a huge disparity between, Hey, I want to have something to sort of do this inventory tracking point of sale thing, and off the shelf, I'm imagining that it would've been something that's very large, probably felt way over the top versus starting out with like, Hey, I got a barcode scanner. I know enough to cobble this together and get this tracking, so we're not going around counting tags. So I imagine it makes sense to have sort of that natural growth of why you would build your own point of sale. I know that nowadays most people would be like, why would you build your own point of sale? There's so many solutions out there, but given where you started from, it makes total sense.

Dave: Well, it still does because the business at the core hasn't changed.

Richard Moot:Yeah, I mean, I totally get it. I mean, having a catalog that size, it's so many skews, it's so much stuff to track. I mean, at that scale, and also I just imagine that it's also from running a franchise business, you're reporting visibility through all these things. It is a huge boon to the franchisees because they're not having to go and figure out all these other things. You have prebuilt solutions for them to do all the tracking and the sales and the receipting and all of that. So I imagine it's a huge benefit on both sides because you have really great reporting and really great things to offer to your franchisees. So one thing I'm curious about, when you built the first version of it, what did you initially build your point of sale with?

Dave: That's proprietary. I couldn't tell you.

Richard Moot: Okay, Okay.

Dave: No, I don't even know. I mean, I think we used just basic programming, and then when we went to the web, you've got your PHP and ASP just web pages, so it's nothing sophisticated.

Richard Moot: Yeah, well, I mean, I love tried and true. It's reliable, it's maintainable. So, and I think I talked to you previously that it was initially doing Visual Basic and then this ASP/PHP growth over time. I'm going to guess probably MySQL or something for database, in terms of tracking, what first drew you into using Square as a payment solution? From what I understand, you have almost all of the stuff for doing the point of sale in terms of inventory, receipts, all that stuff, and then you really just have a payments partner for helping with that final part of capturing the sale. What drew you into using Square initially?

Dave: Well, we did use Square initially. We did have a different partner and they sort of introduced us to the idea of integration. Obviously any small business can one way or another take credit cards by typing in the amount and running the card. And so they introduced us to the idea that you could possibly integrate this and let the point of sale produce an amount, pass that to their device, and then on the fly, take the card. So we took that challenge and we integrated with our software, their device and their code. And so we liked the direction of that. And so it included the purchase of their big block of technology, this brick that takes the credit card, whatever you use to swipe, you could tap, you could swipe, you could type those kinds of things. And so the idea originated there, but over time, we just found that that solution, they weren't paying that close attention to us.

Changes would happen, and I don't know that they or we know exactly how they became disconnected, but we began to have technological glitches. And when you have technological glitches in the financial area, man, people immediately notice. These ladies, these families are trusting Rhea Lana’s, and so they're buying all their children's clothing at one time for the season. And so it could be a $600 purchase by a family that is basically their clothing budget. And so if you double charge them, man, they're living on a shoestring in some cases. And so they are just very, very upset. And that happened. And of course, Rhea Lana and her team were quick to respond and offer solutions because she really, really cares about these families. But then it was upon us to figure out, well, why is this happening? And we came to the point where we can't keep going like this.

We can't use this particular solution anymore, so that put us in a position of trying to change. And so I was feeling pretty glum and went to a coffee shop and drowned my sorrows in Espresso, and they were using, I said, what are you using? What is that machine in front of me? What is it using? And they said, Square. I said, well, heck, let's try Square until Square disappoints us. Let's try it. And so we were able to contact your customer service people, your salespeople, eventually your development people. And we began to look for similarities between our old integration and what Square could offer. And we weren't surprised. We were just happy, I guess we didn't know what to expect. We were happy as we began to learn about it. And we were able to pretty quickly, we needed to do this pretty quickly because you're in the middle of a season, we have 120 of these going on, and you have these events that are struggling, and so you're trying to switch in midstream. And so we made the switch. It wasn't without an issue here or there, but anyway, it was a great decision just to switch to Square and sort of begin to continue to offer an integrated credit card solution with our POS.

Richard Moot: No, that's great. And from what I've understood is it's not like all 120 franchises are necessarily using Square, but you've been sort of progressively rolling out them using, I'm going to guess that most new franchisees would be using Square. Tell me a little bit about the mixture or the relative number of folks who are actually using Square for their events.

Dave: Erin, you may know that, do you know where we stand?

Erin Franklin: Yeah, we were at 98 last week of our 120 franchises. And I've personally, Elan and I at Square worked together a lot, and I've personally talked to more of those franchise owners and most of them are planning to switch this year. So it was not something that we could require because it wasn't something in our franchise owners, FTDs are their franchise disclosure documents. And so it says a lot about Square and how smoothly this transition has gone with Square and how quickly it happened that so many of the owners voluntarily chose to make this change and make this switch. So yeah, it's been a really smooth transition and we do have, the bulk of our owners are already on it.

Richard Moot: I love to hear it. I mean, convincing them through just better experiences is exactly what I want to hear. And so for the payment integration that you have right now, just for everyone listening to clarify that it's using our terminal devices using Terminal API, is that right?

Dave: I believe that's right. I believe that's right.

Richard Moot: For the main part of how they interact with the Rhea Lana point of sale, are those just on laptops connected on wifi at the event and then they're just paired with each one of the various terminals? I think I also want to touch on, because I remember there's an interesting thing that sometimes you can have two point of sales connected to one payment terminal if they need to do that. And that's something that you can now support.

Dave: Our older system was I guess USB connected hardwired to the laptop. We'd use laptops that are connected to the internet and they interact with our live database. And then our point of sale pulls the data, uses barcode scans to come up with an amount. And one of the great things about the switch is that the terminal, I called it a brick or a block, the terminal, it looked like a brick,

Richard Moot: A little wedge.

Dave: the old one, but it was obscure and it was expensive. And so it also would come to us maybe not programmed. And so when you're starting off with a new franchisee, which you're trying to bring 'em up to speed on a hundred things, and then that's just another huge challenge when now the terminal doesn't work.

So a great thing was that you can go down to the store and buy a Terminal that works off the shelf, a Square Terminal. So that was a one, especially given the speed at which we had to switch, that was great. There wasn't any shipping, there wasn't any programming. It was just we could pull the Square machine off the shelf and then use it with our integration with the API.

And then another positive like you just referred to is one way to operate is to have maybe two laptops next to each other sharing one terminal. And because of the way the API works, we can pair each of the two laptops to the one terminal, and as long as the two operators are cooperating, collaborating together, and we know, okay, now this particular sale that's on the terminal belongs to computer A, not computer B, they can swipe safely and it can work, and then it can flip to computer B. They have to coordinate obviously, but that does cut the price of getting into the business in half. And especially for a new franchise, I mean, they're trying to save as much money as they can. Our franchise owners are typically small business women who have a lot of energy for this, but they are trying to get into the business as cheaply as possible, so that's another way they can do it.

Richard Moot: Yeah, no, I mean it makes perfect sense.

Rhea Lana: Well, I was just going to add just an element of our business is that we are a pop-up event, so it adds this element of pressure. And so in a brick and mortar store, you can sort of maybe handle it tomorrow or probably fix it when you come in the next day. I mean, everything we do is urgent and it needs to be done really yesterday. And so we do so many things from merchandising the store to marketing to our customers, and sometimes women are even having to fix the bathroom if they're in an empty retail space.

So with technology, we just need to depend on it, we need for it to work. And so I think that's just, and the ease, like Dave said, of being able to just go get a terminal because at the store and we just plug it in and it works. And again, these are just normal women who most of them don't have business experience. And so Square has just made it fast and simple and dependable. And so we have just appreciated that very much. And I was also just going to add, we haven't really been in the relationship very long, Erin have we been through one season,

Erin Franklin: One full season.

Rhea Lana: One full season, which I think that speaks a lot that we already have this many franchise owners that are using it. And another reason is because of the customer service. I mean, I really want to speak a lot to that of Elan and all of Square because in a franchise system, especially of women, they talk. We want to work with companies who when we're in a crisis, they're going to actually answer our phone call and they're going to actually talk to us even if it's late at night or on a weekend and we're in a crisis. And so we have really just appreciated all of the customer service and the dependability that we have and really kind of surprised by it. We are all like, oh my word, can you believe Elan called and checked on me before my event and he helped me? It's proactive, not even just reactive. So we've just really appreciated that.

Dave: I'll say one more thing, just in that transition, we had a little bit of a black eye, but when the customers saw the Square terminal, they recognized it. And so there was some good publicity as people talk and saw the Square versus the old terminal. It made them feel, I think more comfortable because they had recognized it from whatever coffee shop and around the Square name helped us.

Erin Franklin:Yeah, I was going to say something similar just that I was in my event when the issues arose with our previous merchant service, and it doesn't paint a great light on your business, and it's hard sometimes to have these families see, oh, I promise we're fixing it. But the time that it took for Dave and the Square team to flip and start this partnership, it was incredible. And Rhea Lana I have said many times to have this level of customer service come from such a large company, it truly is very encouraging because sometimes when these companies get very big, customer service may go down, and that has just not been the case with us.

Richard Moot: I think I remember when we chatted before setting up the podcast, it was a small little story of the double charging incident, and it's one of those things where it can be very heartbreaking because I've seen it so many times in talking to so many different businesses that sure, the double charge can be refunded, but for a lot of folks, I think people forget that can take anywhere from three to 14 days before that is actually cleared and returned back to somebody's account. And if they don't have a high credit limit or they're already close to their limit, that means I can't buy anything for several days. And that's hard.

Rhea Lana: Well, and with social media now, I mean that was what was going on. And like Dave said, people are buying a lot. They're buying for six kids, the whole season, a lot of money. And so now with social media, they were just ripping me up because, and the banks, they weren't getting their money refunded quickly, they couldn't buy groceries. It was so opposite what I stand for and really how I operate my business. And thankfully we solved it, but we were in several days of purgatory. It was terrible because we, and we couldn't figure out how to solve it. And so you're right, I mean, it's a terrible place to be as a business owner.

Richard Moot: But I think I remember someone saying that it was even in that very next event or next season, they had noticed the switch over to the new payment system and that it all seemed way more seamless. I also quickly want to plug, one of the interesting things that you all have built for Rhea Lana is those digital receipts that give a full branded invoice. So they can just say, I don't want to print a receipt, just go ahead and text me a link. I can go look at it and follow it up. I'm sure that there's a multitude of reasons that that helps streamline the checkout experience so you're not having to wait for something to be printed out and they get a full thing from you with all the branding. So it's just a testament to the brand. And also that you were able to get this integrated in a way that can streamline things even further.

Dave: Yeah, what you're referring to is a text receipt. When we do that, because it's more activity on the terminal, that's when we sort of have to commit one terminal to one laptop. It's just too much because we're asking them, Hey, if you would like a text receipt type into that Square terminal, your phone number, and we've integrated so that it will then text them a receipt. Obviously you've got another, a texting API software there as well. So anyway, but all that works together. It is more streamlined and lets us serve them at another level.

Richard Moot: That's great. And I guess the final thing that I was wanting to ask about on the tech side, and then I want to talk about, just give a picture of what the size and the revenue of this is for either on a franchise or nationwide, but how long was the initial integration process when you finally got in touch with our development team and you were sort of building out the integration? About how long did that whole thing take?

Dave: Not very long.

Rhea Lana: I remember the Square team was surprised how fast it was. We have a pretty small tech department. So was it over the weekend, Dave?

Dave:I mean, yeah, it was a necessity for us, so we were trying to switch quick. I got enough access to enough of the Square Development pages, education pages, and somebody set me up with a Sandbox, or maybe we skipped a Sandbox maybe. They said, okay, you can go live. And so we just sort of worked away over a weekend and got to a point where we were comfortable and our tests worked. I spent a lot of money off my credit card running transactions to make sure it worked. But yeah, it was quick. It was quick. We watched a couple of videos as well, that Square had, I think with other customers too.

Richard Moot: Oh, great. I was actually going to ask whether or not you came across any of our tutorial videos on Terminal API, but that's shamelessly self plugging. I know that I created some of those, or my team has. So great to hear that you came across some.

Dave: Hot yoga, hot yoga,

Richard Moot: The Hot Works video. Wonderful.

Dave: There we go.

Richard Moot: Yeah, great. They definitely give a full understanding of the size and scale that you can take this thing. And so just to come back to give an understanding of the scale of Rhea Lana, we have the two events a year, the 120 locations, and to whatever extent that you're comfortable talking about this, but what would be the average for an individual franchisee or event? And then what is the size of this? Through all of the United States.

Erin Franklin: There's a range in sales. And so startup new events, they might have $10,000 in sales where larger events go up to a million dollars in sales for an event. And so there's a very wide range across the company, and that's per event.

Richard Moot: And for those larger events, how many point of sales, what is the checkout looking like?

Erin Franklin: Rhea Lana, I mean, most have probably 15 to 20.

Rhea Lana: Yeah, I think we probably set up 20, but it feels like one or two are not going to work for whatever reason. Either it's the scanner or the printer or the, so we're always trying to leave some room there for one station, not to work, but about probably about 20. And we do try to use some, just the way that we have our shop, our people come to shop, we do try to control the crowds as well, just so that we can handle the number of people in a good flow so people don't have to wait in line a long time.

Richard Moot: And it just reminded me, the thing I forgot to talk about is that because this is an event-based thing, you all have it, it's scheduled, but people can buy tickets and there's different types of tickets they can buy. So there might be a little pre-sale that some people can opt in for versus the main sale. Could you maybe give a little bit around what that looks like?

Rhea Lana: Yeah, so every franchise is different, but we do have a pre-sale before. Once we open to the public, everything is free. And that's how really we started was everything was free, but we did have to do a model change several years ago. And so we began offering tickets and it has been a wonderful model change. And so people, it's sort of like going to a concert where the better seats cost a little more. Well, the earlier you come, the tickets cost a little more because you get the best selection. And like Dave said earlier, the consignors price their items themselves. So there might be 20 high chairs, but the earlier you come, you're going to find your favorite brands and the lowest prices, and every item is unique. And so it's like this wonderful treasure hunt. And so a lot of people do, it's worth it for them to buy a ticket and they're still very affordable and you end up saving, you save the money, especially if you're buying large items, families that are having babies and have to buy all the baby gear, it's definitely worth it. And then we have a half price at the end.

Richard Moot: Oh, that's great. I mean, I would definitely say I would be guilty of wanting to do the presale type thing. I mean, I would like to get in there and get first pick, make sure that I get everything that I'm looking for. So it definitely makes a lot of sense.

Rhea Lana: And we have fewer shoppers too, so it's just kind of a quieter, calmer experience. And one of the things I might just throw in Richard, that we do love to do that's part of our events is at the end we have a lot of consignors will decide that they want their unsold items to be donated. And so again, our POS and our system helps us track all of that, and so then we are able to take those items that the consignors don't want back, and we have a free shopping time where foster families and some of the lower levels in the military can come in and get items for free for their family. So it's really a neat way that we can give back in each community and really bless even more families. So it always warms our hearts. We love the very end.

Richard Moot: I guess my final question I would have, I see that we're climbing close to time here. My final question would be like, so how does the pricing of items work? Is it usually the consignor? Is it a partnership between them and the franchisee and figuring how they want to price the item? I'm going to guess that sometimes people have to be like, look, you're not going to be able to sell it for this much, so I don't really want to consign it, but just for those who aren't familiar with how consignment pricing might work, tell us a little bit about how that all works.

Rhea Lana: Well, I'll start first, then I'm going to toss it to Erin, but one thing I really did want to mention is that one of the things that we started that really Dave and the IT team get credit for is we do voice entry. And so families, a consignor can just speak into their phone instead of having to type it all in. And so that is another technological advancement that we use, so it helps it go so much faster. A mom can be sitting in the carpool line, talking into her phone, entering the items into the database, but Erin, you could speak to the pricing.

Erin Franklin: We strive for excellence, Rhea Lana mentioned that earlier. And so we do have a minimum price for items, and so that's $4, and that's just to keep quality high. We want the quality to be high. And so consignors do get to set their own, but we do have guidelines that we try to have them land in between, and so our hope is always for items to be priced about 25 to 35% of retail. And so it just offers enough of a discount that buying used items is a great idea for local families. And so we really try to strive for that kind of range. There have been many times when as owners, we've called a consignor and said, Hey, might be a little high. And so sometimes they're willing to come down, but for the most part, they do set their own prices.

Richard Moot: That makes a lot of sense because I mean, I do know that at a certain point you kind of be like, well, do we want this to take up space here? If it's kind of priced at a thing that no family's coming around this area or going to want to buy it for that much. So that makes sense.

Dave: There is an option to go half, there's a half price ending, and so people will come back and shop for those half price items too.

Rhea Lana: And the Consignor chooses that in the POS system.

Richard Moot: Awesome. Well, I see that we've used up all of our time here, and I want to thank you all so, so much for attending here and telling us about Rhea Lana. To anybody out there who is interested, please look up Rhea Lana, see if there's an event going on in your area. And again, I just can't thank you enough for telling us about your integration, your business, your story. If there's anything else that you wanted to mention here for if anybody wanted to learn more, I dunno if you have socials or anything that you want to mention for people to follow.

Rhea Lana: Sure, you can find us at Rhealana.com. And of course, we're on Facebook and Instagram and LinkedIn, and so we're pretty easy to find. But we'd love to tell you more about it. We would love to serve moms and markets all over the country.

Richard Moot: Awesome. If you've got a project with Square, we'd love to hear about it. Reach out to us on our Discord or on X at Square Dev. Don't forget to get to subscribe and check out developer.square up.com for more. Keep building and catch you next time. Thanks.

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 or some sort of collective where they meet up and sell goods there. And there's a lot of folks who might sell at those very infrequently, but it's very easy to just have a phone, have a Reader, or even just taking payments directly on the phone. And so having something like a Google form where it's like, well, I just want to be able to get this thing started. It's as simple as you use a Google form and you connect Payable, and now all of a sudden you're taking payments and collecting and starting your business.

Ryan May: And the cool thing is all the data goes into a connected Google spreadsheet. So every time that somebody submits the form a row goes into your spreadsheet, and then we update a payment column with whether the person is paid and what their Square transaction number is. And so it's all really organized, and a lot of people then add extra logic or complexity into that Google sheet. So if they want to have a view where it's sorted by just people who have paid or sorted by people who have bought this product, people really know how spreadsheets work these days. And so they're able to build even more automations kind of off of that spreadsheet. So the core of it too is instead of having to go to a dashboard or a different portal is you're really just, we're piggybacking on a lot of the goodness of what is a Google sheet. So if you need to share that sheet with other fundraisers or other people who need to look at it, they can look at it and say, this person's arrived, they've received their t-shirt. And it takes a lot off of our back for having to build up all these different obscure workflows because people can just use their normal spreadsheet knowledge to take over the rest of the business process.

Richard Moot: So I'm curious about the evolution of Payable, and maybe I'm going to be very self-serving here, a little bit more specific of initially integrating with Square and how has that changed over time?

Ryan May: Yeah, for sure. So we started with PayPal because we looked at it and it was one of the most countries, and it was one of, I had the most experience working with PayPal. So with myself, I started with them, But what we really liked about Square was how fast you could onboard casual sellers quickly. The most important thing for our business was you have all these small casual sellers who are just many times individuals or sole proprietors and they want to get up and running quickly. And Square was the best at that, and also giving you really professional looking credit card processing out of the gate. So you got Apple Pay, you have Google Pay, you have your checkout page looks pro when you've signed up with Square. So it became very quickly after we integrated the number one payment provider that we would recommend. If somebody reached out to us, said, Hey, I don't have any one of your payment providers yet.

Should I use Stripe? Should I use PayPal? Should I use Square for the average sole proprietor or small business? We always went with Square. And also if their business extended to the physical world where in time they may need to take a credit card payment in person, we could help them in that place too. So how it's evolved over the last four years is we've got more and more users using our simple add-ons, and we've been working on a new product called Payable Pro, which has a bit more robust features, and it also handles some of the in-person stuff. So it has kiosk built into it, and it has in-person workflows, so when somebody arrives, you can scan their ticket

And check them in and check them out. It has more of that full robust dashboard, whereas our traditional Payable Apps runs inside of the spreadsheet. And so spreadsheet is great for simple workflows or custom workflows are really unique things. But for some of our bigger users who are using us for things like ticketing or kiosks, we have the new Print Payable Pro platform. And with Pro Square is our only partner just because of how great and easy it was to extend the e-commerce capabilities to the online, the physical world capabilities using the card readers and the card reader APIs were quite nice.

Richard Moot: So in the very first iteration of the app, and you're going to have to make, because it's been a while since I remember how this worked, but was the very first version built using Square Checkout or was it using the web, I don't know at the time, might've been SQ Payment form or Web Payments SDK, what it was initially built with. And in that initial flow post filling out a Google form.

Ryan May: Yeah, so we're entirely a web dev shop, so we do no native apps, so no iOS, no Android, everything is a web app. And so we used Square Web Payments STK, so it's all just the extra JavaScript that you include and it has a little iframe that appears on the page, and you can include your Apple Pay button and your Google Pay button and that right on the page. So generally what we do is we transition users from the Google form to our hosted checkout page, almost kind of like an invoicing platform might do. Like you were used to paying an invoice with QuickBooks, you would go over to the QuickBooks page. So you come over to our Payable hosted checkout pages where we kind of take the data that was submitted in the Google form, automatically turn it into a checkout page, almost like your cart or your payment page. You would enter your data right on that payment page. And because Square does all the latest client side encryption, the users are typing their credit card data, if they do end up typing it into a tiny little iframe that encrypts the data and sends it to Square. So we never touch, or the customer never Google or anybody never touches the user's credit card data or their customer's credit card data. It's all encrypted by you and it goes off and comes back.

And then over time, we got into subscriptions. So we expanded from doing just single one-time payments into subscriptions using Square subscription engine as well, and taking cards, putting them on file, and then attaching them to subscriptions for the user as well. So we also have a really easy way, if you were say a gym membership or you wanted to make six payments for a more expensive coaching or basketball class, you could divide that up or offer those type of solutions to your customers right through the Google form as well.

Richard Moot: And what have you used, it's a web dev shop. What is your tech stack of choice and has that changed over time?

Ryan May:: For me, it's pretty old school, so I mean, it kind of dates me a little bit. It goes back to my history of being an engineer. So when I went to school, I learned PHP and I learned PHP. It was the first web, pretty much the first programming language I actually learned. And so because of that, for the rest of my career yet to this point, I've stuck hard. I've been a hard PHP advocate, so the core backend is just PHP MySQL, so it's a lamp stack and we use Google Cloud to kind of run our Google Cloud SQL and our infrastructure, which is good because a Google partner, so it sometimes makes sense. I always say the servers are close to each other, they're in the same area, which helps speed things up and keep it in a closed ecosystem. But yeah, a good old fashioned lamps stack that has been around for decades.

Richard Moot: Nice. And so with that, are you using a particular PHP framework or are you just going plain old standard PHP?

Ryan May: No, A lot of it is vanilla PHP starting from a starting point, and we've customized quite a few of the libraries. So what we've done is we've abstracted our main bread and butter is almost like we're a gateway of gateway, so we've abstracted a lot of the concept of what is going on behind the scenes with Square, and we have that same logic for PayPal, Stripe, Razor Pay, Rapid, and so generally the background of that frameworks is that. We don't have a lot of, there's not a spot on our site where people actually even log in and look at their data, so we are essentially a connector, a connector. There's not a lot of UI, there's not a lot of tables, there's not a lot of things going on that we are using. Our framework would add a ton to it. Nowadays you probably start with some sort of API framework or go a different way, but because of the way it was born, it's generally a vanilla PHP connector.

Richard Moot: Well, I mean from what I've understood in the tech industry, it seems like PHP and Lamps Stack is actually making a little bit of a resurgence in the indie hacker community because it seems like it's tried and true, it's reliable. You can let it just sit there and run and it's not difficult to maintain.

Ryan May: Yeah, it's tough. I think a lot of the times your young junior engineers want to work on whatever is the sexiest or latest thing, and so sometimes it might be a little boring to them, but I feel like I've converted our team into slowly starting to love it a little bit. But at the end of the day, what's interesting about code is I've seen some startups, crazy fuss about the latest technology, the latest load balancing, the latest optimization building these really complex, like you could log into Google Cloud and create an extremely expensive platform for a product that people aren't using. And we talked about it a little bit before, but one of the most important things is how many lines of code can you write for seconds of time you're actually saving a customer? And that is what is really nice about a lot of the Payable Apps is they're very invisible. There's not a lot of code there. It is generally what we wanted to do is go, how much time can we save the average small business for a small amount of codes, like a small amount of lines? And that's the most rewarding thing as a developer when you're able to have 250 lines of code that take data from here and put them over there, but it saves people hours and hours of putting things manually into a spreadsheet or doing something by hand, and so that's kind of where we've tapped into solutions like that.

Richard Moot: Yeah, well, I mean I think the way that you put that about lines of code for minutes saved or hours saved for end customers really kind of positions that in a really customer-centric way of, I mean code is supposed to serve a purpose, it's supposed to be understood by people, but it's also supposed to be solving a problem, and if you're adding in code just to add an abstraction because it'll be easier to understand later. I mean, there's a value to that, but I mean it's harder to see that in the near term.

Ryan May: Yeah, I mean, I've worked as an engineer at both tech startups and at bigger payment companies, and sometimes the hardest thing as an engineer is not knowing who your customer is while you're doing all of this engineering work and not really knowing how you're going to save them time and why they're going to love it. And I think that's the hardest part. What we did at Payable was, so when I started the first product Payable Google Forms, I already had the customer. My co-founder was the customer of the product, so if I could save her time, that was my whole goal with it. And I think that's how every engineering product should be made. Find your target person that is going to use this and work closely with them to build them what they need. That way you're at least building something that one person is going to need, and then you hope you'll be able to find five or six or 10 or 500,000 people just like that person. But it always is great to start with one person in mind and work with that customer while you're building it.

Richard Moot: Yeah, I mean it's so important that, I mean, I can entirely agree with you at times of working at a larger company that the engineer working on the feature is so far removed or disconnected from the end user. For us it would be say sellers. And so getting to work closely with that use case is crucial to providing value. I'm curious, as you've gone from working in the payments industry, you're still kind of in the payments industry, but more I guess hands-on with working for your end customers, how has that evolved over time in terms of writing software versus managing a business? Has that evolved or changed your perspective on engineering or business in general?

Ryan May: Yeah, I mean, I loved engineering. When I first got into it. I remember I took my first PHP class we talked about, and I was still, I think second year university. And I was like, wow, okay, so you could just, this concept of, okay, I could make a form and data could go into a database, I could do something and then I could build software. This concept was really exciting and I loved it. I also found it to me to be soothing, almost like painting. So some people love to paint and they'll sit down and they get to be a little bit creative. And as an engineer, I also found solving these problems and building little tools to be kind of like a soothing process.

After school, I went to California and I worked for a startup there, and I loved it. It was so fun to work for a company and build something bigger than I could do on my own. And we were building a product that was bigger than what I could do. I loved that so much, especially in the early stages where you're taking that first customer and you're building something, you have that build stage. It's a really fun and exciting part of any startup. And I always loved working on the payment stuff. When you're the engineer that gets to make money move, it just is a little bit more exciting. You're like, I'm putting in credit cards and I'm moving money from here to there. And it was always an exciting part of being an engineer. So when I changed roles, I always wanted to be somebody who got to move the money. I loved being the engineer who specialized in either working with different payment providers or building those flows out. Eventually later in my career, I was able to be hired by one of the bigger payment providers, and that's where it gets a little bit more abstract. So as an engineer, you start to lose connection with who your end customer is.

Sometimes you might be managing a product or a suite or an engineering team, and the roles and the tasks, the stories that come in, you're often pretty removed from. And it was even surprising at times to go like, we're working for this big company. We're working on something, maybe it was related to point of sale for quick service restaurants, but none of my engineers have ever worked in a quick service restaurant. They don't know what it's like to have a KDS display pop up three things in a line versus two things are a line or how a bump screen works and all of these different things. And so it's really tough. You become abstracted quite quickly from who your end customer is, and it can be quite difficult as you get into that position. A lot of really good engineers to just specialize in, okay, well how do I do this one piece of the pie really, really well?

How do I write database queries that are super, super fast or how do I do infrastructure or architecture? But you lose that connection with the customer, and I think that's the hardest part. And so for me as an engineer, I always wanted to go like, well, what's going on? Who's making these decisions in this big room that they're giving to us as engineers? So you'd sit there and you'd get your user stories and say, Hey, this week you're coding this, this, and this. And I was like, where are these coming from? Who is giving us these instructions?

So later in my career I said, well, if I can learn how to code, I can learn business. So I decided to kind of go back to school and do an MBA, and so I could kind of go into that room with all the business people who were like, oh, Ryan, you're just an engineer. Stay in the engineering room. And so I think that was helpful in a couple ways. One way I thought it was going to help me in the corporate world, like, speak corporate speak instead of geeky engineering speak when I would sit down with executives, which it did a little bit and it helped me understand a little bit of of accounting and revenue recognition and some marketing and some things like that.

But the other thing it did is it made me a bit more confident that I could do those other aspects and start my own company. And so I think it was after that a little while that I realized, okay, I think I have the skills to not just make code, but then make a product and market that product and do all of it. And so after a little bit of time, we created our first product and then I've broken out onto my own. So that's kind of my journey from a developer at startups to a developer at a bigger company and then through product manager into starting my own company.

Richard Moot: Yeah, I mean, it sounds like, and I don't want to be putting words in, but it sounds like going through the MBA program also helped give that reliability or that confidence to be able to go run your own company or start your own company because now it's like while you can understand the larger picture of how to connect things between understanding product, I mean, you could probably understand from an engineering perspective, product market fit loosely, but I feel like it probably gives a more concrete understanding of what to be considering in terms of how do we market this thing, how do we talk about this thing?

Ryan May: Yeah, I mean definitely I would recommend it. It's hard to recommend formal education these days anymore, especially now that AI is out. And I could talk to ChatGT about almost anything, and he's faster than our lawyers and better, so sometimes it's hard, but what it does give you is a forced sampling of a whole bunch of stuff. And a solo engineer can be really, really fast when you are a good solo engineer. You can build things in a day or in a week that would take a big corporation years and it would still fail to actually hit the right thing. And so you're really giving yourself all of those other ingredients, all those other tools, just a little bit of graphic design, a little bit of marketing, a little bit of exposure to your accounting, to your books. And then the other thing is, as an engineer, you can start to automate all the other pieces that the average business wouldn't automate. So if I was just an ice cream shop or I was a restaurateur, I might not look at where all these other inefficiencies are in the rest of the business cycle. Whereas as an engineer, you can fix those other inefficiencies with code or with software. And so having a background in tech and building for tech also helps you automate the rest of your business as opposed to making the rest of your business also just inefficient or outside of the scope of what you're doing.

Richard Moot: Yeah. Do you feel like maybe some of that is, it can sort of spawn out of necessity? I know that we try to automate things in larger companies and we do, but it does require a lot more coordination and planning and consideration of maintenance, whereas on the smaller side, I don't want to say it's like you can choose to automate things but then not be married to them. But I feel like some of it you just have to automate out of necessity. We don't have the bandwidth to keep doing this process over here, so it's got to be automated. I'm just curious, how do you evaluate that?

Ryan May: Yeah, I think when you have a super small startup, we are only four or five people, you start to realize which tasks get tedious quickly. So you go, okay, what are tasks that we are obviously a computer could do? And then we try to pick up those. And we have an engineering team. So the other thing I always go is I have an engineering team. There's no reason that that engineering team is limited to just building customer facing product. They can also build internal tools, dashboards, reporting pieces, something that automates receipt syncing for our QuickBooks or for our accountant. So we have a lot of things that the team works on that maybe not are always customer facing. So whereas when you're at a big company, you don't really have, you're not taking your engineers who are working on the Venmo app and assigning them to help you with payroll automation or something like that.

So I do it because I find it's also good for the team to look at other APIs that are out there. The good thing about SaaS, we were talking about there's pros and cons to software as a service. The pros are these days, many of them have an API that's open and out there. And if you have a company that has engineers like us, well we can interface with those and use them for the average small business, having APIs for QuickBooks might not be the easiest thing for you to do. How is that supposed to make your life easier? So they end up using plugins or add-ons. And so, yeah, that's where our business is really quite invisible. We don't want you to have a separate login. We are a plugin or an add-on. So for people who don't know how to code or can't make these connections, and so we have really tried with every part of our business to automate as much as we can.

Richard Moot: Well, I love to hear it because I mean, it feels very aligned with Square. I mean obviously I'm very biased here, but folding into and sort of fading into the background was something that was very essential to the initial designs with Square, we designed our payment hardware to sort of blend into, I'm talking about in the in-person experience, but it was intended to be blended into many different types of business. It wasn't intended to be sticking out in your face when you needed to make the payment. It was there when it needed to sort of fade away and allow you to be focused on your business and the customer interaction.

Ryan May: I agree a hundred percent. If you're building software for small and medium sized businesses, you want their brand to be front and center. They are so proud of their brand. They've spent time getting customers. If they're a yoga company and they've chosen to paint their whole building pink, you want that, their form can be pink and it can have the logo at the top. And sometimes payment companies, you might look at, oh, a QuickBooks invoice came or something like that, and it just looks like QuickBooks and it doesn't represent your brand. And that was one of the things I did like a lot about working with Square. Even when your card reader came out at the beginning, one of the first things you guys built for your card reader was that you could put different splash screens on it. So when it's just in its passive mode when nobody's looking at it, you could upload different screens and you have no idea how much the small businesses love that so that when the card reader is off, they could have a picture if they're a mountain bike shop of a mountain bike coming around a corner, or if they're a yoga studio, they could have their pink yoga studio brand and just using their card readers as promotion for their own businesses or a sale that's coming up is super important.

Too many SaaS companies want their brand to be everywhere. Thanks for clicking this Calendarly link. It's Calendarly, this is calendar. And you're like, okay, I get it. I get it. There is a time to show your brand, but when you are supporting small businesses, the most important thing you can do is let their business and their brand shine as the front and center thing. And so yeah, with Payable Pro, the first thing we do is we let you pick your colors, we let you upload your logos, we let you have, she kind of likes to wear a Square logo, a long logo. What is it about your brand that you want to have? And then we kind of take a step back. We want to be invisible. We want your brand to look professional. And that's one of the biggest complaints people get sometimes about a Google form as people want it to look professional. I don't want it to say Google or Powered by Google. I want people to think my brand is big. And so that's the other spot we're coming in with Payable Pro is to help kind of disguise that it is a Google form going on behind the scenes there and that it looks just a little bit more high end and professional like your brand.

Richard Moot: Yeah, no, I mean it makes perfect sense because as micro sellers grow into small businesses which then go into mid-market, and we've seen this within Square, there's this natural propensity towards feeling like, oh, I might be outgrowing this thing and I need something that looks like I have more identity with. And what you said about brand is, I couldn't agree with it more because as the business owner, of course, you're obsessed with your brand. You don't want to be tacking on everyone else's brand. And of course there's places where you might want to have some other brand when you need to build trust. I know it's very common on say, checkout forms, particularly when they do a redirect. When I say this checkout is powered by, and then trustworthy brand because they're like, otherwise, that experience can be really jarring to buyers when they suddenly go, wait, where am I? I don't feel like I should be putting my credit card information in here.

Ryan May: No, 100% we found on the bottom of our checkout page as we always have powered by Square, where are you putting your credit card in those locations? It does build trust. You're like, I understand there's no skimming. This isn't a phishing scheme. This is going straight into Square. And Square does have that brand, brand trust. So when it comes to payments, having it in the right places you're right is a hundred percent crucial.

Richard Moot: So this is a little bit of changing gears, but I wanted to touch back on a previous topic as we were talking about automation and using AI as part of your business, I'm curious, how much have you, for Payable or in general been leveraging this for software engineering or business automation? How has this been something that you've been using?

Ryan May: Yeah, I mean, everybody's typed into chatGPT and seen how cool the responses can be and how amazing they are. And so as engineers, there's multiple ways that our team has been touching on it. So one is our IDs, so the code editors that we use to code these days, it's pretty amazing how the ones that have AI built into it as you are typing a new function or a new piece, how good they are at anticipating what you actually want. And so that's the first thing that's been pretty amazing is the team. You still need to be a good engineer and kind of understand and read and understand the code. They're not coding for you just yet, but the code editors are really amazing at doing predictive algorithms and tests as to what you want to do. Look at all the rest of the code on the page correctly, name your variables. It is really quite unbelievable there with the IDEs. So we've been doing that for a little while now. And then the other major change we made is customer support, so we have a ton of knowledge base. So we had this really long knowledge base. People get confused at times about how you set all this stuff up. And so we've written help articles and we've made help videos and a lot of it is helpful, but at the end of the day, we always had chat support on our site. And if anybody is a startup or at an early stage of their business, whether it's a software business or a service business or any type of business, I definitely recommend putting a chat like a little chat icon on your site. You don't have to code it. You go to Crisp or Intercom or some of the major supporters of chat and you can set it up. So even if you're a sole entrepreneur, when somebody chats you, it comes to your cell phone as a text message and you can reply back wherever you are.

But chat is this low barrier to entry where people are willing to engage with your business as they're trying to figure something out. So when we were getting started, it was me on the chat box and people would ask questions in there, and as a sole engineer it was invaluable to be like, okay, they're getting confused about this step. This is the third person that's got confused about step three, I'm going to have to change the way the UI looks or change something to make step three happen automatically with step two because it is weird that I make you click two buttons. And so when you have a new product that is invaluable. But as we grew, we got so many chat support requests that it was unbelievable, and a lot of the time it was the same thing. And back in the day, our chat bot was so it was hard, you had to say, if you see text that says fees or cost, send them to this article and try to have them figure. And it was painful for our customers to have those type of interactions.

And the new chat interactions are absolutely unbelievable. So I am blown away by how our chat support works right now. Our AI chat support solves probably about 60% of our chat interactions. The person says, yes, this helped me and the AI person solved it, and the other 40% now go on to our team and a human will look at it or a human will step in, but it is able to take those complex help articles that we've written and point you at the exact right spot. So somebody is going to say, Hey, I'm getting payment method not found, or I'm getting free order. It's like, okay, that is this article, it's here, here is your exact answer. And it unblocks people. It gets them moving forward with your product quickly. And the most important thing you can have as a product developer or somebody who's selling software is you unblock people and get them moving forward.

So with support AI has been unbelievable for us. So we spent a big chunk of time working with that, and it's crazy how far it can go. So we are working on better integrating it so that when you talk to it, it knows which Google forms you have set up, it knows which payment provider you have set up. So it can give you more tailored information when you're trying to say, Hey, how do I issue a refund? We could tell you the specific square steps because we know you who's talking to us is with Square. And we would tell that to the AI and the AI knows the square refund steps and it will walk the person through how to issue a refund with Square. So yeah, it is really for customer support. It's pretty amazing.

Richard Moot: Yeah, it's awesome to see it being leveraged that way. And I think it's probably really, really helpful that you had such detailed documentation for it to more or less be trained on because we did a similar thing, I can't remember if it was this last year or before that, but for our developer forums, we had released a Square Dev AI, which was trained on all of our, initially it was trained on our payments documentation and basically was extremely, I think even to this day, it works in sort of a semi-automated kind of way where somebody posts a question into our forums, it'll generate a proposed response, our developer success folks will review it and make sure like, Hey, is it on base or off base? And then I don't want to be totally quoted here. I think that they also can use that for retraining, so when it is correct or isn't correct, it can sort of be like do some sort of reinforcement. We've seen a very similar success, and it was in large part because we had such great robust documentation and now it's very well versed in almost our entire API suite.

So most of the time it can just immediately give an answer to someone. It saves developer success time because it's answering the types of questions that they don't need to go and point somebody to articles for. And in those instances where somebody's asking something that's so bespoke, the AI couldn't ever really answer it, our dev success is already going to be able to say like, Nope, I'm just going to go ahead and step in here and answer this for folks. And it's just been a huge boon for us and for our developer community now they're getting answers that they need that they might not be able to figure out on their own.

Ryan May: And for me, 60%, getting self-service quickly is amazing because as much as we try, we're a small team, and I always go, Google doesn't have a human that you can talk to and Microsoft doesn't have a Google human that you can talk to. And so we do as a small team, we are trying to get and service as many small businesses who have questions. Sometimes those questions err on the side of like, I just need help figuring out how to set up a Google form, or I'm confused at how spreadsheets work. And it can be tough. And what's been nice is we've been able to take our AI and let him learn a little bit more about, okay, this is how you set up a Google form. This is how you manage spreadsheet basics. And so sometimes you look at these in depth conversations that people have been having with our AI and it's unblocking them and it's moving them forward and it's the most important thing we can have for our business.

And then, yeah, every time he doesn't get it right or she or the AI God, they learn from the human answer that's put in, and that's really quite good, too. And then the last thing where we're going with AI, it's weird, but we're on a couple of new projects and the thing I like about our company is always just trying to come up with different things. And so we do a lot of hackathons is something where we do with the team to try new ideas. And so hackathons are great, you can go to different places to find them, but Devpost often has, they're kind of an aggregate of all the different big companies that are putting on things.

And if you're thinking about trying to come up with a product idea or start something as an engineer, I always recommend going to Devpost, look at hackathons that are going on and see what cool companies have new APIs that they want people to build new ideas with. And you might have something in your life that have a solution for, or you might see another solve, but build and test with these hackathons because it's a really good way that number one, you can win money and it's a perfect little business case for you as a startup because usually you submit a little two minute video and a demo of your code and you had to solve in one of these tasks.

And that's exactly what it's like to launch a business is you have a solution, you have a problem, you build a solution using technology for it, and you build a two minute video that can market that technology. And so if you're thinking about being an entrepreneur, trying hackathons, two or three of them is a really good way to get your name out there. And if you're looking for a job or work, many of the companies who put them on are higher the developers or the people who have submitted ideas. They use them for headhunting or sourcing. So if you're thinking about doing something like that, go do it as an aside. So how that transitions into back into AI, one of the things we were working on is we have this other app that we are working on that is looking at ways to automate other things that are coming through your inbox.

So you have information coming into our inboxes all the time, and sometimes people QuickBooks does its best to try to figure out a receipt and match receipts and do other things like that. So we've been using AI to try to help build us self-healing regular expressions. So how this works is I get an email and I'm expecting it to say total and transaction ID in these two different spots. And so we have a tool that parses an email that comes, maybe it's say a receipt and it parses it and it puts it into the database and updates an order for it. However, what happens all the time is people are changing the templates and the skins of the emails that are coming out and they keep breaking. You would go, ah, we're no longer able to scrape the right data out of this. It's gone.

And so what we've done is we built into the flow, the ability, when our regular script doesn't deliver the expected info, we then use the chatGPT API to send it the email template and we ask it to help us locate these things and write a new regular expression. And we can take that new expression and add it to our database of attempted expressions for that email provider. And we can sell code is self-healing itself, so the code is smart enough to now fix it itself on that first try. So we take situations where the code is breaking a lot. So as an engineer, you look at your code and you go, why is this code breaking? We're dependent on a third party. That third party is changing stuff. Could we, instead of hard coding it, use AI to look at it, give us the new code that we need and save that new code in our database and then automatically try a collection of our code.

So we are attempting to in situations where we run up with infrequent errors or things that are changing a lot to start, and we don't want to use AI every single time because as we know, AI is a little bit slow and it's a little bit expensive to call. So what we want to do is use it to get a new algorithm or a new regular expression or a new way we can parse the data, save that, and then we move on. And itself fixes itself after it's done it. So if somebody changes their template, if an email provider changes its template, our initial scrape will fail. We'll end up without the right data. AI will figure out the right scrape, we'll run the right scrape, it'll be solved in about 15 seconds. It just fixes itself. So we're trying places like that to do things like that.

Richard Moot: That sounds awesome. I mean, you're inspiring me for an idea around an auto API migrator, but only because I want to envision a similar type of thing of switching the API version, testing out a feature set, seeing what fails, and then trying to do adjustments in the code to be like, well, this is what a proposed change to migrate to this API version would be granted very self-serving. One of the other things I do is I lead API design here. And so I very much want to get people moving along on our API migration story.

But yeah, self-healing code for something like this just sounds so useful. I can't tell you the amount of times that I've had to build my own parser for scraping data from blog posts or something to assemble things. And every month or so I'm having to go and retool it and readjust it because the stylings, the tags, the IDs got tweaked a little bit and I needed to go fix it. And yeah, now it didn't even occur to me that I could use something like open AI's APIs to basically adjust it and figure out how do I throw this into my database to fix my parsers

Ryan May: And it's going to get faster and better and better. And there's times where sometimes I go, well, do we even need to write an app? Just give it the HTML, let the AI figure it out. It knows the layout, it knows logos. It's really good at doing the parsing right now. It's just a little slow for something that's coming so quickly. So for us, we're using it, we're phasing it in that way where when what we had regularly doesn't work, then we'll pop it in. But I can see a future where as engineers, you're no longer having to do manual parsing. You're just kind of telling it, Hey, can you grab me the transaction ID and the total amount off this? What currency was this invoice in? You can just ask these type of questions and it's unbelievable. It's really amazing.

Richard Moot: So exciting. Well, I see that we're here. We're just at about time. So I want to give a huge thanks to you, Ryan, for joining us here and telling us about Payable and your journey along here. I recommend to anyone if you are a Square seller, and you're interested in learning more about Payable, you can find their app in the Square marketplace. Ryan, is there any other way you want to plug for anybody who'd want to learn more about Payable and what you guys offer?

Ryan May: Yeah, you can always go to Payableapps.com and check out our apps and go to the Payable Google Forms. If you've created a Google Forms, they have an add-on section and just type Payable Forms, and you can add our add-on right inside a Google form there, and it's compatible with Square and it'll get you up and running in no time.

Richard Moot: Awesome. And if you've got a project with Square, we'd love to hear about it. Reach out to us on our Discord or on X at SquareDev. Don't forget to subscribe and check out developer.square up.com for more. Keep building and catch you next time.

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 its core functionality handles really well. And the other thing I would say is that the bigger the gap between a group of people producing an API like the communication gap, how hard it is for you to communicate, right? Are you on the same team? Are you in the same organization or are you not in the same organization in completely different countries? Like the gap between a company's engineers and open source or third party API consumers, the farther you are towards the side where there's a big communication gap, the more GraphQL helps I think because it lets the consumers customize the data that they're fetching without the API producers needing to build a bespoke endpoint that is exactly what the consumer needs within an organization where you're very close, you can spend the time to do that, you can build a custom API for somebody that meets their exact need, that's going to be very performant and it's going to be very optimized. But with GraphQL, you can get something that works for a broad range of use cases and you don't need to communicate and collaborate as much between API producer and API consumer. So I think that helps a lot for public APIs

Micheal Watson: A hundred percent. I mean to really ground that, one of the things I think about, let's say you have a REST API that you're offering out as public, you have this developer portal. You're trying to make everything self-service, right? Developers just sign up, get an API key, start making API calls. But here's the thing, all of your APIs, you have some functionality that you provide. Think of your existing website, your existing apps. There's things you can do with your business, your product, and people are trying to add flavors of that using your REST API into their world. Now, the thing I love about GraphQL is it actually gives you a secret benefit as a business that I don't think gets called out enough. You have a lot of tools today like AI, copilot, where I give it an open API specification and it writes me some fetch logic.

But what that really is starting to point at is that custom code that all of those third party developers are starting to write. Now, how confident are you that all of those are being optimized? Those are all written the right way. How many times have you had a REST API where you had to cut off an API token because someone was hammering your REST API, when really they just didn't follow those docs pieces? I mean, I'm guilty of it when I use a new product, I don't go to Docs first. I just start using it, clicking around, hammering it with calls. But with GraphQL, when they write that operation, they add those fields of exactly what they need. The execution actually on your end as the API owner is standardized. It's known. It's structured, right? This is where the declarative aspects of a GraphQL schema really come to your benefit.

So you now have an understanding of like what's actually going under the hood. And I've actually known a lot of GraphQL APIs you mentioned it's not REST First GraphQL or one or the other, and there's a lot of GraphQL APIs that actually call directly just to the REST APIs under the hood. I've seen that very common, and there's nothing wrong with that actually. It's a very known way of this type of operation is going to make this many REST API calls, and it becomes a way of you controlling that orchestration and it's also a benefit to the other developer. They don't have to worry about that orchestration anymore. Right? It's kind of just handled for you with just riding a GraphQL operation.

Richard Moot: Yeah. In fact, my first talk I ever gave on GraphQL is literally just trying to take a REST endpoint and just wrap GraphQL around it and basically saying like, Hey, here's a way to interact with my REST endpoints. And it was just stitching the two together. And at the time, I didn't feel like I actually understood a whole lot about it, but it was very interesting to just see how much more useful it became, especially because that separation of concerns from the front end developer who's just going to consume this doesn't really have to think very deeply about how are they actually creating these queries. And so that separation makes it a lot easier for them. I've always had this notion, which I would love to be dispelled, is that for the front end of a graphical API, amazing developer experience, but that sometimes on the backend can be this crazy amount of optimization or way of trying to power these queries. And that's why we end up having things like evaluating query load or depths to make sure, hey, we're not going to overload some relational database queries.

Alex Hancock: There are some gotchas for sure. I mean, there are common things you have to handle when a resolver could be run on a bunch of objects in a list, there's a known solution for that with data loaders. There are things that come up of GraphQL, but I would also say that the complexity introduced by almost any backend solution that's going to provide an API right performance optimization. You see people do all kinds of crazy things with needing to cache certain results, different endpoints being hard. And I think one advantage GraphQL has in this area over other API technologies is that if you're fetching and returning a big object, if there's a field or a few fields in an object that are really expensive to compute and they don't get queried in a GraphQL operation, then never, that code never even runs, right? Whereas responding to an RPC endpoint with a fixed set of data, unless you're using field masks or something like that, it's always going to compute that data even if the client doesn't need it. So the GraphQL Hertz performance myth is kind of, it's like, yes, there are some challenges that get introduced, you have to solve them, but there are challenges with any other API technology as well.

Michael Watson: Yeah. I also think you put some of those challenges on the client developer without GraphQL, those challenges don't necessarily exist from the performance standpoint. You're just kind of like, ah, I don't see them just that client developer writing that app because everyone has this, right? You build this nice UI and then someone's like, Hey, I don't need that data to start interacting with the page. I want a faster time to first interaction. So how do we progressively load that? And then you start thinking of the component structure in your client app and what you're doing with suspense and starting to handle multiple of these calls. There's also some really great solutions in GraphQL. One of the things that's come out recently in the past couple of years is at Defer, which just lets a client developer put some metadata in their operation and then actually have that data chunked down. So now you could really have one query per page and then progressively load that information into those individual components or have a fragment for an individual piece that's like a micro frontend strategy, which is really popular now.

Richard Moot: In fact, I think you put it really well there that a lot of the times, even in REST that we push a lot of that complexity down to the client. In fact, I just recently have been working with teams on trying to implement what we all fully acknowledge is a GraphQL feature within our own REST endpoints of we want to have this thing we call an includes pattern where you could say like, oh, I want to fetch an order, but please, I'd like to include customer data. Can you enrich this to go fetch related customer data? And as we're codifying it, we're like, we know that this is GraphQL, we would say, you can just go use GraphQL for this. But in certain contexts they're like, well, I really don't want to switch everything over to REST or from REST to GraphQL, so I'd rather keep it in one. But that's why we limit the scope of it and say, yeah, you can fetch one thing, but if you need anything more complex than this, please go use the GraphQL endpoint.

So one thing I was wanting to talk about is in the growing of, it doesn't have to be public APIs, but in the growing of APIs, I know when we first started out on this, GraphQL was a little bit earlier, I think there was mature groups out there with it in GitHub who had public GraphQL endpoints and everyone was getting really excited about it. So GraphQL has not gone away. It's only grown more and more. I think one of the things I'm curious about to talk with both of you is how companies can actually grow their graphs. Because I think there's working with legacy software, legacy things, how do you sort of adopt different data into this? And I'm kind of leading into wanting to talk about federated GraphQL. It sounds like a really useful strategy for compositing in what you want.

Alex Hancock: Yeah, I think adopting federation is a big first step for a lot of people. I mean, especially if you're in an organization or working in a project that has a microservice architecture, it's a really nice thing to add in. And I think it's nicer the earlier you start with it in mind, if you design your servers, your microservices with GraphQL as an interface from the beginning or from as close to the beginning as possible, I think the nicer, the nicer and nicer that experience is for Tech Stacks and organizations that are microservice based but are older and have historically used some other API technology, it's a little harder. But I think the story is getting better and better there. And I think the way to grow graphs, the key driver to growing a graph in my view, is to make it as easy as possible for data producers to add their data to the graph. If that's too hard, if that takes too much work, then the data producers will ultimately just do something else. They'll do what they need to get the data into the client app, even if that means that the client developer has to deal with some unwieldy interactions with multiple APIs where they're getting more data back than they need, those kinds of things. The best driver for getting more data into the graph is just to make it really easy to get data into the graph. And that takes work, right? That's the platform part of GraphQL. That's why many companies have a GraphQL platform team. That's what we're all doing.

Richard Moot: And just for anyone who's listening here who might not be familiar, could either of you give a quick explanation of what is meant by a federated GraphQL or a federated schema?

Michael Watson: Federation's near and dear to my heart, I actually started with the Apollo team back when we first announced it. Well, I started with Apollo team before, but when we first announced Apollo Federation, which was the early version of really what we're talking about back in 2019, really when you're talking about federated GraphQL, what federated GraphQL really is how can we take multiple GraphQL schemas and compose them into one shape and then be able to take an incoming request and then break that into the execution across multiple GraphQL APIs. So really what you do is you're adding in some metadata into your GraphQL schema. And this is really like I'm identifying this thing, this order, it's an entity. And what you're able to do is in that composition, all of that metadata is really coming together of here's those connection points between those entities and then here's where those entities live, those distinct URLs, service clusters, whatever they may be.

And then your modern GraphQL stack is really, you have some graph router sitting in front that's able to take an incoming request and it generates what we call a query plan. And that's really, I think of it as like SQL explain. It's a plan of based off this operation, we're going to execute across these downstream services in that. And it gives you a very structured order, this is exactly how it's going to happen. And it's also nice to see, like Alex was saying, if you don't have that one field in there, you don't see that hop, right? And then you add that field, then you see the query plan add that additional hop, what that really is, it's trading off the code that we would be writing by hand, that optimized code and maybe a BFF backend for front end. And it's really replacing the form of a generated query plan from a structured algorithm based on that composed schema.

So that's really Federated GraphQL. And the thing I love about it too is it gives you the flexibility to kind of go into whatever architecture you have, whether you have microservices today or maybe you have a monolith and you want to start splitting off parts of that monolith to maybe move a little bit faster before you get to two. You still have to have one. I always say that, and it's very quickly that you might be building the one you're like, oh, we need two and more right away. And I always encourage that. I think it leads to a quicker development cycle.

Richard Moot: And it also seems like it would give a lot of benefit. I know that we've seen this here at Block is that when it's federated that teams can own their part of the schema more easily and more readily. So we own this part of the federated schema. And so it's not like you're having to defer everything to say the GraphQL platform team and owning that entire interface. They're just like, Hey, we've created this system and your ownership is over here, and we just ensure that everything gets stitched together.

Alex Hancock: I think the reality in most organizations beyond a certain size is that different core objects that are important to the business or the organization have data from multiple teams, from different groups of people inside the organization that need to be contributed to the same entity, the same business object. And the way that happens in technologies that don't have something like Federation is often really messy. How many times have all of us seen REST APIs or Protobuf APIs where there's a prefixed version of the same object with 90 different prefixes across the company, something so and so is a version of a merchant or so-and-so's version of a payment. And then the client developer has to look at all those and kind of figure out, well, is this the same object? Are they talking about the same thing or is this something different? Federation just it's a new approach that wipes all that off the table and there is a payment object and everybody can contribute the fields that make sense for them to contribute. And there's a merchant object and everybody can contribute the fields that make sense for them to contribute. I think it's a shift in the technology that actually more closely models the real concepts that happen that exist in organizations. That's really helpful.

Michael Watson: You're giving me nightmares for my past, Alex. I was at Microsoft before Apollo and I worked with a lot of O data implementations. If you're not familiar with O Data, they have a schema version for every model or the entities you define in it just so people can have different representations of the same entity. But that's actually one of the nice things about Federation. Also, we talked about being able to own your own portion of the graph. Federation also has the concept of entities being multiple representations. So one team, one org might look at an order a certain way. Another part of the organization might look at that same order entity, but through a different set of key fields. And that's very common in enterprises and businesses that have been around for a while because you've adopted new technologies, you've maybe acquired a couple companies over time, that growth, that change over time, a lot of people talk about is technical debt. I don't like the word technical debt. I think them as technical assets and it's how do you unlock them? And that's why one of the reasons I really love GraphQL is you can modernize that legacy service in your federated architecture and now you're opening it to all the client developers. So I remember with O Data, if you were a C sharp client developer, there's a lot of nice to haves in there. You're building a React app. Well, half those nice to haves just disappeared. And what about them and what are they doing? But with a federated approach, you can expose those various different APIs, whether it's in C Java, whatever it is, there's a GraphQL library for that that you could bring together into a federated architecture.

Alex Hancock: Yeah, it's definitely a really helpful advance in the API technology. And I think Federation's kind of unique in my view as well, in that it is a benefit to using the GraphQL ecosystem broadly that Federation exists. And I think the reason it exists in GraphQL comes down in part to the underlying design of GraphQL, the field specific nature of GraphQL kind of makes something like federation possible. But this concept of merging multiple different data sources into a single consumable API for the client and merging their schemas in a logical way, that the big picture of what Federation does, I think is something that I have to believe that that concept will be replicated in other API technologies. I think it started in GraphQL in part because GraphQL’s really, really good at enabling it, but it's kind of a differentiating factor for GraphQL that Federation exists. Nothing like it really exists at scale that I'm aware of in other API technologies. So it's really nice.

Michael Watson: Actually Open API specification just released last year. It's called Arazzo. I might be saying that wrong, but that is a spec where they're trying to be able to compose multiple open API specs together, but that still doesn't include what is that router thing that's going to actually orchestrate those requests. It's just more of here's a semantic of how to describe that. That's really what Federation started almost six years ago now in the GraphQL space and is starting to make its way towards the actual GraphQL spec.

Alex Hancock: That's cool. It's bound to happen. It's just a matter of time that it'll make its way out of the GraphQL ecosystem.

Michael Watson: A hundred percent.

Richard Moot: And I'm super thankful for it because I mean, Alex can keep me honest on this. That's a large reason or way in which we were able to offer up our public GraphQL. We initially started with an internal GraphQL building that out, getting all the data connected, and then it was a matter of like, Hey, we're just going to create a variant of this schema over here, and then this is the public version or the publicly accessible way that you can interact with us. And there's not this huge wall of separation between all of this stuff.

Alex Hancock: Yeah, the code that powers the public API, it's just a smaller GraphQL API that is a subset of the organization's giant internal Graph API, and we've talked about how that works using the contracts feature from Apollo and everything. It's a really, it's a natural fit and I think something people commonly do because it deduplicates the code. The code that powers the public API is just some of the resolvers in the overall graph. And that's a really nice pattern, right?

Michael Watson: Yeah. And I would say it's extremely common. I mean, us at Apollo, we do have a public GraphQL API, but five years ago we didn't. And we started with our internal API. I mean, I'm looking at our stuff right now. We have 16 different GraphQL servers that make up our federated GraphQL implementation, and then we create a sub slice of that schema, which is our public API. I know GitHub does the same thing. Their API is like 300,000 lines or something huge. But I've talked with developers there. Their internal is 10 times that size. So it's very common to have what is the internal GraphQL API, and then how do we create a slice of that of what is the functionality we want to offer out there to the public.

Richard Moot: So now I'm kind of curious, Watson, because I feel like being at Apollo, you probably get a more unique view into this, is that the typical progression that is many companies have been seeing of building up a really robust internal graph and then eventually just parsing out slices? Is it also basically baking something in on the internal and then figuring out, okay, how do we actually then push this into the public graph? Is that a more common development pattern that we're seeing?

Michael Watson: Yeah, so really there's this things grow to a size and then people want to break them apart. But when you go from internal to public, it's like you get this level of comfort with your internal GraphQL API, where someone asks the question of, Hey, what would it look like to do something like that? And typically the teams have already built something into their internal API that actually gives them what they want. I think of the most common I've heard is people putting what we call it a schema directive, but this is the metadata you add into your GraphQL schema and they have it as pre-prod and basically the server that they run, if it runs in production environment, it automatically strips out anything that pre-prod directive on it. So it's very common for people to have maybe some directives that are custom directives internally and then they strip those out.

I mean at internal is also a very common one inside of there. And the really nice thing about GraphQL is you have a whole visitor API that allows you really to manipulate change to whatever you want in that schema in a very nice ordered structure. So I always hear about the build versus buy, all this different type of stuff. I think one of the reasons GraphQL got so successful is because everyone had that flexibility in the early days with early adopters, if you really needed to figure something out or change saying in your schema, you actually could do that pretty easily. I mean, I even think of how we name things, the way we name things changes over time. And that's actually something that you can have a lot of flexibility in what we called it internally. We don't want that to be what it's called externally. And you can actually have that change is really more of a build script or something that happens at a compilation step before you actually run that server in whatever environment

Richard Moot: You're singing to the things that I love to talk about, because one of the things is I sit on our API design group that comes up with the API design standards, and the most common thing that I'm doing is trying to rename things for public consumption because we have a lot of internal names for things, and then I have to spend a lot of time with folks of that's not what other people are going to understand externally because they don't know what this type of resource is. And it also has five different meanings outside of the company. So that's definitely exactly the types of things that I think about day in and day out.

Michael Watson: I think of all the fun little names and code names and things we think of as engineers as we're building the initial things. But then when you're like, oh, how do we get usage of our API? It's like, well, we got to name things that make sense to where those developers builders are coming from. Inside of that.

Richard Moot: The amount of time that we spent just on trying to figure out the name for our square terminal API, even though it is terminal, it's for doing payments, but we endlessly debated that if we call it a terminal to developers, they're going to think that we're talking about the terminal that they're using on their machine right now and not the one for taking a payment.

So one of the things I'm curious about with the federation, and I feel like this is probably related, but I really want to shoo in a plug for composite Schemas and its relation to making sense in the organization around federation, I'd love to just have you tell us more about Composite Schemas and the working group and all that stuff.

Alex Hancock: Yeah, I'm really excited to see this. I think the Composite Schemas Working group was something that, my understanding is it ran for a while and then it paused and there actually wasn't great alignment on how to do it and how to have this concept of emerging GraphQL schemas be an official thing in the GraphQL spec. And then after the folks at Chili Cream worked on GraphQL Fusion was an alternative to Apollo Federation. And of course Apollo has the very developed federation spec that's been used by a lot of people for a long time. It's the best example of this idea in real practice. After those things got more mature, it was like, okay, well now we can all kind of see how this is going to come together into something that makes sense for the real spec. And I'm really excited about that because I think the federation idea of combining many small GraphQL APIs into a larger GraphQL API is such a good one that it makes sense as something to bake in as a primitive in the official GraphQL the standard. And then once that spec is there, we can all get lots of implementations of these core concepts like Schema merging, schema composition in all different languages, really good tools for taking an operation and generating something like a query plan that will go make request to multiple GraphQL servers. All the good bits that make up the Apollo Federation implementation just leveled up even more considered industry standard. Lots of implementations, lots of languages, lots of flexibility to move between different tools. It's going to be such a good thing for GraphQL. So I'm really excited.

Michael Watson: Yeah, I couldn't agree more. I mean, we've always been big believers of Federation. That's why we put out Apollo Federation, and we've also been very close workers in the GraphQL Working group, even before Composite Schemas. It did pick up and kind slow down. One of the things that I think is really important to say, Apollo has always been very committed to some global standardization of GraphQL Federation and within the GraphQL community, I've always been one of the people saying, Hey, if GraphQL continues to be a thing, everyone in GraphQL wins. That's what it is. I think standardizing this is extremely important. We've kind of always been the leaders of federation's the way to do it. This is the architecture. And when the opportunity came up for us all to start coalescing together on a larger effort, the Composite Schemas working group, we jumped right in.

I think there's, if you look at the notes in the working group, the agenda, there's been a really long standing inside of there. I mean all of 2024, there's monthly meetings from the primary working group, secondary working group. We have to have different time zones making sure everyone who wants to be included. If you're someone that's like, Hey, I want to be included in this too, you can go to the composite schema working group, GitHub repository, and you can just add yourself into the next agenda. Anyone is involved. And I love also seeing the collaboration. I like to think of us as, we've kind of been the leaders in the Composite Schemas working group, but the Guild is there. They have been great stewards of open source GraphQL projects and have done a lot of stuff. If you're using CodeGen, you're using some of the libraries they maintain along with a lot of other stuff.

Netflix, they created DGS, which is their Java GraphQL server that they use internally. They're very active in the group Chili cream, all the learnings from Fusion, they're active in that group. Benji with Graph File, Benji's, Benji's, an OG in the GraphQL space. And we're so lucky as a community to have Benji with everything he's kind of brought to the table. But it's really great to see it evolve to this. I was very lucky to work with all the early federation deployments. I actually, that's how I met Alex. I was one of the Apollo people in the room with Square in the early days talking about GraphQL. And it's been really cool seeing kind of these production deployments grow and continue down this path. So I think the standardization is absolutely necessary for the long living of GraphQL and where we're all going. And it just, it's really been great to see the growth, and I'm very excited for when it finally gets merged in. But it's very important to note when you're bringing something like this into a specification that has longstanding history, you got to be very thoughtful of how are we naming things, all of those things. We called it Apollo Federation, but now it's Composite Schemas Working Group. That's a great example, right?

Alex Hancock: Yeah, it's fascinating to watch the meetings, the YouTube videos of the meetings are really interesting. And the technical depth that goes into some of this decision making, it moves slow for a reason. The spec moves very slowly for a reason because you have to consider very carefully when you make a change, how is that going to impact the rest of GraphQL? And sometimes an idea might seem great for even the first month that people think about it and then you realize that it breaks some core thing and there's really no way around it, and you need to go back to the drawing board and come up with a different idea. But the thing I've really enjoyed about watching the new round of meetings that have been going again with the composite schema working group is the Apollo folks that attend have the most practical real world experience with an implementation of this that's been used thousands of other times.

And they've seen the edge cases. They've seen all the edge cases. So you have something you want to do with one of the directives, inaccessible or whatever, and thinking about how you prune things out of a schema or how things merge. The semantics of what happens when you try to merge two bits of schema. And there are these long discussions about what happens when one very specific thing happens and how we want it to behave in open source standards. So they're taking their time, they're doing it right. We're going to get something that's really high quality as a community as a result. And I'm grateful to everybody who's doing that work because it's real work. It's technically deep, it's to be celebrated.

Michael Watson: Federated interfaces is no joke. That's really complicated when it gets into how's that thing represented? Multiple, because we use interfaces for everything and just general coding practice with when we're building abstractions. And I'm really happy that there's a lot of very smart people. I'm not one of those people on that group smarter than me figuring those things out and getting to have a very good, rich conversation. I'm glad there's also representation from multiple enterprises, companies, you can see various companies attending those working groups to make sure their edge cases are included in that. So if you're thinking is mine in there, I'd love to have you get involved in that group.

Richard Moot: Yeah, now is the time.

Michael Watson: Now is the time.

Richard Moot: Awesome. And for somebody like myself who's not familiar at all is what the composite schema working group, is it working on a spec similar to that of say, open API is for REST of having a formalized pattern or thing to adopt when doing Federated Schemas?

Alex Hancock: The way I view it is like an open source industry standard version of what Apollo Federation already is, right? Apollo Federation is specific to a spec provided by Apollo, and this is just the open source equivalent that will carry on a lot of the concepts that exist in Apollo Federation and make it better, make it more general fix a few things that I'm sure y'all have probably wanted to fix in Federation for a long time, and now that there's a chance to do an open source standard, it's just the open industry standard version of something like Apollo Federation.

Michael Watson: A hundred percent. And I'd also say a reason we've kind of been a core leader in the composite schemas working group is because we have so many companies we've worked with where we want to make sure that composite schemas as we move forward with that, it's not like Apollo Federation doesn't work with that stuff. We're fully committed of aligning everything that federation is along with that spec. Now, what I think will for sure happen similar to what Alex was saying, is we're going to have a standardization that happens and then we're going to get a couple different flavors that have feature specific or things of nice to do this that's from maybe a vendor or another open source project. And that's the beauty of GraphQL is there's always been that It's not like every GraphQL server all works the same. There's definitely some little things in some GraphQL servers that they've added some nice things.

I know there's some things in Java's GraphQL server libraries that those directives I talked about at pre-prod and stripping things out. Some of that's actually already built into that GraphQL server that's not part of the spec now. It's a spec compliant GraphQL server. It's just adding some nice features, things on top of the spec. So I think that stuff will continue. Defer is a great example where we talked about progressively loading things in there, but how that router handles that execution, what's inside of there, there's going to be the basic description that's coming from the spec, but there's going to be kind of the different implementations. And that's great about it is that's how you make everything better. You bring the whole industry forward to that next level. So I love it.

Richard Moot: And I guess the final thing I'll ask on this to, and again, forgive me because I'm not super familiar, but I'm assuming that part of the main benefit is that as the spec is more well defined, more well shaped and then more well adopted, that it becomes easier to sort of add in. Say I want to federate another public graph into my own graph of like, Hey, I want to pull in GitHub repo data in a uniform way. It's suddenly going to work way easier because it's following the same exact patterns and specs that we're expecting. So it's not just on my internal stuff.

Alex Hancock: Exactly. It's about the ability to have many implementations of something like a router, and it's also about having many sub graph, many GraphQL servers out in the world that all adhere to the same spec for how they can be merged with each other. And so yeah, it's just getting everybody in the industry to align, and it really brings that concept up to the level where it's officially included as part of GraphQL, which is cool in a real boon for GraphQL as a technology, I think.

Richard Moot: So theoretically, somebody out there could eventually just build one graph to rule them all just be ultimate federated graph.

Michael Watson: Yeah, that's always the dream. The one graph, one of the things I also think about with, you just mentioned one graph, there's kind of like, I remember Apollo even talked a little about this stuff. You have one graph and then you have multiple representations, and that's kind of like an ideal state. But I think when you get into the practical implementation of companies, you got multiple graphs internally, and it's just like there's teams you've never talked to. They don't even know. I mean, some of these companies are just so large. I'm lucky at Apollo we're not that large, so I can go talk to a lot of these people, but I mean, I'm sure even at Block, you have offices all around the globe and developers everywhere. Those developers don't always necessarily get the chance to interact, and it's totally okay to have those multiple graphs. And the great thing about having that standard is the day you want to click them together, no problem. It's there. It's ready to go. You're prepared for whenever that day comes, so you don't feel like you have to jump to that, but it's always an option.

Richard Moot: That's awesome. Well, with that, I think we can go ahead and wrap things up for today. I want to give a big thanks to both Alex and Michael for joining us. I feel like I've learned so much already and I just want to go build stuff. I mean, obviously I'm going to go build stuff with a Square GraphQL API, but I want to stitch it together with others now. But again, thank you both for joining us Watson. What would be the best place for people to go and learn more about what Apollo is working on and what they're offering?

Michael Watson: Yeah, yeah. The best place, if you went to our website, of course, there's a lot of stuff there. I'm a big fan of our docs. I think we have great documentation around that Federation spec. If you wanted to learn anything around Federated GraphQL, that's a great place to start. The other thing I'd say is our tutorials. We actually have some really good tutorials that are all free, so if you even just wanted to learn how to start doing some GraphQL stuff, anything in federation that's there. And then also there's GraphQL.org. There's a GraphQL Discord that it's a great resource for you to go into where it's just a lot of the community members all talking together. Those are some of the official GraphQL channels that are inside of there. And of course, if you really want to get in the composite Schema working group, if you go to the GraphQL GitHub, you'll find kind of everything in there. That would be a great place to jump in.

Richard Moot: Fantastic. Well then I guess I will just plug that if you've got a project with Square, we'd love to hear about it. Reach out to us on our Discord, which you can also find over at developer.squareup.com. Or you could reach out to us on X at square dev, and be sure to check out our Square GraphQL API. Yeah, if you're going to be building from scratch, I think it's a great place to get started. And so feel free to test it out. Let us know what you think and keep building and we'll catch you next time.