Unlock High Speed Builds with Five Magic Words

Ray Deck explains how to build faster with no-code tools by embracing the mindset "you will build this again." Instead of trying to get it right the first time, he breaks the approach into four parts: beginner's mind, choosing tools that match your current skills, rapid prototyping in days or weeks, and learning with each iteration. Small releases give you market feedback and let you find what customers actually need.
Chapters
The most important 5 words for the success of a no-code, low-code project are, you will build this again. My name is Ray Deck. I am the founder of statechange.ai. We are a group that works on the hardest 5% of no-code, low-code projects, a community that is focused on helping each other and making progress with our various initiatives. My background is I'm a data scientist by training. I've been CTO or a software startup founder for the last 25 years, built a couple of relatively successful companies and also do angel investing. And most recently I've been getting into the world of low-code, no-code with StateChange, focusing on those hard parts to just get past that bit that can feel just a little bit more impossible. And what I have found is that a lot of the time these questions are about the mental model. And the mental model I found that we use here at StateChange really has 4 major parts. And the first of them is the idea of a beginner's mind. And within that, the most controversial idea we do is you will build this again. Now I say you will build this again, and I mean this as something that should be encouraging news. It's not the despair of, oh no, that means that that which I built isn't going to work. No, in order for it to work, we need to embrace the idea that you will build this again. Again is because we are going to be making this iterative progress towards the end that we all started with here, right? Either a certain change you want to make for your customers or for your business or for yourself. And it is with that end in mind that we're going to sort of make this vector, right, of which way we're trying to go. And then we're going to, you know, take steps towards that in order to accomplish the goal. It's not like we just sort of spec out this one piece of software that's going to solve all We're going to spec out our first guess at what we think is right and be able to make that happen a whole lot more quickly. That's where this tooling, this no-code, low-code tooling becomes so important. I was just talking to a guy who was debating between building a site in Card versus building a site in, in TypeDream. And it had a lot to do with what was the immediate job to be done and what was the skillset they were bringing to bear. Now we talk about that a lot in the Shopper's Mindset, which is all downstream of this idea that we are trying to use the tools that are most compatible with where we are today to accomplish what we want to build coming what we want to create for tomorrow. So we should be embracing the idea that we're going to build this again. That our goal is to learn as fast as we can so that we can— and what we're going to learn is going to be both technical knowledge as well as market knowledge. So we want to ship as fast as we can into the market so they can be telling us what's working and what's not working. One of the great things about these tools is that we can ship them something of relatively high quality and, well, quality from their point of view, and that is going to answer some of the questions that we have at the beginning. And then we become a whole lot smarter. And that, that intelligence is what we're really building up here. We're building knowledge, not just the artifact. Now, in order for us to really make good progress, we need to differentiate the parts of the, of the software that we're trying to build. We need to differentiate what matters. And there are two kinds of things that might matter. There's going to be the impact on the market or on our customers, colleagues, what have you, that really matters. Like, what's the sharp end of that stick? And also which parts of the technology really matter that we need to use and which parts we're discovering are going to be a bit more sticky. Learning both of those parts, that technical knowledge and that market knowledge, is what we're trying to do as early in the process as we can. By taking the approach of you will build this again, we're building prototypes that are answering both technical questions as well as those market questions, and we're shipping them through and we're building this habit, right, of, of, of iterative learning. Eric Ries calls this validated learning in The Lean Startup. Marty Cagan refers to 4 types of prototypes, basically 2 of which are on each side of this equation here: the high and low quality, high and low fidelity user prototype versus the business and the technical prototypes. And we need to discover the answers to these questions. We want to do it early in the process. So by embracing the idea of you will build this again, we have a mental model model that allows us to make that progress in the direction that we, we need in order to, uh, learn those things and be able to ship it out. Now I've been talking so far in terms of project, but there's something more important to this than the project. That's the builders. The people who are actually working on this project are themselves becoming smarter as they work on it. We've all had this experience, right? We go build something or we get involved in a project or what have you. And at the end of that project, we are at our maximum level expertise in that particular domain. And then we don't, we just don't do it again. Now that is sometimes the difference between having a hobby and having a profession. Sometimes the difference between having a project and having a career. But one of the things I've discovered about building, especially using these tools, is that we have the opportunity to make use of that fact iteratively. So we're going to climb a curve of knowledge and become a smarter version of ourselves. And then because we're doing it in a loop, We're able to have the next step on that be one that is working off the baseline of that previous level of smartness that we had, and then higher, and then higher. That means each iteration that we do in here, which is usually measured in days at a minimum, at most it should be a couple of weeks, is going to be, you know, it gets to be stacked on top of higher and higher levels of knowledge. If we try to do it as one big, you know, design and then build and then test and then ship project, Um, we're starting, we were doing all of our designing work and all of our planning work from the point in which we know the least in the market. When we have the little iterations, we're able to be much farther along the curve before we're making those commitments that are closer to where we're going to be, be done with the whole project. And I got to tell you that this idea of like discover what matters is a really, it's kind of a big idea in here because that discovery is sometimes not even the, the boy discover matters. It's sometimes not even on the list of things we knew about ahead of time. We don't know what matters yet. And so the— we use validated learning to see whether our original hypotheses are right. Sometimes they're wrong. And when they are wrong, by saving some of our powder, by saying we're doing the smaller prototype early, that allows us to, to then come back, apply energy to the part that really does matter, discover where the sharp end of the wedge is, and then put our efforts into it. So, you know, when I talk to people about you will build this again, the first thing they hear is the, oh no, I'm about to go waste a lot of effort, or I'm just making a prototype, or I'm just making a toy. But in fact, this is a work model that says we're going to build again, and then we're going to keep on building newer and better versions. It's not we're going to build it and then we're going to have to go build it again, but building it in becomes built into the idea of an iterative cycle of development that you're going to the best software houses in the world use in order to create the kinds of products that you are probably using, using today. You can bring that into your own no-code, low-code efforts, and you can do it in a way that, you know, doesn't make it more expensive to build. It just makes it faster. And by making it faster, by saying we're going to take this step, and then we're going to take the next step, we're going to build this part, then we're going to build this part and then stack on top of that, that we're able to make the maximum progress. And so we can say instead of adding despair, we say out of our highest aspirations, because we know this is the path that we're going to use to make great, great products. You will build this again.










