The no-code and low-code market is expected to be worth $86 billion by 2027. Today, we’re excited to welcome Stacker into the Initialized family.
What if you could have a website that let you coordinate thousands of people without writing a single line of code, that you didn’t need an engineering team? All you needed to know was how to use a spreadsheet. That’s exactly what nonprofit team Project N95 was able to do with no-code startup Stacker. Without writing a single line of code, they were able to build a matching marketplace for people buying and selling PPE at the beginning of the pandemic. This is exactly where no-code tools are awesome! Stacker’s platform has done this for over 500 teams and thousands of users, and they just got started last year. Today, we’re going to meet the founder of Stacker, and I’m proud to call them an Initialized portfolio company.
Garry: Michael, thanks a lot for coming onto the show today. It’s such a pleasure to meet founders who are going out in the marketplace, figuring out what people need and then making it for them. That’s what a product market fit really looks like. So it’s a real pleasure to talk with you about what you’re working on. So, what is Stacker?
Michael: Stacker simply is something that lets you create software regardless of your level of technical skill. We let people turn their spreadsheets into software and create tools for their team and online portals for their customers to be able to log in and interact with the business in a more straightforward way than sending an email or filling in a form. We’ve tried to make it really easy for people who are really not technical. I don’t just mean not programming but even not thinking about what makes an app or how an app should work. Rather than making you go and define a data model, you can take some data you’re already using like a spreadsheet, like Google Sheets or Airtable [and] connect it to Stacker. And we automatically create something that is a working app, which you can then customize to fit your workflows; add to your brand; and [add] your own particular theme to it. But it’s always a working app, and you just make it work the best way possible for your use case.
Garry: Yeah, so that’s powerful — how people probably already track all kinds of work processes internally. They’re highly likely to be using Drive or Airtable already and where you come into play is: if you wanted to add a little bit of logic or if you wanted it to be more multiplayer but without messing up the data model; or having workflow, you know if something has to progress through steps, which actually, if you look around, it sounds like it happens everywhere in business.
Michael: Yeah, absolutely. There are so many places where data, which is stored in spreadsheets or in various places in a business, gets interchanged between different departments; between customers emailing in to say, “What’s the status of my order? How’s this project going?” or “Can I update my billing?” They’ve got all [of] this data, which is just locked away, [and] they can’t do anything with it because it’s trapped in a spreadsheet.
Garry: It sounds like it’s being used by hundreds of different companies right now.
Michael: We’d been working on the problem of letting people build software without writing code for quite a long time, but this particular product we released just at the end of 2019. And right now, we have more than 500 companies using it, and they’ve got tens of thousands of end users — and they can be customers, and they can be teams using the apps that they’ve created.
Garry: One of my favorite questions is about the origin story. How did you start working on this? I remember that was always one of the most interesting questions to ask any startup, especially when I was at Y Combinator as a partner.
Michael: Yeah. So, I actually met my co-founder Sam at an asset management company in the city of London — a really traditional, very British, very middle-sized, mediocre, very backwards asset management company. We were working for the IT department, and we were kind of tasked with finding out what this new technology Salesforce was and how it could be used in this organization. Very quickly, we worked out that it was pretty mediocre CRM but actually quite a really interesting low-code enterprise app development platform. And we started going to different department heads, just me and Sam, saying, “Hey, what software has your IT department given you so far that you really hate? And how could we make your life better?” and working with them super closely to kind of use this platform, writing some code and using this low code environment to create exactly what they asked for. We’d come back the next day or a couple of days later then they would tell us some more things, and we’d iterate really, really quickly with them saying what they wanted, us giving it to them. And eventually, we delivered loads of great stuff for them, which was just a complete revelation. They were used to six months, 12 months, 18 months to even just buy some software off the shelf. Being able to do this so quickly and have it fit exactly their requirements was mind blowing for them.
Garry: Yeah, it’s funny. When it comes to technology and some of the world’s honestly, most revenue-generating spaces, like asset management, you look at the kind of IT and the type of software systems that people use, and it’s frankly junky as hell. You kind of can’t believe that they’re still using stuff like that. When I sort of first started my startup journey, I was at Palantir very early, and they’re almost notorious for refusing to work on anything that doesn’t have a seven-figure annual sales contract. And I think that was one of the key things they discovered. There are scenarios where, you know, there’s no software and the amount of savings or change in the business absolutely justifies seven figures of spend. If you look who they can actually turn to for solutions, it tends to be horrible consulting firms with packaged software that barely meets their needs. And then it’s crazy over time, always over budget; it never quite does what people want. You and Sam working on something very diligently and having very tight cycles is incredibly rare, and that’s exactly what I remember seeing Palantir do. We would go in; have an enterprise sales meeting; show them an initial prototype or design; [an] sometimes even, there’d be a Flash demo of what it might be. The next week, rather than show them 20 pages of PRDs that [woul] make people’s eyes glaze over, we would actually show them sometimes a demo, sometimes a working product that did exactly what they had discussed last week. They would sign on the dotted line right away for a pilot because they had never seen anything like it. I think that’s a really cool story because that’s one story that everyone can actually implement tomorrow. If you’re doing enterprise sales, if you understand technology and can deliver it very quickly, a tight sales cycle is super powerful.
Garry (continued): After this experience, it sounded like you moved over to the land of startups and that got you a little bit faster iteration cycles.
Michael: Yeah. So after this, I went into some very operations-heavy, marketplace-oriented startups, a couple of them in a row. I thought that we’d be moving out of IT and into the land of tech startups, hir[ing] teams with really fantastic engineers, but actually, we never really cracked how to make this internal operational software. We spent a lot of time with the product roadmap working on the customer-facing, the actual product — even though most of the innovation that the businesses were doing was not product or technical innovation but was actually operational innovation. We never seem to find time in the roadmap to build this stuff. But worse, I think when we did, it just was never very good. That wasn’t because the people involved weren’t great. These were really,really data-driven astute operators. I had a really motivated team of really smart people, but these guys were just no good at writing precisely exactly what they wanted, and potentially, they didn’t know what they wanted at the start. They needed to see it and get their hands on it, and my team didn’t really have the context to make those micro-decisions at the time. Usually, we’d chip something, and they’d say, “Oh that that’s not quite what we wanted. Could we just…?” And we’d say, “No problem.” Just goes on the back of the roadmap, and six months later, they get another shot. It was frustrating. It was just terrible because I knew we were shipping bad software, and it was frustrating for everyone. Thinking back to how close we had been to the nirvana of letting these people actually do it themselves when we were using Salesforce. At that time, we still had to have the Michael and Sam translation layer, right? There was still us taking the requirements from these business people and turning [it] into the app. We thought, “Well, what if we could just get rid of that middle layer? What if we could just let these people actually own and iterate on their software themselves?”
Garry: That’s powerful. I think that there’s something very classic. I just think about how many startups that have become billion-dollar startups that actually started exactly in this way, where you see this part of the world sort of over and over again. In a way — especially for those that are technical startups that have software engineers but they have to focus on other parts of the business — you need to scratch your own itch. That’s exactly the kind of observation that sets the world on fire, and it totally mirrors what I saw: you don’t need expensive consultants, and you also don’t have to wait for internal resources that will never, by nature of business, be unable to prioritize the needs of say, an ops team, and that doesn’t take away from the needs of the ops team. Those are fundamental pieces of making a marketplace work. It sounds like the big realization, very core to no-code broadly, is: if software is eating the world, how do you play in that world if you can’t write software itself? Your [Stacker’s] contribution is you don’t have to.
Michael: Yeah, exactly, exactly that.
Garry: How do you think about what Stacker is really uniquely good for? We talked about internal software. How do you [meaning Stacker] think about it ?
Michael: There are a lot of no-code tools out there, which are [there] to help you make the next product to make the next Airbnb or something. We’re not for that. We’ve tried to focus really strongly on the real use cases that businesses already have. So typically, processes that are running — and they’re running kind of manually — there are lots of people involved; there’s lots of manually sending data back and forth. One thing I like to think of is: imagine Uber bought out this business unit or is trying to run this process, and they had the whole might of the Uber software development power behind them. What are the systems they would make in order to make this a really, really slick process? How could we kind of give some of those [systems] to this business without the huge resources of Uber [and] still be able to achieve the same things? Really, we take things that can’t be automated, but [the things] where you want to connect people directly to the data so that they can interact with it directly rather than having to send emails or make phone calls.
Garry: Yeah, I think one of the really interesting things that you guys do is that you have this concept of a user table or a user spreadsheet — that’s really unique. I hadn’t seen other people do that properly. And I think that’s a really key part of [this], and this is very subtle because you have to have built these systems to even think to know that that’s a problem; you need to be able to have a sense for who is actually accessing the data in order to know how they should progress through the workflow. [Stacker] is useful broadly for all kinds of things, like tracking approvals for healthcare. What are some examples that you’re particularly proud of, that have resulted in really big gains for your customers?
Michael: Well, one of the most exciting things that we’ve been involved in over the last 12 months is something called Project N95. This is the United States’ National Clearinghouse for PPE, for protective breathing equipment. These guys were not-for-profit and obviously suddenly had this huge, huge burden of both healthcare providers looking to be connected with a supplier and suppliers of this PPE, who had various bits of inventory that they needed to get distributed as quickly as possible. What they did was, without having to write a single line of code (because this was happening really quickly as the pandemic) make something where the buyers can login, write down the requirements and be matched with some potential suppliers, and suppliers can go and update all the different stock in real time as they’re sending it out and allocating it. And actually something for the volunteers who were part of this program to match the people with the highest need and the high supply. That, for me, was really fantastic — to see that unfolding before my eyes in real time, something that eventually turned out to be a bit like a two-sided marketplace.
Garry: Basically with an Airtable or with a Google sheet, you could make a multi-user workflow application that makes the whole thing run. Classically, what you would do otherwise is you’d have a coordinator who has an email address. Maybe you have to fill out a Google Form, and then they have to manually copy and paste rows from here to there. — in some ways, a little bit mad to think that that’s how people do it. It’s basically just a digital version of paper and pencil. With Stacker, you can get rid of that. You don’t have to have that person do that anymore.
Michael: Yeah, that’s exactly what it is. Often, at the heart of this, there is someone who’s been running this process themselves. They have been acting like the app; They’ve been taking the data, splitting it across different spreadsheets, sending it out to people bringing it back in, recombining it, doing the sums…It’s just a really waste of time.
Garry: Daily weekly. Over and over again.
Michael: And it’s not even a good experience for anyone involved. It’s not like a beautiful concierge service. People want to be able to just log in to an app and see what the status is rather than having to ping a message to say, “Hey, can you tell me my balance or whatever?”
Garry: Yeah. Can you think governments around the world, departments of motor vehicles around the world have paid consultants like tens of hundreds of millions of dollars every single year to do what? Frankly, [what] one person could probably design in Stacker in about an hour or less, maybe twenty minutes honestly. I think that’s actually a really cool observation, too. You don’t have to have a highly technical person go and make the Stacker; you could have the person who was the email router go in and create it themselves. Because they had to do the process themselves, they intimately know what the requirements are. So all-in-one, they’re a product manager, engineer, test and operations, and that’s super empowering actually.
Michael: The super cool thing is that the people who deeply understand these processes are the ones that create the app and continue to own it and iterate it, and it really is all in the iteration. I’m sure if you’ve made a complex spreadsheet before, the first version of it was not correct. You really had probably no idea exactly what was going to go into it until you got your hands on it. And then you thought, “Oh, I’ll add a new column. I’ll move this over here.” Having that [understanding] as quick as possible is what makes these systems really great. To be able to — as soon as they find that there’s a bit of a hitch in the process or something that could be done faster [and] just immediately change it… no writing a long spec and then getting that into the development cycle and then getting it back out again — just change it. If it’s good, keep it, and if not, change it again.
Garry: This reminds me of this Japanese concept called kaizen, which [means] a “change for better.” It’s continuous improvement, and then the key thing from the tear to production system is [that] you know [that] this is not a top-down thing; this is a bottom-up thing. It’s the bottom-up that sees what is broken and then if you can enable them to fix it. I like to think about how that resulted in highly highly reliable cars throughout the ‘80s and ‘90s.
Michael: Yeah, and I think we’re trying to do the same: get people to have really, really well-run teams and well-run departments and really select processes. Everyone who’s building on this is not someone who is engaged in the process of making software in general; this isn’t project managers or product managers being able to make this stuff without having to bother the dev[lopment team] so much. These are people who would not otherwise be creating software, and these are all apps that would not have otherwise been created. This isn’t a cheaper way to do it. These just wouldn’t have been made otherwise — that for me, is really satisfying to know that basically that part of the world is just a lot slicker.
Garry: That’s exciting. I’m glad that everyone in my YouTube community can actually take a look at this and hear about it first because basically, if you run a business, you need Stacker because there’s always going to be some sort of flow, working with vendors, working with partners, business development, sales…you name it.
Garry: Michael, one of my favorite things to ask, especially founders who I know have reached product market fit — because it’s so rare to find something that people really, really want and to be sort of climbing that scale wall, which is very, very hard, and often it feels like there’s no net… it’s just rare to be where you’re at… My favorite question for people is: what do you wish you knew when you were 18 or 22? Maybe before you came into tech? What have you learned or wish you could send to the younger version of yourself, knowing what you know now?
Michael: I think back then, I thought it was all about the technology. If we got more deep into programming languages, if we had more technologies, we’d be able to solve problems better. But I actually, having been all the way through that cycle of like, “Okay, let’s go really crazy on technologies.” I’m not really of [that] mind [anymore] — it’s about [a] deep understanding of problems, and it’s also as much a human component as is the technology component in any solution really. I wish I’d worked that out earlier so I could have spent more time focusing on what exactly, what problem are we solving and what are the constraints and how will this affect people rather than just like, “Oh well I’ll read a book what we can use to do that.” Because loads of times I would write some dazzling stuff, and it’s just being absolutely useless because it wasn’t solving the right problem or it wasn’t doing it in the right way…so definitely focus less on the tech in order to do [the] tech well.
Garry: That’s fascinating. There’s a sort of minimum bar for people to be tech proficient, and the ability to take on any sort of new technology work with it and ship code. There’s a facility with it but then past [that], a certain bar. You’ve got to go back into user land or problem space land. Technology is not an end in itself. The only time when something magical can happen is when it interacts with humans and then hopefully leaves the humans in a better spot than before that technology interacted with them.
Michael: Yeah, I kind of have a maxim that I try to use the minimum amount of technology required to solve the problem. Whereas maybe in the past, I’ve tried to use the maximum amount.
Garry: Yeah, that reminds me of that design maxim by…I think it was an Eames quote… “The best for the most for the least.” That’s sort of like the min-max on creators — the best possible product for the most number of people for the least amount of cost and maybe with the least amount of technology, right?
Michael: I’d definitely buy that.
Garry: Awesome. Well, Stacker is hiring. That’s the coolest thing about product market fit — everything’s on fire and in a good way— but that’s the place where you can learn the most.
Michael: Yeah, so they should go to stackerhq.com/jobs. And we are hiring for product engineers, product designers, but really actually, we’re looking for people in every part of the company. The great thing about a growing startup is that jobs just appear almost out of nowhere. And sometimes, you almost don’t know what you need until it comes along. We’re looking for smart people and people who are interested and passionate. And your channel listeners are a good proxy for that.
Garry: Yeah, that’s awesome. On the flip side, probably everyone watching here, whether you know how to code or not, could be a really good user for Stacker. Sooner or later, there are going to be pieces of data, like parts of workflow, things that you need [and] interact with lots and lots of people — it might be overwhelming what you have to do — but then software is really good at that. The second you can make a multi-user app that has a workflow that allows you to skip having someone manually coordinate — that’s kind of magic.
For more conversations like the above, along other leadership and startup topics, be sure to check out my YouTube channel and subscribe. To stay up-to-date with all the latest Stacker news, follow them on Twitter.