In today’s episode, we’re going to dive straight into some prototyping tips and tricks, what you should do and should not do, and best practices to keep in mind. Of course, we couldn’t have a prototyping episode without our very own, Stephen Meriwether, programmer and director at product development agency, Sprout Labs. Listeners find out about some of the reasons to choose prototyping, from getting a product to market as quickly and cheaply as possible to instant feedback loops, and Stephen also shares some of his favorite no-code/low-code tools to help you get going. Tune in today to hear more from the starting-something saga, where our advice is to just get started!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 184. Prototyping Best Practices with Stephen Meriwether
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.3] DA: Dave Anderson.
[INTERVIEW]
[0:00:11.4] MN: And ladies and gentlemen, I’m ready to prototype. We’re going to dive right into some prototyping tips and tricks, what you should do and should not do, and many other things pertaining to prototyping. We can’t have a prototyping episode without our very own Stephen Meriwether. Stephen, how’s it going?
[0:00:30.3] SM: Hi Dave, hi Bobby.
[0:00:33.3] MN: Yeah, you were here on the last episode to talk about prototyping and you sold me, I had mentioned before, I’m ready to prototype bro. I’m ready to do this.
[0:00:42.6] SM: You’re the prototypical prototyper.
[0:00:46.4] MN: Cooked up right here.
[0:00:47.8] DA: It’s on the business card.
[0:00:49.0] MN: I want to know, just dive right into it, what are some best practices that you know, a person may want to have when thinking about prototyping an application?
[0:00:59.2] SM: Yeah, that’s a good question. I think we have to be super clear with the definition of a prototype. My definition is, it is something that you build to go to production but you intend to get rid of it later. I don’t see prototypes as something that are long living, that sort of stay standing for years and years.
If we have that definition, then, in my mind, the sort of best practices are to do the thing, use the tool, use the technology that lets you get product to market as fast as you can, while not sacrificing on user experience and short term maintainability. There’s a lot of different techniques to do that. My preference is you use no-code/slow-code tools because I’ve sort of, I’m experimenting with those, and I think those are really interesting, but if your team is more familiar with the certain – with like, React, you could throw up – a React developer could make a React site pretty quickly, in just a couple of hours. It could do a lot of interesting things.
I think you reach for prototyping because you want to rapidly test an experiment with your product ideas in the short term. Like Dave mentioned in the first episode, you do the thing that your employees are most comfortable with.
[0:02:30.3] MN: The idea of prototyping is being able to build something as fast as possible, to get it to your users, to experiment how users interact with this product, and it could be a low-code, no-code application, or something built very quickly in React?
[0:02:49.0] SM: Yeah, exactly. I’m working with the client right now who is sort of pre-product market fit. She has very little money, but has this wonderful idea, and wants to go to market as fast as possible and as cheap as possible. We together are working on this no-code solution and we’ve built this no-code web app using Bubble in only a couple of weeks, and we have all sorts of fancy integrations, and all sorts of fancy graphs, and visualizations, and tables.
She is now pitching it to potential users and has a small pilot program going. This is something that there’s no way I could have done by myself, with her, in just a couple of weeks, using traditional technologies. In my mind, that’s an example of a rapid prototype. It’s something that’s going to be around in the short to medium term but will eventually be replaced in the long term once she is post product-market fit, and has revenue, and has the ability to really build something that’s going to last her and her company for years to come.
[0:03:51.8] DA: It’s like something that really doesn’t need a lot of investment upfront? You’re saying it’s just two people working on this application. It’s a very intimate experience.
[0:04:07.3] SM: It is quite intimate, it is not as intimate as, once I was working with the client, and I was working form their home, next to their young children. That was very intimate, this is a little bit different but –
[0:04:21.0] DA: You don’t have to be quite as good of a role model, I guess.
[0:04:23.5] SM: Yes, exactly. I don’t have to – I can wear sweat pants and feel okay about it. In my mind, you know, it’s the thing that gets you moving the fastest. We sort of talked about this a little bit in episode one, there are tradeoffs that you make in order to move faster because, this is especially talking to sort of really early stage companies, their prerogative is getting to product-market fit.
In my mind, one of the tradeoffs that you make and one of the tradeoffs that I have been making is on testing. I am like a big XP person and I enjoy TDD but, in my mind, when you’re prototyping, you sort of don’t do that to the extent that you would working on a more solid, long-term application. But I’m curious, you know, what you all’s thoughts are on that.
[0:05:17.3] MN: I just gasped. Oh my God, you’re out here writing code here that isn’t tested? Who are you?
[0:05:23.9] SM: That’s the great thing, I’m not writing any code, it’s no-code.
[0:05:25.8] DA: Into the pit, okay.
[0:05:27.5] SM: But I’m building software.
[0:05:30.2] MN: That’s like a work a bit, what if I build a – if I was writing this in React as a prototype though? I’m not like spinning up jest on the side, test drive things, are you going willy-nilly because all React?
[0:05:43.7] SM: I’m going willy-nilly. I think that I might get voted off the island right now but I’m going willy-nilly.
[0:05:51.9] MN: Bobby out of the island, out of the TDD island you go.
[0:05:56.4] DA: I mean, I don’t know.
[0:05:58.4] MN: You mentioned Bubble earlier. Does Bubble have a testing framework? I mean, I don’t know how that no-code/low-code programming language tests.
[0:06:06.0] SM: Most of the no-code/low-code tools that I experiment with, I don’t have any sort of testing idea. They usually have some sort of an idea of a compiler. They make sure that your bullions are actually bullions, and your component A talks to component B, but they don’t have any way to test behavior. That’s all done manually right now.
[0:06:28.3] MN: Just like eyes, and clicking on things, and the good old manual testing way of – just like I’m going to put numbers in here when it’s only letters and, okay, that’s good. But you know, test symbols and you got a wise guy user who decides to destroy your app and then you fix it.
[0:06:49.3] DA: The stakes are a little bit lower right? When you're so early on that it’s like no one, literally no one is using this, right? It’s fine.
[0:06:57.5] SM: Literally no one. There are two people working on this product and there are also two people on this planet that know of this product.
[0:07:07.6] MN: I see.
[0:07:07.9] DA: Product-market fit at its finest.
[0:07:10.6] MN: There you go. There’s very little space for testing, for the sake of just trying to get the prototype, like, whether it’s on Figma, or I forget what the name of the app is. Figma is the one where people have been drawing, or [inaudible 0:07:26]? [Inaudible 0:07:29] is one, Sketch. It’s just – prototyping is just getting those thoughts and ideas from those Sketch applications to some other application that’s low-code/no-code or even prototype in React let’s say? As fast as possible.
[0:07:46.4] SM: It’s getting ideas into the real world as fast as possible, in order to validate your thinking behind those ideas. In that circumstance, in my mind, it doesn’t matter if the phone field accepts text, or characters, or something. There’s a variety of different things. It doesn’t matter if it doesn’t work for part of your user base, you're just sort of trying to track engagement and usage and you don’t actually even care if this works at all really.
You just want to see if people are interested in this idea, then you can spend more resources fleshing it out and getting it more resilient, through testing and lots of other –
[0:08:31.7] DA: It’s the idea of a thing that works. I think there is like a fundamental XP idea that is very useful that you’ve mentioned, which is the feedback loop. It’s like getting things out of the way that aren’t getting you the really meaningful feedback, which is from the users, but like, also leveraging the feedback loops that exist within the tooling or what have you.
I know prototyping in React, there’s React dev tools, there’s hot reloading. This already has kind of like, a foot gun for a lot of like more mature React teams where, like, they may not write as robust testing because the feedback loop is so tight with writing the React code where you just like, wait a moment and it comes up.
But I’m sure these no-code tools as well are providing like very nice feedback loops where you can make a change and see it evolving pretty quickly.
[0:09:41.4] SM: Yeah, definitely. I think a lot of no-code tools but even sort of web programming languages. One of the great things about the web is feedback loops are pretty instantaneous. I’ve grown to really appreciate that in my development, but that all being said, you know, I will be honest to say that I run into scenarios where I need to do a lot of manual clicking around and QA testing just because it’s – I don’t want to build software that just doesn’t work at all.
[0:10:14.0] DA: It’s a pride thing.
[0:10:15.0] SM: The reason is that can get a little overwhelming.
[0:10:18.2] DA: Yeah, totally. I think it’s like, you might consider, like, okay, what is the point at which I might add that into the mix? What is the cost and the benefit of having some capability to know and be comfortable about, like, I’m not introducing any regressions?
[0:10:38.0] SM: Yeah, exactly. In my mind, it’s just like, you know, what is my runway? Early on in a product’s history, your runway is just a couple of months at most. I feel pretty confident that I can manage a code base that only a few people are working on or maybe I’m just working on by myself for a month or two. But as that runway starts getting extended, and now I’m confident that I’m going to be working in this code base for the next year, well then, that’s probably a good time for me to realize, “Okay, I can’t manage this on my own without any tests for the next year.”
That’s a good time, I think, just start adding those tests in.
[0:11:22.2] DA: Yeah, I think there’s probably also, like, there may reach some kind of a limit where if you have somebody that’s a complicated logic. If it’s cruddy, you know, a lot of create, read, update, delete, then those cases may be covered by the tooling that you’re using and you can feel pretty cozy with just the out-of-the-box experience with that.
But if you’re starting to do a lot of math, and conditionals, and other things like that, and it’s important for people to – you’re trying to sell to somebody and if it’s not accurate, then they’re not going to buy it. It might be a tool that you want to reach for, like, writing some tests.
[0:12:11.9] SM: Yeah, one of the clearest indicators for me to know that I should be writing a test right now and I’m not is if I can’t figure out the logic of what I’m doing. Then that’s like, “Okay, I’m just going to write a task that has the outcome that I hope to achieve, and I’m going to slowly work my way to that point.”
[0:12:31.2] DA: Right, our simple human brains cannot comprehend the bullion conditionals that are coming together, or what have you. That’s the tool to like break it down into smaller pieces that we can digest.
[0:12:44.6] SM: And I think that applies for, if you are working at NASA or if you’re working at this two person startup. No matter where you are, I think that’s a good technique to use.
[0:12:56.5] DA: Yeah, totally. I would love to get someone who works on NASA on the podcast, although I feel like there are NDAs and things like that, like security clearances.
[0:13:09.2] SM: If NASA wanted me to write code for the shuttle, I would turn that down. I do not trust myself enough to put humans in a –
[0:13:18.9] MN: On a rocket?
[0:13:19.7] SM: On a rocket, yeah. No way.
[0:13:22.8] MN: Nope, nope, nope, not me. Nuh-uh. No way.
[0:13:26.6] DA: The no-code tool.
[0:13:27.8] SM: I am sticking with web forms for the foreseeable future.
[0:13:31.4] MN: Yes, I am not doing it either. I think we’ve had multiple conversations between Dave and I about whether we’re shipping rockets or like pacemaker applications, not doing it. No way, no how.
[0:13:45.6] DA: Right, maybe some code then. Maybe not no-code.
[0:13:49.4] MN: Yeah.
[0:13:50.4] SM: Yeah and then some code, yeah.
[0:13:53.4] MN: Stephen, what is your favorite low-code/no-code tool that you’ve been using? You mention Bubble as one. Do you have any others in your tool belt of low-code/no-code prototyping applications?
[0:14:05.8] SM: Yeah, so I am a huge fan of Bubble. I think it is super powerful. Here at Sprout I am pretty sure we’re spitting up an internal application using Bubble, somewhat non-technical, created an account and had a V1 version of their idea in just a couple of hours. I think that is super representative of the power that Bubble has. Bubble is great for web application. Dave earlier mentioned CRUD apps.
If you are working on a CRUD app, then Bubble is a phenomenal tool for that. Another one of my favorite tool is Webflow. Webflow is really great for marketing sites. It allows you to drag and drop CSS and HTML onto pages and build really beautiful websites without writing any CSS, without writing any HTML. It sort of holds your hand a little bit. I am a really big fan of that too. I am also a fan of this tool called Retool.
Retool is similar to Bubble in that it allows you to build complex work flows in the UI, as you would see in a web app, but it also has interesting connections to – it lets you write code to supplement their built in technology. It lets you connect to all sorts of different databases. Retool is a tool that – I think they pitch themselves as a tool for building. A no-code tool for building internal applications. I think they’re really cool.
Then the last tool that I have some experience with that I really like is the cool tool called Draftbit. Draftbit is for building mobile apps. What they let you do is, through just dragging and dropping UI components, build fairly complex React native mobile apps. You can drag in a photo uploader, or you could drag in this or that component, compile it, and then what you get out of it is React Native code. I’ve used that to build mobile apps.
Those are the tools that I am really comfortable with that I am a big fan of.
[0:16:18.6] DA: That’s pretty cool. Yeah, I am like kind of looking at some of these tools as you are going through it, and I am just having a flashback to like Visual Studio Code.
[0:16:31.0] SM: Say more.
[0:16:32.4] DA: It seems like the spiritual successor for that in such a real way, but like, so much better. It is very hard to make a website that looks good, like aesthetically good, and to have things that are helping you nudge you in the right direction, for how components are laid out, and, you know, how everything looks and feels, that is pretty huge because, you know, I made some really awful things in middle school in Visual Studio Kit.
[0:17:08.8] SM: Me too.
[0:17:10.2] MN: Was that like “what you see is what you get” kind of web development, using Visual Studio Code?
[0:17:16.4] DA: Like Native application development for like Windows.
[0:17:20.6] MN: Oh yeah, I’ve had a lot of fun with that too.
[0:17:22.6] DA: I think it has finally been retired, but it’s heartening to me that there are new tools out there that people can get started with and, you know, as an early stage programmer, someone learning programming, that kind of resonates with me that these tools are available for people to use. I can see some enterprising elementary school person or something like just starting something with this or – Maybe not elementary school but maybe a middle schooler.
[0:18:01.2] SM: Yeah, definitely and I think you are bringing up an interesting point and that I think some of these tools, this newer crop of no-code/low-code tools needs sort of a – they have sort of a brand problem, because no-code has been around for over two decades. I think in the early 2000s people were building software using no-code tools, and the experience was sub-par, to put it nicely, and there’s all sorts of these new crops of tools that the experience is actually quite good.
I don’t know what the brand should be but I would encourage people to try all of these new no-code tools, because you can do some really cool stuff in not much time at all.
[0:18:44.2] MN: It just like being able to, you know, if you have an idea in mind, you can just get started as fast as possible, see what kind of interactions with your users you may get for this particular product, and know, very quickly, this is a product that the world may need versus like, “Oh this is only a niche group of people.”
You can make a decision as to whether you want to continue moving forward, building whether it is going to be a fully fleshed-out application, your React front end and Rails back end and that kind of stuff, versus figuring out a new idea and starting a prototyping process again with a different idea. Rather than diving into a monolith, and building all of this boiler plate, and then having four users, and then not having a lot of interaction, and stuff like that.
[0:19:32.8] DA: Oh no, so sad. My beautiful code is only being used by four people.
[0:19:39.5] MN: Yeah. I mean hey, the four people get to see my code, that’s great. I’ll be happy with that.
[0:19:45.8] SM: If there is four million people, my code will also work great.
[0:19:49.5] MN: There you go. That’s where it’s at. Yeah, fully tested, everything, for sure. Do you think that we – this came up in what, you know, Dave had mentioned with the visual basic knowledge that you had in middle school. I have done a lot of what you call career day and talked about programming and stuff like that, and I am curious, is these no-code applications or something like Bubble a thing that we should be introducing to kids in middle school so that they get more excited about coding? Or am I still – is my Ruby puts your name the thing I should be doing to show the kids? I guess, it’s my question.
[0:20:30.7] SM: Yeah that is an interesting question. I followed this guy named Andrew Wilkinson, who is the CEO and founder of this company called Tiny Capital. They own a lot of different sites, like Dribble, and Meta Lab, and others. I mean he had to tweet the other day that I thought was great, and he said, “Everybody shouldn’t be learning how to code. Everybody should be learning how to use no-code.” I think that’s true, especially as a way to sort of get people into programming.
Getting your mind to thinking about building software and building products using no-code tools I think is a really nice introduction to the more heavier components of building software. If my little cousin came to me and wanted to sort of build something and learn how to program, I would first point them in the direction of Bubble. I would teach them what that looks like, get their mind thinking in that way, and then that translates really well to actually writing software and writing code.
[0:21:39.5] DA: Right as you can think about the joy of creating something. You can think about the feeling that you get when you put some logic together, and connect the dots, and create something surprising or different, but without really writing any code, then that’s pretty good.
[0:22:04.5] SM: Yeah, you get that excitement and that joy of putting something out there in the world, but you also start thinking in sort of a systematic way, that you have to do in these no-code tools, and then you also have to do if you’re writing code. If you haven’t been doing that for a while, it’s sort of challenging to start thinking that way, so this is a really gentle introduction to that.
[0:22:25.8] DA: Yeah, and something that I’ve seen I think also in my career, that we haven’t really talked about too much, that the most successful low-code tool in the world is Microsoft Excel. I cannot tell you how many products I’ve been on where like, “We just need to replace this spreadsheet that Barbara put together.” Like, Barbara put together this wild spreadsheet and it does everything. It is exactly what we need. This is the right product market, fit but it just doesn’t scale.
[0:23:00.1] SM: Yeah, that’s a great example of the first low-code tool that really changed the world in a way.
[0:23:10.5] MN: Oh man, Excel. Who would have thought? Not me. Yeah, I think the idea of prototyping now is very, very interesting to me, right? I think one of the things I myself struggle with is analysis paralysis, is the idea that, “Oh man I want to build something, but what language am I going to do in? I can’t do an Elixir backend. I am going to use Go API. Oh my god, I am going to use React. I’m going to use Vue, or PHP, oh, gosh no.”
I was lost Felty or whatever, what other JavaScript framework that exists, is that going to be my back end, my front end? I think this is just a really good way to let people, myself included, to use an application that just makes it very easy for you to start something. That way, when you start, and then you figure out what you like and what you don’t like, as opposed to being caught up in all of these different programming languages that you do want to build in in. Just so that you know whether this product is something that you want to continue to deliver to whoever is using your application.
[0:24:13.6] SM: Totally. I completely agree with that.
[0:24:16.4] MN: So if you are stuck on an application idea, stop worrying about the programming language you want to do in, and just start, right? Because this is the starting-something saga, and the best way to start something is to start. Programming, the low-code/no-code solutions as Stephen mentioned, Bubble being one of the many, is a great way to get yourself started on that idea you have in your head. So, start something.
[0:24:41.2] SM: Just do it.
[0:24:42.7] MN: Hey, just do it.
[END OF INTERVIEW]
[0:24:44.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole. Never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
Stephen Meriwether on LinkedIn
