Mo Hashemi is the Co-Founder of Gadget, a full-stack, serverless JavaScript platform for web app developers who want to build faster and maintain less. At Gadget, they're building a development platform designed to rid developers of the endless repetition of boilerplate and busywork, allowing them to build better software, faster.
On this episode, Mo and I discuss Gadget's revolutionary serverless stack, how they cut down on app deployment time, the expansiveness of app customization, and much more.
What is Gadget
Mo Hashemi: So what we're trying to do with Gadget is essentially simplify the process of building eCommerce applications on the web for app developers. Right now, the set of steps that they have to go through build a custom or public eCommerce app for any of the major platforms.
When a store is trying to customize their business, the set of steps that a developer has to go through are really long, repetitive, and there's a lot of boilerplate work involved, and ultimately that translates to more development time and more money spent by the brands that are having these kind of custom applications developed for them.
And so what Gadget tries to do is it gives these developers a framework and an approach Of building e commerce applications that materially faster because we take care of all the repetitive stuff, the integrations to various data points, the infrastructure. And we just leave the developer to focus their time and energy on like the business logic and writing that code and not the boring boilerplate work that they kind of have to do over and over again.
So yeah, it just makes e commerce app development super easy and fast and therefore brings the cost down for brands and agencies that are engaged in this type of work.
Alex Bond: That's great. So you're kind of streamlining that process a little bit as like a layman, you know, I'm not the eCommerce expert that you might be and some of our listeners are still kind of maybe in the one on one stages.
So I'm curious if you could just give us a little background, a very quick explanation on the difference between the front end and the back end of an app to kind of like lay the land for some of the things we'll talk about in this conversation.
Mo Hashemi: Typically, the front end, there's usually two front ends. There's one that's kind of like buyer facing, and that's the user interface that your buyer will see on a store. Shop itself, the homepage, the product page, a picture of the product, the content that describes the product and lets you kind of like pick and select and go to checkout. That would be the front end. It's the user interface. It's visual. Your end customer sees it. The buyer sees it.
There's a second front end as well sometimes in applications, which is kind of the merchant facing front end, right? Like sometimes you as the business will log into, let's say a platform like Shopify or whatnot, and you see a interface as well, and you use that interface to build your store or manage some portion of your store.
So both of those are front ends. I would say buyer facing front end merchant facing front end. And then the way front ends typically work is they need to store data somewhere. Data has to be kept secure. There's some logic typically that needs to take place. Maybe when you click a button, some sort of SMS gets sent to somebody's phone or email confirmation goes somewhere.
That logic typically lives in a back end. So the back end of an application and software development is typically responsible for like security business logic. When the user clicks this button, what should happen? You know, maybe a payment process should be started. A credit card should be charged. That's typically logic that lives in the back end.
So the front end is a visual user interface. The non technical user will interact with by clicking around and then that will tell the back end to do a bunch of stuff. Save a bunch of data and return the information to the front end so it can be displayed to the end user. So that's how I would kind of try to define front end and back end and layman's terms for eCommerce at least.
Unique Customization Abilities of Gadget: Going Beyond Boilerplate App Development
Mo Hashemi: The way Gadget saves developers time is kind of in three bucket.
First of all, zero set up. Typically, anytime a developer wants to build anything on the internet, there's a phase of just like getting all the pieces of infrastructure and languages and libraries to talk to each other and that takes a while and you do it over and over again. And it makes no sense that you do it over and over again.
So first things about Gadget is you just kind of like start a project, all of that's taking place for you start building set up. The second part, a development platform comes with integrations to the major e commerce platforms. So we already have one to Shopify built in and we're adding to WooCommerce, Magento and others.
And typically what that means is when you need to fetch data from a platform, that's hosting a lot of the information about a store to power your application, because typically you need a source of data like it might be Klaviyo, it might be Shopify, a lot of this data lives elsewhere. Gadget gives you those integrations by default, so you don't spend a week or two weeks reading Shopify's API docs.
Figuring out how to integrate Shopify, how to fetch data securely, how to handle weird issues and errors that occur. You just log into gadget and say, I'm trying to connect to this data from Shopify for this store and the integration is set up. So that's the second piece. So zero setup, zero integration.
And then the last piece is closer to what you were describing. We have a framework and that framework, you learn it once and you use it and what it does is it kind of reduces the lines of code you would write. So in the back end, specifically these days in 2023, the patterns that we use for building web applications are pretty common and pretty visible to everyone.
Like if you've 10 years, you'll just see the pattern of what you're doing over and over again eventually, and the analogy I like to use is like, 2023, but developers show up to a construction site knowing they're going to build a brick building, they show up with sand. It's like, well, that's a bit weird, you know, like, we're building brick buildings, we've been doing it for 30 years now, we see the pattern.
Maybe it's time for new tools, and maybe it's time to show up bricks. And so what the best way to describe the gadget framework that third part that reduces the lines of code is it's trying to give you like higher level components because we're not claiming gadget is a tool for building all software ever.
We're saying Gadget is the fastest and best way to build eCommerce web apps. And if you need to build eCommerce web apps, which in my analogy would be brick buildings. Let's start with bricks, not sand. Like you're not building glass buildings. You don't need sand so that you can change your mind about what type of building you're building halfway through. You build Shopify apps or e commerce apps, here's a brick for building that specific thing.
And that's the third part of Gadget's offering is that framework that typically on the back end reduces code by about 70 percent and on the front end, maybe 10 to 20%. And ultimately all of that translates to like your app is out the door faster and whoever contracted you, whether you work for a brand or you're an agency. They get a better deal. Like you can build more software for the same amount of money and further customize your online stores to make sure that your customers needs are met.
Alex Bond: No, that's wonderful. And just to kind of continue that analogy, if you're operating with efficiency, it's not like you need to make all the bricks from scratch, because thank you with current developmental methods, you know we just need to show up with bricks. We don't need to take the time to create each and every single solitary one. We can go quicker if y'all just show up with the bricks or what have you.
Mo Hashemi: And we're not claiming the Gadget is no code. Like, you still need to code and we still believe that voting the unique parts of an application is the fastest way to build it. But for the stuff that you've done 10 million times, it doesn't make sense that you're writing it over and over again.
And you should just be given those components as a starting point. And that's kind of the point of gadget is the default starting point is very, very high. And kind of filled with a bunch of best practices as well that we frankly developed while working at Shopify. So both my co founder and I ran a large team there and it's a very similar framework to what we used internally to scale software while working at Shopify ourselves.
Gadget's Serverless Approach and Data Storage Solutions
Mo Hashemi: I think serverless nowadays has been around for quite some time, where like everyone pretty much keeps their stuff on Amazon, Google Cloud, or Microsoft Azure. It's like 98 percent of the internet is running on one of those three clouds.
So Gadget is serverless in the same sense, but what's a little special about Gadget serverless is it's at both the, what would typically be called like the code execution environment level, as well as the database level.
So both of those things are serverless, and it's the framework we've developed that effectively allows us to say you're going to hook into our platform in these structured ways that we give you and have documented for you using your code, but because it's a structured way of connecting your logic and our existing logic together.
We can take the responsibility of scaling everything about your application, no matter whether you're getting like one minute, you know, event an hour or a million events because you're doing some gigantic sale. Our framework allows us to move that burden of responsibility of figuring out how to manage servers and databases and scale the knobs.
Because even if you use Google and AWS, you still have to go tinker with them constantly and make sure you have the right settings. Our framework just allows us to take all of that on. So basically, it is serverless without any management, and it's serverless both at the code execution level and the database level.
And that's a bit special. Typically, serverless means just code execution, not database. The reason we feel confident we can do this is actually my co founder, Harry, very much responsible for building a similar architecture that we used at Shopify. And scaling Shopify's backend was a real challenge of engineering. And so, you know, it scales. And so now we're kind of like more productizing it and offering it as a service to other developers.
Alex Bond: Yeah, no, that's impressive. And especially, obviously no offense to Gadget, but I think that sort of two pronged approach, y'all size is very different than an Apple, a Google, an Amazon.
So I think that's what's revolutionary about it is its accessibility and something that doesn't have billions of dollars of input to make that possible. So I think there's a lot of innovation and creativity to solve that problem there.
Mo Hashemi: Yeah, well, to be clear and to be fair, like what we actually do is we build on top of Google cloud. So not everything that we're managing is done from scratch. Typically what we do is we take those lower level concepts that are pesky and require a lot of setup. We take those from Google cloud. We work on them. We built these higher level components that I call the bricks. And we offer them to our customers.
But there is a portion where we leverage, you know, some of the best in class infrastructure built by in our case, Google, we could have gone with Amazon or Microsoft. So I want to clarify, like, there's for two reasons when there's no really good reason to go build another cloud provider these days and we're not crazy enough to have done that from scratch.
But also, there's a lot of trust and security built into going with a Google or an Amazon and Amazon. Ultimately, we went with Google and we build on top and we sell these higher level components to our customers.
Accelerating App Deployment: Unveiling the Rapid Go-Live Process of Gadget
Mo Hashemi: We, again, that's kind of part of the framework. Our definition of boilerplate is quite extensive. It's like a developer who finishes building something, the process of actually putting it online is filled with a bunch of challenges in itself and copy pasting things that can go terribly wrong and have weird results.
And so for the Gadget framework, there's two parts that are really interesting. When you start a project, you already have a web URL that is live. And anytime you make changes to your project, you can go to that URL and see exactly what changed and that is both in development and in production. Like production. That's normal. When you're showing off your app to your end users, you go to production, you deploy. And they see everything running on the Internet.
Development, typically, you don't see things running on the Internet. You see them running on your computer, and you kind of, like, assume it will run similarly on the Internet. But that process of going from your computer to the Internet, you'll run into 50, 000 problems. It takes sometimes an hour times. Sometimes you'll be stuck for days trying to figure out what went wrong.
Gadgets, cloud development and production environments are both on the internet from the moment you start. And so what that means is once you're done building and development, the process of going to production is you click a button, we'll take care of all of it.
There's not going to be any surprises because you build your app on the same cloud that you're trying to deploy it to and by building it on the same cloud you're deploying it to all of those pesky issues suddenly disappear and we can give you a button. And it's like, well, just click that button and we'll move it over for you instead of you spending 2 3 days of your life trying to figure out what went wrong and troubleshooting.
So that's kind of the what's neat about Gadget like zero deploys because literally everything about deploying software to the Internet is nonsense and has nothing to do with what you're building, regardless of whether I build your company or mine. There's a nasty deploy process that's very much the same, and it's entirely boilerplate busy work that should just go away.
Alex Bond: Yeah, because assuming something is gonna look the same on my laptop as it is on your phone two weeks from now is something that I've personally had experiences and headaches from, you know, in a perfect world, everything just does what it's supposed to, but you above most people probably know that being able to mitigate that sort of a headache is extremely valuable.
Mo Hashemi: And again, like all of this goes back to the brands because like what people don't realize is the cost of software is really high for two reasons. Like developers cost money, but also developers are spending a lot of time doing a bunch of repetitive nonsense that somebody's paying for at the end of the day.
Our goal here is, like, not just to make development faster and more fun for the developer, like, we still, we want them to focus their time on the parts of the code that are unique and fun to them, but to the brands, it's like, well, those ideas that you used to think of as cost prohibitive are maybe not so cost prohibitive now, and you should pursue them and build more software.
You know, those ideas that were going to cost you 10k, maybe they should cost you 5k now, and the other five can go to yet another app idea that you just couldn't justify. Our hope is like we're changing something for developers, but the end benefit should really be for everyone in the eCommerce space.
Simplifying App Development: Exploring Gadget's Powerful Automated Functions for Users and Builders
Alex Bond: And one of those things that has also made developing easier is automated functions that you can provide for users or builders of the app. So I'm curious what some of those automated functions you can provide are.
Mo Hashemi: Yeah. So to the end developer, I think primarily like two of the really big pieces that we provide are the ability to synchronize data with any e commerce platform.
So typically that involves if you want to fetch, let's say, a million orders from a Shopify store and send it to a custom ERP system that is tracking inventory and orders. That process of getting a million orders from Shopify is a real challenge and what Gadget does is it gives the developer a button.
A little button and an A. P. I. call one line of code thing. They can write and run that essentially takes care of the entire process. And when I say that process is a lot of work, if you've never done trying to sink a million orders from shop by to elsewhere as a developer, like your first time around is probably at least a month of your life.
And so Gadget, one of the really neat features is like, here's a button that does that for you, if you don't know how to do it. And here's an API call that does it for you as well. That's one of the most popular features of the platform for developers today. And then the second part is like, there's this thing in a software called the web hooks.
Like when something happens, the platform that knows something happened informs all the apps. So Shopify, when an order gets placed, we'll tell all the apps, Hey, an order got placed. Here's some data, do what you need to do. And let's say your app is doing shipping labels. It'll be like, okay, well, here's a shipping label for that order.
So all of that is handled by Gadget, like how building a pipeline for when Shopify fires events, what to do with it, how to store the information and also these events are flimsy, like servers go down, there's no guarantee that you got 100 percent of them. So like what to do every night to make sure you actually got the full set during the day. Gadget magically makes that go away.
And that's another really big feature developers love is like 100 percent guaranteed data delivery without you having to work for it. So I would say those two are kind of the platform features that shine the most with app developers. This ability to just like click a button and get as much data as you want from a store without having to work for it. And this ability to make sure your data is always, always, always synchronized with these underlying platforms, which is a really tricky thing to build, right?
Alex Bond: I think what's fascinating about automations, right? Is that, that word is pretty standard in terms of the infrastructure of most eCommerce companies nowadays is like, you know, we provide automated services, okay, that is such a broad category of what that really means though.
So I'm curious, and in your opinion, Mo, is that a capability? This might seem like a rhetorical question, but that seems like a capability that's still being constantly developed. So when people tell, you know, we have automated services, it kind of feels like a bit of a half truth. I'm curious if you have any sort of solution as to in my opinion, things are automated because of artificial intelligence. But that is a phrase that has a lot of weird connotations to it.
So automated feels safe, but artificial intelligence fears like fearful. So I'm curious what sort of a dialogue we can open in terms of trying to say that what you're doing is pushing boundaries in the best way possible. Does that make sense?
Mo Hashemi: Yeah, it does. I think, like, if you think about a Gadget, it's all about automation, but it's really automating things developers shouldn't be doing for developers with the aim of helping them go faster and the way we kind of handle this, like automation in our case has to be extensible, like we're not building an app.
We are building an app building factory. And so in our case, when we give automation to our users, the developers, they have to be able to take them and extend them and do something unique with them, which makes our job particularly tricky because it's not like this one specific automation. It's actually an automation factory so that the developer can build whatever they want.
So that's where the framework that word I was using comes in. It's actually like a well documented stand. Here's how we do our thing, explained, and here's how you slot into our thing to do whatever you like. Our thing is automation of boilerplate that you would have spent endless hours writing.
So we automate the boilerplate, we express what we just did to you in our framework, and that's important because you need to understand what we did, so you can go in there and stick in your code and do something different. And that's how automation works in gadget is like there's a lot of automation of boring monkey work of typing the same nonsense over and over again.
The output is a user interface described with a framework, and then you can extend it and do whatever you like. So I think the best way to think about Gadget is back to kind of like automations is the use cases for building automations for merchants on top of Gadgets, which you can also do typically start when Tools like Zapier come up short, because if you can build a simple automation for a business, that's like, if order takes place, then send email like, yeah, it's a great tool.
And there's like a million no code tools for it. Gadgets use cases typically start at more complex automations where it's like, when this happens in Shopify, I got to take the data and I got to change the data a bit. And then I can send it off to this other place. That's like typically the starting use case for Gadget in terms of simplicity and complexity. And then all the way to like full complicated app with a user interface and a backend and all that.
So definitely big use of automation within Gadget to streamline developer workflows. AI we're starting to explore a bit because we think we have a unique advantage as well of just being able to have our own kind of code generator built in that will just help the developer like write faster as they go write the limited amount of code they're expected to write, but it's still very early days for us.
So we haven't done nearly as much with accelerating workflows with AI. And frankly, I would say with AI, it would probably be less automation, more like acceleration, like there's going to be a human who needs to review the thing, the AI output, because it's not going to be a hundred percent perfect every time.
Alex Bond: Where a coder does more quality control than coding. And even then that's. That' a little way down the road.
Mo Hashemi: With a blank screen, you get a nice screen of texts and you edit it quickly, so it'll be more acceleration versus like what we do in the framework is true automation. It's like, it's taken care of. It's over. We did it just hook into it and extend it and do more.
Driving Business Success through Expediency and Efficiency: The Strategic Focus of Gadget's Development and Scaling Approach
Alex Bond: And after talking for a little bit, there seems to be a clear emphasis in your business model on expediency would probably be the best word that I can come up with is expediency and efficiency, develop and scale quickly. Why such an emphasis on that? Was that like an active decision when creating Gadget that was your emphasis was, or are we still figuring that out?
Mo Hashemi: We're a young company and we're obviously figuring out our messaging. I think the speed thing really spoke to Harry, my co founder and I, because I think our view is just like, there's a lot of software that non technical people want, but often refrain from asking for because it's just understood that it's like, Oh, that's cost prohibitive. Like, that's not worth it. The ROI is not there.
And I think that is a shame. I think that is a byproduct of the tools developers use and the languages developers use. And it's resulted in this world where we can't have all the great, fantastic software that accelerates human development that we want because some of it we've deemed to be cost prohibitive because our tools betray us and force us to do monkey work that somebody has to pay for.
Alex Bond: If you don't mind, Mo, that cost is essentially the barrier for entry for certain people getting involved in developing ways to make it, it's kind of like a recursive catch 22 cycle.
Mo Hashemi: Exactly. And so what we're excited about is a new paradigm where the cost of building software drops dramatically. And our view is anytime you make something hard and expensive, easy and cheap, there's actually just growth in the pie. Like the market just gets bigger.
Because what ends up happening is all the use cases nobody was talking about start start showing up and everybody wants all those things built as well because all of a sudden the price is reasonable and it makes perfect sense to go automate that pesky annoying thing that your colleague is doing manually a thousand times a day.
Like a developer is going to do it for me for 800 that's worth to not 8,000 and so that's kind of like why we emphasize this is like we just think it's sad that all of this useful software doesn't get built because of its cost. And so we're like, why is the cost high? The cost is the speed. Let's focus on reducing all the boilerplate and getting things faster.
That said, the messaging is in flux. I think the messaging I like is if you're an app developer, you get to focus your time and energy on the code that matters and all the pesky things you've done a thousand times are taken care of for you. And your ideas get to market faster. If you're an agency, you just get to output a lot more with the same staff and make more money.
So like going faster is a means to an end. The end is focus your time and energy on the code that matters and is fun and is unique for the developer and for the business owner. It's really, you know, you can actually make more money. You know, you can build more things with the same amount of time and with the same headcount. And you're not getting the most of it. And so that's really the, maybe the new messaging that we're going to move towards.
