Engineering Enterprise-Grade Payments That Scale Globally

The Square Developer podcast explores the intersection of technology and innovation in the world of payments and beyond. Your host and Square Head of Developer Relations Richard Moot sits down with a series of guests this season walking you through the latest news, updates, and innovations in the Square developer ecosystem.

On today’s episode we are joined by Monstarlab Director of Technical Product Management Adam Mack and Monstarlab Engineering Director Cesar Aguilar. Creating seamless user experiences is more important today than ever before. From pioneering payment integrations with restaurants like Shake Shack to crafting innovative kiosk solutions for others, hear how Monsterlab is reshaping how businesses interact with technology, while always keeping the customer’s experience in mind.

Guests

• Richard Moot, Square Head of Developer Relations
• Adam Mack, Monstarlab North America, Director of Technical Product Management 
• Cesar Aguilar, Monstarlab Engineering Director

About Monstarlab

Full transcript

Richard Moot: Monstarlab. 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 Monstarlab. Can you both give us a quick intro and tell us a little bit about yourselves and Monstarlab?

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 Monstarlab in North America.

Cesar Aguilar: My name is Cesar Aguilar and I’m an engineer director here at Monstarlab based in New York.

Adam Mack: Monstarlab 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 (artificial intelligence), 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 Monstarlab 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, 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 card-present payments, 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 Astor 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 that kind, 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.

With Square APIs and SDKs, it’s Square — customized.

Learn more -/^

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 kiosks 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 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 are 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.

Richard 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 eCommerce, like I’m going to go through self-select things, or was 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 intentional 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 in Excel, like, ‘Okay, sure. Yeah, exactly. If it works, it works.’ What I 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 an 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. If

Adam 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 eCommerce 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 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 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 a 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, it’s 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 audiovisual based interface, that somebody can come help them. So a 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 cues, including the Sandboxed Square SDK and the entire set of UIs that come with it. So that was just a 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 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 sorts out 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 provisioned 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 , 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 frontend 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-tos?

Cesar Aguilar: For the kiosks? We’ve always done native for the most part, especially since it’s all, as we said, usually iPad-focused and it lets us do the best experience. We have done a couple of kiosk-type installations on Android devices, and for those, because of the different kind of limitations and variations, we found that more of a web-focused approach was kind of better than going full Android native. But in terms of just the actual kind of 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 writing 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 is 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 are your go-to setups for that?

Adam Mack: Well, I mean, Node continues to take over the world, so it tends to be a huge focus for us. 

Cesar Aguilar: No, I mean node for the frontend 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 .NET at more established enterprise platforms.

Adam Mack: Quote un-quote enterprise choices. 

Richard Moot: Yeah. Got to get the J2EE 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 spiky 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 frontends? Kind of 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 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 oddball is I always feel like I have to be very clear on it. It’s Node.js, not Nest JS. 

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 original, OG Angular with two-way data binding and weird digest cycles that make you scratch your head as to why this rendering bugs 

Adam 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: We are Monstar-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, Monstarlab 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.squareup.com for more. Keep building, and catch you next time.