The Square Developer Podcast

Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, and today I'm joined by Miles from DH Pace. Thank you so much for being here. Miles, can you give us a quick little intro and tell us about yourself and DH Pace?Miles Rush: Thank you, Richard. My name is Miles. I've been a software developer for over 20 years now and I've been working at DH Pace almost that entire time, developing lots of different projects and mostly focused in the mobile space. So for our field team doing field service and sales, DH PACE is a door company, so if it has a door, we work on it pretty much. So your garage doors, the doors to the front of your building, dock doors, if you walk through it, we touch it type stuff. And so we have a nationwide service and sales team and my job is to help them be more efficient and get their work done.Richard Moot: Awesome. And for those that aren't familiar with say the size of DH Pace, how large are we talking, and I'm assuming it's predominantly in the United States,Miles Rush: Correct.Richard Moot: But how many locations, what is the total reach of DH Pace?Miles Rush: I think, last time I saw, we were around 50 locations nationwide. We have probably 3,500 employees and about half of those are field employees.Richard Moot: And so you have worked on building the integration with Square for DH Pace. Before we talk about that actual integration, I'd love to paint a picture of what it looks like when somebody is interacting with DH Pace. You mentioned the field service technicians. What is the typical life cycle of somebody who's either buying a door or repairing a door? Tell me a little bit about that.Miles Rush: Absolutely. So one of probably our primary use case is residential service. You have a garage door and spring breaks or it just doesn't open or something like that. And so you call us up, Hey, I need this fixed. So our office staff will create the order, dispatch it to our field tech, and they come to your house and start using their mobile device to record what they're doing and see, oh, I need to, this is what's broken, here's the parts I need to fix it. They'll record those parts, record the time. And then as far as customer interaction goes, once they've completed the work, we'll have the customer sign off on what they did and then take payment right there in the field where they can use their credit card and take the payment and then we're out of your hair and moving along.Richard Moot: It sounds like you have a custom built system for actually handling this sort of interaction. I've had work done at my house before and mostly the other times somebody comes in, they do a quote, then they have to schedule somebody else to actually come out and then go and do all of the work. And then most of the time I get an invoice or I have to go write a check to them. But this kind of solves that, hey, we have a payment device right here. It's logging everything. We know exactly what was changed, what work was done. You can display this is how much you're being charged and then pay it right then and there.Miles Rush: Absolutely, yeah, so we have all of our pricing and everything sent down to the field on their phones and tablets that they use and they can invoice the customer right then and there and using the Square device makes it real easy for the customer to pay and for us to collect from them.Richard Moot: Tell me a little bit about the devices that you're using for doing this kind of payment integration or really for that interaction. You said that mobile devices, tablets, what do those actually look like?Miles Rush : Yeah, so our field team primarily uses Samsung devices. We're using Samsung phones and tablets for our field. Depending on whether they need a larger screen or not, we'll use a tablet. And as far as for Square, we're using the Square readers that connect via Bluetooth and they make it real easy to get those synced up and they'll just pull it out of their tool bag when they need to take a payment.Richard Moot: That makes it so easy. And previously you were integrated with a different payment provider, like you were using something before you actually started using Square. Tell me a little bit about what sort of things you were dealing with prior to that in terms of the technical issues and then some of the more logistical business issues.Miles Rush : Absolutely. Before this we were integrated with a provider that did not have any hardware. They only had a web API interface, and so we had to send all of our payment information through a web API to them. They would process the card and send it back. And while it worked, it wasn't ideal. It put us into the space where we were PCI had to take care of the PCI compliance because we were handling card information and then also was a poor customer experience. We were typing in their card number into our device and customers, a lot of our customers would get nervous seeing you type in their card into your phone, are you trying to steal my information or whatever.Richard Moot: I know you have a stranger coming to your place and you just like they're immediately typing in the card numbers. You're just like, what is going on here?Miles Rush: And so we wanted to get where it was, we could maintain our PCI compliance much more easily and have a better customer experience so they can just tap their card or swipe their card and we don't have to handle the card numbers.Richard Moot: Yeah, I mean it's one of those things where I've talked to many developers over the years and PSI compliance, I get this mixture of feedback from folks. Some people are like, oh, it's not that big of a deal. And for some people it might not be. But I think at certain scales when you have to reach certain different levels of PCI compliance depending on how much you're processing and the danger of the business, and it can be really onerous, running all of those audits and then having to run all these various checks so I can understand the desire to absolve yourself of we don't want to deal with PCI compliance, we just want to sell doors. That's what we want to be doing.Miles Rush: And don't forget the 50 page survey you have to fill out.Richard Moot: Oh my gosh, I know I've thankfully not been the person having to fill that out, but I have had to review it and it's lengthy and onerous. It might be 50 questions, but some of those questions might require quite a bit of research to go validate are we actually storing these things in this way? Do we know that these places where we're storing these things like who has access? Do we have audit logs? Countless things that you're trying to run through. And so you had tried out several vendors before switching from your previous integrator. Tell me a little bit about that exploration process.Miles Rush: So we wanted to get a solution where we're not responsible to PSI compliance. Our partner can take care of that for us. So we wanted to get out of that space. And then we wanted a better customer experience. So we needed some hardware where we could scan the card through tap, swipe, whatever it may be. We looked at lots of vendors that could handle that for us. And we settled on a couple that had the hardware. One of the ones we tried out was the SDKs and getting in there was just extremely cumbersome, couldn't get in. So we kind of put them aside. And then next one we tried, they had a device that worked for us. We had a proof of concept going, but it was very difficult to get it connected. There was either a) we had to have this device have its own cell phone plan in order to transmit payment information. So not only were we paying for the phone plan for the phone, we got to pay for another phone plan and that just doubles the cost of that.So if you wanted to avoid that, you had to was the connection process was difficult, had to go through a lot of steps and hoops and it was just very difficult. And the devices, we talk to them and say, this isn't easy, we need something easier. And they're like, well, that's a year away and that's two years away. We're almost there. We'll give you there soon. And the vendors we were talking to we're all saying that. And so one day I'm just kind of like, why is this so hard? And I'm walking around a baseball stadium and seeing the devices they're using. I'm like, why can't we use these devices that are just so easy to use? Why are we having so much trouble and places like this baseball team has no problem, they're up and running, have no issues. And that got me looking towards Square and places like that. I went ahead and just bought a square device, signed up for my own account and within a week I had a proof of concept going and it was exactly what we needed.Richard Moot: And so you originally built this, was it on reader SDK or mobile payments SDK? Correct. Okay. So it was on reader SDK. And I always love hearing that somebody just provision their own account, started building out their integrations. And I say that because too often I've sort of heard that the experience can sort of be like, oh, I have to go fill out this form, talk to these folks, build up my case sometimes provide, this is what volume my business is doing. So it's great to hear. And so you had that working, at least the proof of concept, I'm sure it's not a fully robust solution, but you had this working in under a week, right?Miles Rush: Correct.Richard Moot: You built this in Android. I'm going to take a guess here. Using Samsung tablets and phones, that'd probably be what you wanted it in.Miles Rush: Yeah, so the original proof of concept, I used Android Studio and Java to get up and running. That's how we got the original one going. And since when we moved to the mobile payment, SDK, which just came out not too long ago, we switched over to using, still using Android Studio, but now we're using Kotlin, tried to modernize our efforts there.Richard Moot: Yeah, I've heard, I mean I'm not familiar. I am not really a Java Kotlin developer, but from what I've understood from my peers is that Kotlin is a breath of fresh air and helps abstract a lot of the onerous parts of Java away to make it less painful to develop in.Miles Rush: Yes.Richard Moot: And so what is the main things that you have been building stuff with for DH Pace previously? It sounds like the Android studio and Java wasn't really what you're predominantly building with. I just love to know what is it that you've sort of done most of your mobile development and backend development with?Miles Rush: Yeah, so we purchased a rapid development platform that kind of drag and drop and you've got your workflows in there and they have a component that lets you integrate with native Android libraries and SDKs and stuff like that.And so we were able to take our rapid development platform and just link it up with the native Android stuff and we just pass the parameters we need, it passes back, payment was successful, and then we're good to go there. The development switching to the mobile payment SDK, it was really nice because Square added these quick start forms essentially. So you don't even have to develop your own forms. You just say, Hey, I'm taking a payment now and it already knows, pops up a standard form that lets you get going really fast. We didn't even have to create our own forms to do the payments.Richard Moot: That's awesome. I mean I recall, and this is just to sort of give a little bit more illustration to those that might not be familiar previously with reader SDK, it was like you had this connection process, authorization process and then it would kind of kick off a one continuous checkup flow where you'd sort of say, this is how much I want to charge for. It would kick it off and then it kind of like you'd just have to wait for that to complete and then you would sort of get back like, okay, transaction's done, we have this all process, but with mobile payments, SDK, it was kind of decomposed a little bit. So you had little flows for different components of what you were wanting to do through the process.Miles Rush: Yeah, and what I'm going to call 'em quick start forms, I'm not sure what you guys call them, they were great accelerators to getting us done. The branding on them is really limited so you don't have to worry about it saying all this stuff everywhere that detracts from our company and if we did need to customize it though and make a real custom checkout, all that stuff's there. But this just got us to market a lot faster being able to use these standard payment flows.Richard Moot: And so I don't know if this was something that was difficult to deal with previously, but I'm curious for your field service technicians, I'd imagine a common problem, and I don't want to say common, all of them deal with this, but common enough that you have to figure out a process for this of troubleshooting the devices when it's not connected, a payment won't go through. Tell me about how things have sort a evolved from the previous things that you've been using from reader SDK to mobile payments, SDK. How has that sort of changed over time?Miles Rush: We actually never went fully live with the reader SDK. It was always in the proof of concept stage and then we only went live with the mobile payment.Richard Moot: And then how has it been for the field service techs in terms of troubleshooting issues or dealing with connectivity?Miles Rush: Yeah, it's been pretty good for them. What we did is we just recorded a video like hey, here's how to set up a device and sent it out to them. And then when we showed it to them, there was this big apprehension when we first rolled this out, they're like, oh, what do we do? What do we do with this? What do we do with that? And we recorded a video, we sent it out, they saw the video and they go, oh, that's really easy. I don't even know why we were so concerned about this.And they just were able to connect the devices really easily, get up and running and when there's a problem it's usually just restart the device and you're good to go.Richard Moot: That's awesome. And so to give everyone an understanding maybe the scale, so you originally said about 3,500 ish company wide, almost half-ish being field service technicians. What is the scale of your device management and how is that, how do you make sense of all that? I imagine that's a lot of devices to be managing.Miles Rush: Because for our phones and our tablets and everything, we have a device management system we use to push out software updates. That's how we pushed out the square package is through our MDM software. And as far as the hardware itself, because these Square readers are at such a low price point, we're treating them just about any other tool that if it breaks, we'll buy you a new one. And so we ordered the initial batch from Square, pretty much just drop ship them out to all the locations and then they were able to pick 'em up, give 'em to a technician, they put 'em in their tool bag and away they go.Richard Moot: Couldn't be easier. So in terms of the simplifying of things, so in one of the proof of concepts it was having to use individual payment devices with their own cell plans. I'm assuming that the company issued phone and the company issued, the company issued phone is the same phone that they use for handling service calls, but it's also the same one that pairs with the reader for actually doing the payment stuff?Miles Rush: Yeah, absolutely. They're able to use the same device for their work, for their phone and then to pair to the reader. The only extra equipment we had to buy was the actual reader itself to scan the card.Richard Moot: So Reader SDK and then mobile payments SDK isn't the only thing that you're integrated with. You also have made use of our web payments SDK. Can you tell us a little bit about how you're using that?Miles Rush: Yeah, that's correct, so we have our field force that goes out there and interacts with the customer and taps swipes the card. We also will have people call over the phone and need to pay their invoice over the phone. A lot of our larger commercial customers will do that for payments on account and that sort of thing. And so we needed a way to handle that securely as well. We don't want our users typing in card numbers over the phone and storing that in plain text and any of that stuff. That's just not a good way to do that. So basically we just created a webpage using the web payment SDK. And so anytime they need to collect the payment over the phone, they go to the webpage, type in the card numbers, Square handles, all of that as far as taking the card number and the expiration and any of that information that's needed to process the card, you hit the process button, it goes to Square returns back approved or denied and away you go. And then we take that result back to our system to record the payment and it made it real easy to securely take payments without storing those card numbers.Richard Moot: When it comes to the payment processing volume, to what extent can you sort of touch on, I think it's also just so people can sort of understand what is the average invoice that might come through for a repair installation and nationwide, what kind of payment volume? These can be ballpark numbers to whatever extent you can give us an understanding of it.Miles Rush: I haven't looked at our volume stats in a while. I was surprised with how quickly it hit a million dollars when we went live, it was within a few weeks.Richard Moot: Wow, that's great.Miles Rush: And processing that all through Square.Richard Moot: Has there been any sort of noticeable difference in terms of improvements to either completion, deny authorization, anything like that? In terms of the transition from your previous one over to using Square?Miles Rush: We get a lot more approved cards upfront. So Square does a pre-validation step when you type in the card number. And so we know we have a valid card number before we even process it as far as we've got all the right digits and all the right pieces of information before we actually charge the card, which has been really nice. Before we had to actually send it off and they'd be like, well, that zip code isn't right or something like that, or you transposed a digit and well, we got to do the whole thing again where Square stops us before we even get that far when you're typing in the card numbers or things like that. And now that we're also doing the taps and swipes and stuff, those just go through seamlessly. We don't even have to worry about those anymore.Richard Moot: And wanting to also touch on something new that you have been exploring with Square is our terminal devices because you have this all-in-one payment solution with the receipt printer and we have an API for it. Tell us about your new integration with that and what you're hoping to achieve with it.Miles Rush: Yeah, so not only do we got our field service that is taking payments, we also have showrooms around the country where customers can come in off the street and purchase stuff and we wanted to make that experience better as well. So the person behind the counter is still typing your order information into our existing computer system to record what are you purchasing, but we just needed to give them a better way to pay. And so we didn't need a full point of sale system for that. We just needed a way for them to tap a card. So we're integrating with Windows computers at this point and it just made sense to use the terminal, Square Terminal product, so it was very easy to get set up. What we did is added integration to our computer system that sends the web call to Square.Square, then contacts the terminal, says, Hey, you need to collect a hundred dollars payment, and boom, it's right there in front of the customer and they can tap their card, swipe their card, and it automatically prints out a receipt right there as well. We are piloting that here very shortly with our first location and once we work out all the kinks, then we'll be rolling that out nationwide as well.Richard Moot: That's awesome. I mean that's one of the more common use cases that I've started to come across with Terminal API is, a companies like already say we have a web point of sale that kind of does inventory management, order management or it's like an ERP system or health medical record system and they're just like, but we need to connect to actual hardware for taking a payment and we want it to be connected directly to our main source of truth. And so we've found that that's actually a very common way to adopt a terminal for larger businesses. The other one I would say that we've commonly seen is self order kiosks. It's like you want to have this really nice tablet that displays everything and can walk somebody through a checkout and then just have a payment device that does receipt printing. I mean, I know that mobile payments SDK also works great for this, but if somebody needs a physical receipt, you now have to be like, okay, now we need to connect a receipt printer. And it gets, I don't know if you've ever dealt with printing drivers, but printing drivers can drive most of us a little bit batty.Miles Rush: Yeah, and the terminal made perfect sense integrated with Windows because the reader is primarily a mobile product, so iPhones and Android stuff where the terminal can connect to just about anything. And so it made perfect sense to use with Windows integration.Richard Moot: Yeah, no, definitely. I mean, that's what I've seen as well is that it makes it easy that anything that has a web connection, you can just make a call to your backend server, trigger a payment flow. And do you know if with your terminal integration, is it primarily just for payment capture or are you using any of the actions that we've introduced that allow certain sort of data capture or signature capture in that flow?Miles Rush: Yeah, we didn't have a big need for the action part. Primarily, we're just using it right now for payment capture and printing the receipt. I do see that as an area we might investigate further if the need were to arise, but for now we're just using the payment and the receipt printing.Richard Moot: Was there anything that surprised you or you wish could be a little bit better as you were working with our APIs and SDKs?Miles Rush: That's a great question.Richard Moot: I just go straight for a tougher one towards the end here.Miles Rush: Yeah. One thing that has surprised me in a good way is all of the APIs are you can explore every single API through the web webpage. Once you sign up for an account, you don't have to jump through any hoops to just see what this API does. You have the API Explorer and we actually, we'll use that for troubleshooting in production sometimes. Why does this data look kind of funny? Let me go to the API. I'll just run a quick command from there. I don't have to create a whole program or application. I can just run a quick call through the API explorer. That's been a great time saver for us.Richard Moot: That's great. I mean, I am obviously very biased, but I still use that to this day. I used to use Postman way back before we had API Explorer, and that worked most of the time, but for anyone who's used Postman, it's really great until you realize you're constantly going in there and modifying your queries and updating things. Did I save it and somebody sharing it? And API Explorer has sort of really simplified a lot of things for the development process. One thing that I've seen that still actually surprises me to this day is how many people come in to use API Explorer? They do the testing part, and then once they build the requests that they want, they'll switch the language to the language that they're actually building in and literally just copy paste some of that into their own code and then modify from there, which I hadn't been doing that, but I was just like, I didn't even really think about this. It does actually simplify, oh, this is all the data that I want. It already looks sort of generated it for me, and now I can just copy paste it somewhere else. I mean, as a developer who doesn't love copy pasting someone else's code.Miles Rush: The only thing I would love to see, I'm going to throw out one thing here is more places we can integrate with as far as more languages and things like that. For the mobile side, it was if you're using iOS, you go to Swift and you do the development there. If you're using Android, you pulled up Android Studio. I'd love to see that ecosystem expand it out even further. All these new tools out there with Fluent, and I think you guys have React, I think that just came out recently, so that's great.Richard Moot: Yeah, we just have the React native plugin come out.Miles Rush: Maui and different things, more native integration to all these different platforms, I think would be a great boon to expand your reach.Richard Moot: Yeah, I know that two, I've heard Maui from you, but I've also, the one I've heard previously, even for reader SDK when we first published, that was Zamarin. It is used quite commonly. I think that when trying to sort of triage at the time, what are the most popular multi-platform frameworks? It was React native was kind of dominating everything. Flutter was very new on the scene, and we partnered with Google in that initial Flutter 1.0 launch, but I can definitely share this feedback with the team and say that we have more requests for Maui and Zamarin. I do hope to have the flutter plugin for mobile payments SDK coming soon, and in fact, by the time that this actually publishes to air, who knows, maybe it's already out there and you can already build and test with it. I'm definitely excited to go just try out the React native plugin and start trying to get a few examples working.Miles Rush: I did remember one more area we're going to be expanding into using the APIs, and that is the checkout links, so that's something we're looking at integrating into when we email invoices to customers, if we're not doing it on site and we want to email it, we're going to put a link in the email and on the invoices they can just click and go straight to Square and pay from their browser and the customer handles all that interaction.Richard Moot: Oh, that'd be great.Miles Rush: Yeah. That's another area we're expanding into in the near future.Richard Moot: As a consumer who's worked with many different proprietors, I can't say how much I enjoy when you have that ability. In fact, I have, I'm not going to name them, but I work with a pest control company that comes and does a monthly service, and the weirdest part about it is that they send me an email with an invoice saying, this is what I owe, and they give me a link to go pay them, but it's not linked to the invoice, so I'm just hitting pay going and filling out a form and just assuming that because they see it's my name and address that it's like, oh, we know that this is for this invoice, but every single time I have thought, why on earth can’t I just save my info with you? Why can't I just actually have this paying this specific invoice?So I've actually found that the checkout links product, it's near and dear to my heart because it simplifies so much about the payment process. I've previously sort of been in the e-commerce space and having built out enough example payment flows at this point, you could probably build this integration using web payments SDK, but it suddenly creates all of these other things of where are you're going to host this, how are you going to link it? You have to create user sessions and all of these various components and a checkout link simplifies all of that where it's just like. Here's a fully built out streamlined checkout flow that's going to give you an itemized list. Put in customer data. In many instances, if Square recognizes you like, Hey, we've seen this email before. We've seen this phone number before. We can actually say, store that for them and then just pre-fill it. So definitely excited to see you roll this out and what your customers think about it.Miles Rush: It'll be a big benefit for us.Richard Moot: Excellent. Well, it looks like we are coming up on our time here. Miles, I want to thank you so much for coming in and telling us a little bit about DH Pace and what you've built and what you've integrated with it. For anyone out there who's listening and you need some doors or some repaired installed garage doors that you walk in and out of, make sure to go check out DH Pace.Miles Rush: Yeah, thank you, Richard.Richard Moot: That's it for today. Big thanks to Miles from DH Pace. If you've got a project with Square, we'd love to hear about it. Reach out on Discord or X at Square Dev. Don't forget to subscribe and check out Developer.Squareup.com for more. Keep building and catch you next time.

Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of developer relations here at Square, and today I'm joined by Adam and Cesar from MonStar Lab. Can you both give us a quick intro and tell us a little bit about yourselves and MonStar Lab?Adam Mack: Thanks so much for having us, Richard. Really appreciate it. My name's Adam Mack and I am the director of Technical Product Management here at MonStar Lab in North America.Cesar Aguilar: My name is Cesar Aguilar and I'm an engineer director here at Monster Lab based on New York.Adam Mack: MonStar Lab is a New York and Tokyo based technology partner, and we have a staff of over 800 engineers, designers, and product managers all around the globe helping our clients in all manner or different industries to solve complex technology and business challenges. And what we end up doing at the end of the day is building human-centered software that delivers results for our clients. That covers a huge range of activities. We build consumer apps and consumer app experiences. We help design process automation and new operational workflows for different businesses. We help educate brands and internal teams about responsible use of ai and we help technology teams select the right vendors and partners to work with. At the end of the day, all of it comes down to overcoming complex technical challenges, but without ever forgetting that there's a human end user at the other end of the experience. So we try to ensure that we're balancing technology choices and making cool stuff with always doing what's best for our users. And part of that is a huge focus on payments and payment integrations. We recognize payments as one of the foundational drivers of a good customer experience in a lot of cases, and it's obviously a core driver for platform businesses all around the world. So it's a little snapshot of what Monster Lab does.Richard Moot: You've been building and integrating stuff on Square for quite a while. I'd love for you both to just talk a little bit about one of the first big integrations that you've built with Square.Adam Mack: Yeah, so we have a long history with Square, going back to very, I guess you would call them simple payment integrations. Many, many years ago, going back to the beginning of Square's, APIs and SDKs, we had a long working relationship with Shake Shack and we helped to build out the majority of their online ordering infrastructure, including their consumer ordering apps for iOS and Android web ordering. And in 2017 they approached us with this interesting challenge of let's take the really great experience that we've been offering in our consumer mobile apps that really polished ordering brand first experience, and let's bring that to a new form factor with kiosks. And the destination was going to be a sort of, I guess you could call it an experimental digital first location, starting to experiment with different form factors for the brand. So we were charged with helping to bridge this user experience that we built for iOS and Android into a new form factor and a huge part of that, a huge challenge aspect of that was integrating Cart present payment, which was a new challenge for the brand. So we looked at so many different providers to handle our card, present payments for the Shake Shack kiosk and Square ended up being the partner that we worked with and Square helped us and helped our engineering team to really rapidly prototype design and prototype a solution that met all of the user needs, met all of the security needs, met all of the operational and business needs that Shake Shack was putting in front of us and doing it incredibly quickly.Richard Moot: So one of the things I've always been curious about when trying to build for these in-person type experiences compared to say, online, mobile, web, what were some of the more interesting things that people might not think about when building that in-person type experience? Because I remember that app does a really great job of walking you through a checkout flow but also displaying certain things where it feels very different than if you're just sitting in front of a person and just saying, oh, I'm just going to start reading off of this menu. You have a little bit more of a guided experience on this. So I'm just curious, what are the things that you'd say were the most interesting problems to solve or things that you wouldn't really consider compared to doing an e-commerce type build?Adam Mack: Sure. So what's really interesting about kiosks is in a lot of cases they are designed to alleviate the burden on operational labor or increased throughput in a lot of cases. For Shake Shack, that was absolutely an operational goal. I think everyone who has spent any time in New York and knows the brand, knows the long curling line around Madison Park for the OG location, so that was line busting is not quite the right term, but expediting the customer flow through the experience was a huge part of what we were focusing on. What's interesting is customer behavior really changes when they're not interacting with a human. When you're interacting with a machine, suddenly the dynamic changes in ways that were completely surprising to us and in ways that we really couldn't have anticipated until we did extensive hands-on user testing and put the application in front of people.And then there's a second layer to it where you don't even excavate some of these findings and user testing. You only really get them when it's a real customer walking up to this thing for the very first time going, oh, that's interesting, I hadn't seen that before, and start tapping on it with zero context or a grounding in what this experience is or should be. And watching those people and how they interact with the machine was truly fascinating. So you end up seeing this diversity of human behavior and the way that people approach the machine, especially in a really busy urban area like Middle Aster place in New York, you're seeing all sorts of people all walks of life interacting with this, and that's a sort of real life testing bed that you can get close to in lab-based user testing, but until you actually get in the field, there's no real comparison. So the wealth of interesting user data that we got from those first couple of days was just so valuable because it's something we never could have gotten outside of a real production environment.Cesar Aguilar: To add there a little bit with the screen reel space there, you could also change the ad behavior for the brand because instead of saying here's the special, you can use those screens, screensaver mode and stuff like that. So we changed kind that and also the recommendation kind of stuff that was given to users to be like, oh, don't miss this special concrete, especially in the case of Shake Shack or they're chasing concretes all the time and they're delicious.Adam Mack: That was something that was actually really exciting and interesting for us as a product and a UX focused team in the beginning days was the realization that at first we kind of had this mindset of we have an ordering app, it works great, let's just bring it into a new form factor. Oh wait, this form factor is what eight times the size of the one we were working with before: And it operates in a completely different context being a stationary part of the store. So it's not just an ordering app, it's a digital menu board, it's an advertising signpost, it's a customer service output, it's a place where you can deliver targeted messaging. In particular, we've seen that this is really powerful in situations where the kiosks tie into a central loyalty program, which can be a really challenging endeavor to take on. But in those cases where it recognizes me because I just dipped my credit card because it knows that I use that credit card two weeks ago in the ordering app, that's really powerful and suddenly you can start to do this one-to-one messaging that I think has long been the sort of desired outcome of know thy customer, why know thy customer so I can deliver one-to-one targeted ads. It sounds crass, but it works. And at the end of the day, that messaging and that personalization really works.Richard Moot: Is there anything that stands out to you that you can remember that really challenged an underlying assumption that you had going in and then the customer behavior really seemed to be going in a different direction? So one thing that I recall, and I have to forgive everyone listening that I don't remember where I heard this from, but how kiosk can actually cause different types of ordering behavior for customers. Because sometimes in an in-person interaction when certain types of people are being upsold, say like, Hey, do you want to supersize it or do you want to go for the large or something? There's this self-conscious like, oh no, I really shouldn't. But in a self kiosk scenario, no one's there to make you feel judged in your order. So it's easier to feel okay with like, yeah, I'm going to go with the double instead of the single. So I'm just curious if there's anything that you sort of recall that challenged an assumption going in.Adam Mack: So this is not Shake Shack specifically, but we do work with a huge variety of QSR quick service restaurant brands, and this is kind of a universal behavior. What you described is exactly right. People have way less compunction about ordering extra cheese or another patty when they're dealing with a cold heartless machine and not a living breathing person on the other side of the register.Richard Moot: Guilty.Adam Mack: Same.Cesar Aguilar: Just to put numbers into it just to reference, we saw on average, I think it was like 20% higher volume in terms of the costs. So users were always ordering about 20% more compared to ordering from the mobile app or from in person.Adam Mack: Even when you try to isolate confounding variables like, oh, is this person ordering for a family still? You see a market increase in the kiosk form factor compared to others, and that's something that Shake Shack has taken total ownership of this product at this point in time, but they still tout that as one of the key drivers behind the kiosk strategy, right. It just delivers a much better average order volume than all the other ordering channels.The reasons why is still somewhat nebulous. What you mentioned is definitely one of them, but it can't be the only thing. There are definitely other human behavior factors at play that we haven't fully, fully uncovered.Richard Moot: Yeah, it's fascinating.Adam Mack: Another thing that we found really interesting about human behavior at the kiosk that was unexpected was we expected people to need a lot more help. And we first preemptively built a lot of support structure in the anticipation that people would come up to this thing for the first time and be overwhelmed by it or not know what to do or not understand what options they had. And we found it was really kind of the opposite. People intuitively got it, and I think that has a lot to do with our good user design and focus on human-centric design, but we found that people were really willing to stick with it and learn it, and people who had trouble would sit there and they would play with it until they got it and they got it. So we had this whole apparatus for support that ended up just not being necessary. That was really interesting. I'm curiousRichard Moot: I'm curious, in doing the user design experience, how much were you trying to emulate the actual behavior of standing in front of a cashier or what was the centering point for you for emulating a certain type of flow? Was it more like an e-commerce, like I'm going to go through self-select things or were there a certain extent where you're trying to emulate that actual process or flow of ordering from a real person?Adam Mack: So this is another thing that we've spent, Cesar and I have worked together for over a decade at this point, and many of those years were spent building these kinds of ordering interfaces, restaurant brands, and that's a continual give and take struggle in the design process. And it's really such a brand specific thing, how any individual given brand wants to, I guess make the kiosk an extension of their brand and of the human representatives of their brand.So we see a wide spectrum. Some brands are ruthlessly focused on conversion rate and that means the fewest screens possible, even sometimes constraining or restricting a choice like choices that you would be able to express and vocalize at the register are now tightly constrained in a UX environment that has operational considerations, but it also I think has a lot to do with human psychology of choice and the less options you put in front of someone, the faster they might be able to make a decision. On the other hand, that's your place where you offer upsells, right? That's where premium toppings come into play. So it's a constant struggle between these different factors to find the right balance between speed, upsell opportunity messaging the brand voice in a very powerful and directed way, not wasting people's time. All of these things are kind of intention with one another and finding that balance is a huge part of what we try to identify through our user testing and it's very unique by brand and by customer segment.Richard Moot: It's very interesting. I keep coming back to you as you're talking about it, is just how in the kiosk scenario the data becomes so valuable because say that you have a stipulation of like, oh, everyone should be trying to upsell to go from a medium to a large or adding on this little add-on at the end, but you can't necessarily guarantee that the person at the register actually offers this.Adam Mack: Absolutely.Richard Moot: But in the kiosk, we presented it, we had the display screen, we can see how long it took them to dismiss this. Did they dismiss this? When did we upsell it? What time of day are we more successful in upselling this compared to others? I mean, it's kind of crazy how much more information you can really get through that.Adam Mack: We even got into places like building collaborative filters around which items go together most often and using that data to identify like, ah, you're missing something that you'll probably likely buy based on previous customers like you. That's really interesting because I think for most people, an experience of going up to a customer and the person at the counter going, ah, Adam Mack, you were here two weeks ago and you bought a triple cheeseburger. You want a triple cheeseburger. That would be a very unpleasant, borderline unnerving experience.Richard Moot: Super creepy.Adam Mack: Somehow fine when it's the app doing the exact same heuristic determination of what I'm going to order. And so there's also an opportunity there where because it's anonymized a little bit and it's not another human identifying,People are more comfortable with that for reasons I'm not a hundred percent sure about, but it is a very, very, very powerful untapped thing. I think it's just starting to become a reality as people, as brands start to embrace the notion of as brands start to more tightly embrace this idea of universal commerce or omnichannel commerce, this reality is starting to come into play where somebody comes into my restaurant a hundred times, they use cash every time. I never have any idea who they are. They might be my most loyal customer, one of my most high spend customers. They download the app for the first time, I have no idea they're my best customer, I should treat them as such. Kiosk suddenly allows you to start to bridge that gap a little bit. So now they come in, they use the kiosk, they use the same fingerprinted card that they used in my app.I know who they are, I can offer them loyalty points, I can give them the experience that they would come to expect being a regular in a restaurant. And again, that's something that I think businesses are only starting to understand. The power of some of the largest brands in the world are doing this flawlessly right now, and now it's starting to become more and more accessible to smaller brands as data tools and consolidation of data becomes more within reach and analyzing the data once you have it. That's another huge point that requires some examination, I think.Cesar Aguilar: Especially when you have multiple vendors in place sometimes because each one has their own little data schemes. And so how do we merge all that together? That's always a challenge.Adam Mack: Our experience with brands is almost always that they're on this continuum of digital growth and we hit them wherever they might be on that journey, and that often means that they have, as they expand their business, as they add new capabilities to their brand, they're bringing in new vendors. It's almost always being driven by vendor partnerships. A huge part of what we do is trying to help our clients to navigate those complexities and to unify data streams into one place so that their payment provider and their CRM are working in unison to actually drive results and not just operating in silos.Richard Moot: And I'm sure that you get the full spectrum of things I've learned in my time just even here at Square that you have some vendors who they're just like, we just want you to dump a file on an FTP server every day, and then we're going to go and process that asynchronously versus others that are just like, Nope, we actually just want it to be automatically streamed into our data lake and we're going to run all of this snowflake looker type queries and that's just going to be our full ETL process.Adam Mack: You want to dump this syn excel, like, okay, sure. Yeah, exactly. If it works, it works. What I to say, it is my place to say, as a product person,Richard Moot : Yeah, how much do you want me to code around this and how often do you want it to be breaking?Adam Mack: I mean, one of the incredible realities of the digital world we live in is how much operationally critical infrastructure runs on, I would call it just in time delivery of data into systems that may or may not be the best destination for that data. But at the end of the day, a huge part of what the reality of what we do is working within those constraints, right? Because at the end of the day, you can't make a choice that's going to introduce downtime or discontinue operational continuity. So as much as those things can be head scratchers, sometimes it's just a cold hard reality of the modern business world.Richard Moot: Yeah, I mean, I've heard a joke, it kind of hurts because it feels a little bit too true, but most people would be shocked by the amount of processes or parts of companies that are actually just run by a Excel spreadsheet that was built by a new MBA grad who's in their early twenties. There's tons of parts of businesses. It's like it's just running off of this Excel spreadsheet someone built. IfAdam Mack: If that workstation with Excel 97 ever goes down, we're doomed. That's it. It's over.Richard Moot: So one other thing I wanted to just sort of touch on, is there anything from a technical side of in-person experiences that was, I don't know if it's different or something that you have to be more scrutinous of? And I can give a small example of this, when we built and released Terminal API, one of the things that is, and still to this day is the biggest thing is latency. You're making an API request and then you're kicking off a workflow on a terminal device to walk somebody through a checkout. And we've definitely learned that the tolerance for latency in an in-person experience is so much shorter than what somebody would expect on an e-commerce site. If I add something into the cart and it takes me a half second to load, I'm weirdly more tolerant of that than when I'm tapping my card on the reader or sticking my cart into the machine and it's taking eight seconds or 10 seconds. You're like, oh my God, why is this taking so long? So I'm just wondering, what are some things that from a technical side, were the most important things to be solving or dealing with, and how did you go about it?Adam Mack: I mean, you said it, latency is death, right? Latency is the death of conversion rate and every consumer satisfaction metric you can imagine. So we've even had conversations in some contexts about does it make sense for this particular kiosk installation to rely more heavily on local network and not talk to the the internet as little as possible, specifically to avoid those latency situations. We've looked at situations where does it make sense to batch capture payments and do everything offline and just hope that for the best when you actually go online? And those are very extreme examples like deploying a fleet of kiosks to a music festival or that kind of thing where network reliability is extremely suspect at best. So those challenges are very real. At the end of the day, there is sort of a real world constraint that you're only as good as the weakest link in your chain as well, especially when you're dealing with these multi-vendor setups. So that's another key thing that we spend lot of consideration on is how can we optimize every single connection we make to an external partner, especially when it's over the internet to make sure that our latency is low. At the end of the day, is conversion rate.Accessibility was also something that was really interesting to us, and obviously accessibility is important for anyone who's a digital practitioner and building software, but the real world has a way of introducing interesting constraints that you don't think about or have to think about when somebody is bringing their own device. Just to riff on accessibility for a moment, since this is a topic that's really important to me,And I think something that is woefully underappreciated in a lot of cases is in a mobile app situation or a website situation, you as a designer developer have a lot of obligation to make your product accessible and meet the user where they are. Where the user is, is coming to the table with potentially a host of accessibility devices to aid their experience, and it's our obligation to make sure that those devices are respected and our content is accessible to those things, but they kind of meet us halfway, right? In a physical installation, it's a hundred percent on you as the designer or the developer or the operator to make sure that that experience is a hundred percent compliant with anyone who comes up and uses it. And that involves things like physical accessibility from accessibility devices like a wheelchair or a walker. That includes things like clearance on either side of the kiosk, physical constraints. It includes things like having braille labels on everything so that if somebody absolutely cannot use the audio visual based interface that somebody can come help them. So huge suite of considerations that come into play in a physical installation space that are extremely challenging, and again, sometimes interestingly at odds with what would normally be considered best practices for the sake of conversion or a good user experience.Richard Moot: Yeah, no, I mean it's definitely one of those things that I think that unfortunately does not get as much attention upfront from most folks. I remember not that long ago, there's a slew of websites that were getting in a ton of heat for not being accessible to screen readers. And I mean, that's just something where you just need to be putting the appropriate attributes, and we have, at least at this point, I would say a well structured guide on how you should actually be going about making those things more accessible.Adam Mack: Just a note on that, one of the things that delighted us about the Square Reader SDK was that it worked right out of the box with our voiceover implementation. So we put a ton of work into making sure that the entire kiosk interface was fully navigable by voiceover, that if somebody wanted to put the kiosk into accessibility mode with a pair of headphones, they could navigate everything purely through audio queues, including the Sandboxed Square SDK, and the entire set of UIs that come with it. So that was just huge shortcut out of the box to have our entire flow be fully accessible, optimized from the start.Richard Moot : Changing gears a little bit, I mean, still within the kiosk space you have built a kiosk integration. I think it's a little bit more unorthodox, I guess we would say in its usage of Square Services. Do you want to give us a little bit about what that type of kiosk setup was and tell us why it was a little bit of an oddball.Adam Mack: So several years ago, we were approached by a very forward-thinking retailer who has made to order sandwich counters, and they wanted to explore the possibility of having a kiosk interface for what was ultimately a very interactive kind of sandwich building experience. At the same time, they had a lot of operational challenges related to order accuracy, order timing, and we kind of felt like, oh, these sort of go hand in hand. There's sort of parallel problems. There's the input side of user choice and user configuration and the operational side of how that data actually shows up on the line in the kitchen. So we were tasked with building a prototype as quickly as humanly possible to test the viability of this concept, and we ultimately ended up going with Square in a sort of unorthodox configuration specifically for speed to market and flexibility in development.Cesar Aguilar: So with that one, we looked at the Square catalogs and orders aspect of it. It was, let us get it all up and running. Normally when we work with the QSR space, a lot of our customers are coming in with already preexisting systems. They might be using other menu content management system kind of things already, or kitchen systems that are already integrated. In this scenario, they had none of that. They just, and so we needed to do something to kind of let the admins be able to build all this, here are the products we sell, here are the options you can do. And we were looking at different ways of doing that, and Square’s catalog and order aspects just kind of fit in nicely. As you said, this one was now a traditional one in that because kiosk itself didn't need to accept payments at the time, so we didn't actually leverage that aspect of Square in this product, in this integration.Adam Mack: That was what actually made it so appealing to us in the first place was this flexibility that, oh, we can take the modularity, take the pieces that we need, build something really, really quickly that works. And from an operational side Square took care of all of those aspects for us in terms of catalog and order insertion, and then we can kind of pair that up with a content management system that lets us kind of express that rich media that we really needed for the fully custom ordering experience and the customization experience that we wanted to build in the consumer app.Richard Moot: So to help give us a little bit of visual color to what the setup might've been like is that there's these sandwich made to order shops and there's a kiosk that's set up in each one, and that is actually connected to Square through the orders API catalog, API to actually sort of allow somebody to construct an order, and then that gets sent off to where I'm trying to sort of understand how is this all working?Adam Mack: Yeah. So what we're building is, and this is a typical pattern for us where we will build a backend infrastructure that sort of acts as the orchestrator between our different vendor partners for whatever capability we're trying to achieve. So in this case, it was leveraging the Square catalog for pricing and for instance, knowing this sandwich is available at this location, that sandwich is available at that location. This special is at only these three locations, that kind of inventory and catalog tracking and then orders went into Square. So we were just bypassing our payment step, inserting orders as prepaid into Square, and that gave us basically the ability to leverage the order API to pull that data out and have a real time feed into our kitchen display system of exactly what's being ordered when. How long did that order take? Did they hesitate? All sorts of interesting metrics like that that we could gather. So a combination of using Square basically to facilitate our catalog and facilitate our order injection into our downstream systems, and then a whole lot of custom integration work to enrich that data, pull in rich media from our content management system and tie all of that together into an API Flow that could be consumed by the actual kiosk app itself sitting in the store.Richard Moot: I wanted to make sure that we talk about the work that you did on Chase Center. It's a really large sporting venue home of the Golden State Warriors. Would love to just talk about what you built and did with Square Hardware out there.Adam Mack: You might notice a theme to some of these that were typically operating under extremely tight deadlines and budgets. So this was another case where we were sort of brought in to execute on an extremely tight deadline to get ready for the opening game of the Warrior season.Cesar Aguilar: So for this one, we were brought in by another agency and Square at the time to, they were focusing on the mobile applications and hadn't had any time to spend on the kiosk at the time, which they supposedly knew they wanted to build. And with our experience with Shake Shack and other things, we had at this point spun up our own kind of internal white label platform, and so we leveraged that to get the kiosk off the ground and integrated. And from there we could focus more on the unique challenges of Chase Center because one of the aspects of Chase Center that also we helped bring along was for any Chase customers, any Chase card holders, whenever you made a purchase with your Chase card, you would get, I believe it was like a 3 or 5% cashback on any purchase you made at the Chase Center. And so we leveraged the Square’s webhooks APIs to just monitor all orders coming in and just see, okay, which of these are Chase bin numbers? And whenever we found a Chase bin number, we could issue a refund through the Chase, through the Square APIs.Adam Mack: So I think that's really illustrative of why we reach for Square a really modular set of components that sort of any use case that comes up in the context of understanding the flow of payments and the flow of money in a system. We have the tools to have insight into what's happening in real time. We have the test environments to be able to rapidly prototype those scenarios. So the developer experience overall is just a huge part of why we went to Square for the very quick turnaround that we needed for this project.Cesar Aguilar: We could use all these modular pieces. The refund aspect of this was actually kind of its own application workflow, and so our white label product had no knowledge of it. The other agency working on the mobile applications, they just had no knowledge of it. They integrated with Square directly. The kiosk integrated with Square directly for payments, process it, and then the refunds just kind of happen in the background on their own, and it's just all kind of connected and worked kind of like magic.Adam Mack: Irrespective of what channel that came through. We could recognize it and take action on it, which was kind of cool.Richard Moot: That's awesome. And given that you were on a shorter timeline, I imagine that one thing that might've been helpful is you're having to get X amount of devices as you're trying to scale up, swap things out, this is working, this isn't working. I mean, how much did that help in terms of meeting deadlines?Adam Mack: Yeah, that's a huge part of it actually. I'm not going to name names, but something we've experienced with some legacy payment partners is you need a device right now and they don't care. You're going to get it in 12 weeks. It's going to be provision in 12 weeks and you'll get it then maybe if you're lucky, being able to just buy hardware right off the shelf. In the case of the Square reader, all of our kiosks when we have the choice are based on iPad Pros as the form factor. We typically have a custom housing and chassis, but those two pieces of consumer hardware, the iPad Pro and the Square Reader device are rock solid, reliable, and you can pick them up at so many different retail stores that the whole notion that, oh, kiosk went down, what happened to it got spilled on, we can have a new one up and running in 15 minutes. So having a stock of devices on hand was super, super helpful for, and also standing up, we weren't really sure how the demand spike would go, so we weren't sure how many kiosks we would need. So the ability, oh, we can scale up 20 more kiosks, just roll out a modular shelf with all the hardware equipped was a lifesaver when it came time to meeting those spikes of demand.Cesar Aguilar: And I'll add another piece there on just off the shelf hardware, but it's off the shelf hardware that you can walk into an Apple store and just be like, okay, I need to purchase X iPads with my business account, and all those iPads will automatically be managed. Every iPad we put into the kiosk in any of these locations, they're all managed through MDM software. So the minute it boots up, it loads up the app, it goes into single app mode, boots up, screensavers, whatever configuration the brands set up for how they want their kiosk experience to be. It just, you turn it on and you're running,Adam Mack: It's good to go. Yep, our app boots up and then you're in the experience.Richard Moot: Yeah, I feel like that's one of those things that I traditionally come from web software development, and that's one of those things I just wouldn't really think about is I think about web deployment, but this is hardware deployment and the fact that you can have it in such a consistent method and hey, this is already a well understood device, has really good user experience, and it's not super complicated to explain to somebody at a location like, Hey, here's how you can actually get, just grab this thing out of the box, go through these few simple steps, and then you're up and running with another device that's already connected to the system.Adam Mack: That's a huge part of it. Your troubleshooting staff has now become every floor manager at every location across the country or the world that you're deploying to. So having that ease of operability and being able to stand something back up when it falls down is critical, especially during a lunch rush or dinner rush period. Yeah.Richard Moot: So to wrap things up, I always like to make sure that we touch on the geek year components of this. I'm curious of when building things. I mean, I'm sure that a lot of it is driven by whatever the customer's infrastructure and other things, but what are your go-to technologies when you're building stuff like this out in terms of backend? I'm guessing that on front end it's usually native, but I'm just curious, react native flutter in some instances, or do you just purely build things out in a native way and then again, on the backend, what are your go-tosCesar Aguilar: For the kiosks? We've always done native for the most part, especially since it's all, as we said, usually iPad focus and it lets us do the best experience. We have done a couple of kiosk types installations on Android devices, and for those, because of the different kind of limitations and variations, we found that more of a web focus approach was kind of better than going full Android native. But in terms of just the actual kind qualifications, it kind of depends on brand, what their teams internally look like, potentially what their stomach for maintenance is. Do we want to kick both platforms? Because sometimes it makes more sense to focus on iOS and get Android more through just the web experience. Sometimes it makes sense to get both native, sometimes it makes sense to do cross-platform, just a matter of looking at the brands kind of where they're at.Adam Mack: It's another one of those huge tensions. Absolutely. In an ideal world, we have fully native, bespoke written to the metal for each platform, but there's a huge ownership cost that comes with that and a huge maintenance cost that comes with that. So sometimes it's the best customer experience, but not the best operational experience. So it's another one of those tensions that we constantly need to evaluate.Richard Moot: Yeah, I would imagine in that split between iOS and Android, I mean, it's been known for a while, but I imagine this becomes more pertinent when it's like your business is relying on this of, there's fragmentation on devices and versioning. This is a little bit more prevalent on the Android side than it's on the iOS side, because I always said, you have fixed device profiles. There's only these types that are going to be on these versions versus Android, like a design might not quite fit this resolution on this particular device.Adam Mack: And you might have an Android device that's 55 inches diagonal that suddenly needs to scale your design. We can't necessarily know that ahead of time.Richard Moot: And so for backend implementations, what is you go-to setups for that?Adam Mack: Well, I mean, node Node continues to take over the world, so it tends to be a huge focus for us. ButCesar Aguilar: No, I mean node for the front end stuff. I mean, we do use Node for other stuff, but we found with the smaller kind of clients, we find that we can leverage the agility of Node or Python sometimes, but with the larger or more our larger customers, we find that oftentimes we need to focus on something like Spring or dot net at more established enterprise platforms.Adam Mack: Quote un-quote enterprise choices.Richard Moot: Yeah. Got to get the J two EE in there.Cesar Aguilar: Yeah, those are the platforms they can support long-term, most likely.Adam Mack: At the end of the day, it ultimately, so much of it comes down to the needs of our client and their internal teams.Richard Moot: I was just also wondering, and certain things when you're doing event venues where you might have really, really spikey traffic is there's stuff that has to sort of augment in terms of, oh yeah, we go with a serverless implementation. We can more readily scale up when we have large events and then scale back down to control costs when nothing's actually happening at the venue.Adam Mack: No, that's exactly, that's exactly it. Yep.Cesar Aguilar: Exactly. The type of service also dictates how we deploy that stuff. Yeah, as you said, for something like a venue, that serverless makes a hundred percent sense. In the case of Shake Shack, we did more of a Kubernetes deployment, which auto scaled up during lunch rush, anticipated lunch rush, and already was scaling up services. So by the time Lunch Rush came in, it was ready and stuff like that,Adam Mack: And in a rolling wave across the country, yeah.Richard Moot: Yeah, I was just thinking that it's probably like you see that lunch rush going from East Coast to West Coast.Adam Mack: And then a second smaller one at dinner. Yeah.Richard Moot: Yeah, no, that makes a lot of sense. And I guess my final thing I would ask on the node front, I'm a JavaScript programmer, so I just have to ask, what is your favorite framework? Or do you just do everything in just regular node?Cesar Aguilar: For the front ends? Kind an API where we're kind of mixed stuff, we'll usually leverage Next and react with TypeScript as kind of our main kind of thing. But when we're doing kind of more just fully backend only project in Node, for example, usually when we're doing that, it's we're doing a serverless type deployment. Sometimes we'll leverage, forgetting the name of the, there's another framework we'll use, but it's a little more rare that we'll use that. We usually, if we're going this route, we're using serverless most likely with Node.Richard Moot: My go-to that always feels like an odd ball is I always feel like I have to be very clear on it. It's Nest js, not next Js Nest.Cesar Aguilar: Oh, yeah.Richard Moot: Mainly because I would always say it requires this really initially steep learning curve, but if you ever did Angular back in the day, it follows those patterns very, very well. I think it's also very similar to C# in some regards.Adam Mack: Angular hasn't gone away. There's still plenty of custom client code base. It's still an Angular yet.Richard Moot: I'm talking about og, OG Angular with two-way data binding and weird digest cycles that make you scratch your head as to why this rendering bugsAdam Mack: The dawn of history.Richard Moot: Yeah, I feel like I'm really dating myself in terms of programming.Adam Mack: No, no, no. You're dating yourself if you've ever called yourself a webmaster as a professional title at any point in your career.Richard Moot: Oh, yes. Yes,Adam Mack: Definitely. Or web designer. Yeah.Richard Moot: Well, with that, I think that's it for today. Thank you both so much for joining us, Adam and Cesar, is there anything that you guys want to plug in terms of if they wanted to learn more about Monstar, check out the work that you've been doing, where should people be taking a look at that?Cesar Aguilar : With are Mostar with a hyphen lab.com and you can go see our work there across the globe, it's split up by the different sections of the globe in terms of company and a lot of the QSR, and that's not to say that there's Square experience across the board, but in terms of the QSR space, Monstar Lab Americas is kind of where we've done the most of it.Adam Mack: Check out our website for a pretty comprehensive selection of case studies across a variety of industries, and please feel free to reach out if you have a complex technical or business challenge that you'd like to solve.Richard Moot: And I would definitely plug for anyone, if you're in the Bay Area, go check out Chase Center. You can see some of their work there. You can go to Shake Shack, go order something. You can see how awesome that little app experience is.Adam Mack: I'll always recommend going to Shake Shack and ordering something. Yes.Richard Moot: Yeah. I mean, I will always pop in there regardless of whether or not it's good for me on that particular day.Cesar Aguilar: Who doesn't want an ice square?Richard Moot: I'm still extremely loyal to that brand.Cesar Aguilar: Yes.Richard Moot: Yeah, of course. And for anyone else that's listening, if you've got a project with Square, we'd love to hear about it. Reach out to us on our Discord, or you can reach out to us on X at square Dev. Don't forget to subscribe and check out developer.square.com for more. Keep building and catch you next time.

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