Can you imagine a world where you can fast-track your idea, turn it into a feature-filled app, and perfect its development with speed and technical finesse? For Stephen Meriwether, that future is now. As today’s guest, Stephen talks to us about single-page apps, prototyping, and how he uses his skills and experience to help small businesses and entrepreneurs build products. Tune in, and you’ll learn about rapid prototyping, the process behind it, including its virtues and pitfalls. We also get into the nitty-gritty of coding language, touching on Python, Django, Ruby on Rails, and JavaScript, as well as taking a look at no-code and low-code philosophies. Stephen builds on this by sharing his recipe for getting a product in front of his client’s users sooner. You’ll also hear about his experience as a consultant, as Stephen talks about building large React codebases and the reasons why technical debt shouldn’t be something that you need to dread. To find out more about this fresh look at app development, be sure to join us in this episode!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 182. Starting Something New — Do you need a single page app 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.
[0:00:11.4] MN: Today, we’re going to ask, do I need a single page app and what is prototyping, how we’re going to figure out the thing I need to build because we got to start something, right Dave?
[0:00:21.6] DA: We do but I don’t know where to start but we do have a Sherpa to guide us or at least a friend.
[0:00:29.9] MN: Yes.
DA: Friend of the show.
[0:00:32.0] MN: Yeah, today we have Stephen Meriwether, how’s it going Stephen.
[0:00:36.3] SM: Hey Bobby, hey Dave.
[0:00:38.1] MN: What’s going on, tell us a little bit about yourself and where you’ve been at lately in this world of development we’re in.
[0:00:45.1] SM: Sure, I’m a software developer consultant at Stride, I’ve been with Stride for a little over two years now but for the past five or six months, I’ve been helping small businesses and entrepreneurs build products primarily with no-code and low-code tools and so this idea of rapid prototyping — getting something to market before building out a giant code base and a giant test read is something that I’ve been thinking a lot about over the past few months.
[0:01:18.2] DA: Those words are blowing my mind. Whenever I hear no-code and low-code, it just feels like such a far away land from where I find myself often as a consultant where people have established code bases, they have typically React I feel like it’s very common an there’s like some kind of API backend like a Python and Go, JavaScript and yeah.
But you know, there’s a lot of stuff that goes along with that, there’s a lot of stuff that goes along with that, there’s a lot of task on infrastructure, CICB, all that good stuff.
[0:01:57.0] SM: Yeah, you know, I think there’s a place for all of that, it’s – I’m interested to explore with both of you where that place is. I think there’s also a place before you have any customers, before you have really any money to build out your idea into software and then get that in front of people and I think with some of the new tools that exist out there, it allows people to do that quickly and cheaply. That’s what I’ve been doing.
[0:02:31.5] DA: Yeah, I recently within a past couple of months went through a Google design sprint so you know, I did go back and I relistened to our episodes that we did together, episode’s number 152 and 153, the Google design sprint and you, that was like very helpful for me because we were starting from scratch, we didn’t have anything but the thing I struggled with a lot while we were building out this product was like, when do we reach for the big guns, when do we go full single page app and like TUD and like build out all of our beautiful code world.
[0:03:18.4] SM: I’m curious what you ended up doing on this project and what were some of the pitfalls for the choices that you all made?
[0:03:29.9] DA: Yes, I think this has been like kind of a theme in several projects where when you’re starting with a core like something, Ruby on Rails or Django with Python, you have pretty much all the batteries that you might need in there and if you find like a border plate, then there’s even more batteries, there’s so many batteries and within a day, you can have something that looks like a site that somebody might want to use.
That was definitely like a first place that we started at and then we always kept in mind as we’re going on. Okay, do we need a single page app? Every time that there would be the requirement or an ask for like a user feature that okay, is this the time? Do we need it right now?
[0:04:28.1] SM: My opinion is that you hardly ever need a single-page app and I think that's a little controversial, I’m a big fan of serving HTML over the wire via and like a traditional Ruby on Rails or Django sense. I think at least what I found in my experience is building out large React code bases, leads to a lot of technical debt upfront when – especially for really early stage companies, the thing that needs to be happening more than anything is building features and what’s like the absolute fastest way to get feathers out into the market, into the user’s hands to start learning.
I think most developers, myself included, like to reach for the shiny – on day one, I’m going to set up a rails API with a graph QL interchange and that React front end.
[0:05:22.6] MN: That sounds like the app to built right there, let’s go.
[0:05:26.1] DA: Or, other side of the fence, okay, you just need HTML, why don’t you just build Gatsby with a headless CMS and push it all out to the edge?
[0:05:41.9] SM: Yeah, I think that some companies do that very successfully, I’ve never done that myself, I am a fan though of – if we’re trying to spike or prototype on a feature to just starting a blank text file, throw some HTML and CSS in a text file and like, get all the knobs and buttons on the page and using that as an approach to getting software in front of people.
I think I’m really interested in this idea of how do you make sure you're writing the right software, right? I think most developers have fallen into – I’ve worked at places before where they work on a ticket or they work on a series of features and it turns out that they’re not actually being used or it turns out that the actual requirement or the actual need of customers is slightly different and you know, I’ve spent weeks and weeks building out software that is never used.
I think prototyping can come into play there just as much as it can come into play if you have no software and you’re like an entrepreneurial and you want to get something out to market.
[0:06:48.7] DA: Yeah, that’s true, that is like the biggest pain like just like a stabbing pain in my heart of unused software. The feeling that there’s so many lines of codes out there that is just never executed.
[0:07:05.6] SM: Yeah, I’m actually a proponent of not always requiring software to be built inside your big monolith or big mono reaper like whatever. Sometimes it makes sense to just have an app over on to the side that does like one very specific thing that you as a company want to experiment with. Or using some sort of technologies, lets you iterate on that really quickly and so one of the things that I’ve been exploring over the past few months also is, working with larger companies and helping them get product and features to market, outside of their traditional development cycle.
That’s like let’s talk about, what is the goal you’re trying to accomplish and then, how could we do this in a no-code way and like a rapid prototyping way that gets it in front of your customers but doesn’t have to go through the traditional development cycle? I think that’s really interesting and not a lot of companies are exploring that, but I think it’s you know, more and more are and I think it’s a really interesting idea.
[0:08:11.8] DA: Yeah, I guess there’s kind of like that guiding principle of like, what’s the simplest thing that could work?
[0:08:18.0] SM: Yeah.
[0:08:20.1] DA: I mean, if you have those kind of tools at your disposal and they’re a good fit then maybe there’ simplest thing that could work is you know, no code at all.
[0:08:33.8] SM: Yeah, it requires a lot of rigor though, that’s where I at least in my experience, I’ve seen this not work for companies because what you don’t want to do is end up in a place where a year down the road, you have all of these separate apps, using all of these different technologies, doing all of these different things and no one has a clear understanding of what all is involved in the tech stack.
Really, what I tell people and the clients that I work with is we do this rapid prototyping technique to get your features and your idea out into the market, experimenting on it pretty rapidly and then once we see it work, sort of wrap it back into the traditional development cycle. I think that wrapping back in two part isn’t what’s often overlooked because it requires stopping feature where it’s sort of bringing it back and so, one of the downsides of this approach is if you don’t have that sort of rigor then you end up with a lot of technical debt over the long term, which I actually don’t think is such a bad idea. You know I think as software developers, we have come to view technical debt as just this scary thing or is like a negative term. I actually think it is irresponsible for companies at least in the very early stage not to incur technical debt because if you have to technical debt that means you’ve –
There are tradeoffs that you’ve made and so if you are an early stage company, you have to be sacrificing code quality and long term code maintenance and technical debt for sort of short term gains because you know unless you have an unlimited pile of money, you have to make those tradeoffs.
[0:10:21.2] DA: Right, there is little business value in code poetry versus usable features. So you know you got to save all of your good Haikus and things like that for later and just get something on the page that you can validate.
[0:10:46.0] SM: So I have a question for you Dave, when do you think companies should reach for single-page apps or more generally like Graph QL, API’s and sort of these heavier technologies?
[0:10:59.8] DA: Well, that’s an interesting question because I think it depends on the talent and people that you have on hand because if you have people who think in React and people who instinctively know that tech stack, then there may not be a lot of friction in adopting that, right?
[0:11:27.1] SM: Yeah.
[0:11:28.0] DA: So in this particular instance like we did switch from server rendered HTML to React and Graph QL but it was a switch that took maybe like two or three days of work and a couple more days of rebuilding out to the features that we had. The things that we gained from that were that we kept on seeing a lot of reusable components on different places in the page and you can do that with server render under HTML but it is definitely a different mindset and different skill. That I feel like a lot of us had not flexed in a while and we were more comfortable thinking on a paradigm of how React works and so we actually found that when we switched over to React, we sped up quite a bit in development despite overhead of getting there. So it comes down to I think using the tools that you’re most familiar with and you’ll be able to be productive in.
[0:12:36.2] SM: Yeah, I think that aligns really well with how I think about the problem too, which is you do the things that let you move the fastest and sometimes that means that you make tradeoffs and those tradeoffs are okay because you’re moving really fast and that might be because you pick a certain technology that your employees are comfortable with. It might be because you use different tools that let you move things really fast but you move really fast.
[0:13:03.6] MN: I do have a question. Is it ever too late to do the swap? Like you mentioned if you are in doing prototyping. Dave you mentioned that you all eventually switched over to React, Stephen had the question of, when do you think is a good time to do the change. You know at first my initial thought was oh when you realize this is the product you want or whenever it makes money for you, when you see a goal to making money.
But I feel like that may come later or earlier and I don’t know. So I am curious, is there a point in time — Is it when you are building out a prototype like you wait an extra month, right? I supposed Dave your team waited a month after the decision to move to React, would it had taken more time to port the application towards React or do you have to start from scratch or whatever? How difficult is to — when you swap to a single-page app later as opposed to as early as possible is my question? Is there a con to waiting to do the port like what would that be?
[0:14:11.2] SM: Yeah, I would love to hear Dave’s answer to this too but –
[0:14:15.9] DA: Oh no, wait. I am not ready yet. You go first.
[0:14:19.4] SM: Okay. In my opinion, I at least in my career so far, I’ve not found any hard and fast rules that apply to answer that question. I think it is a lot of intuition and it’s a lot of just sort of guessing. I think the problem with switching over too late is that there is just opportunity costs that you are sacrificing. The problem with switching over too early is again, there’s some opportunity cost of either moving too slow or not moving fast enough.
So I am not sure. You know my experience where we have done those type of transitions, it’s sort of been a lengthy team discussion and it just felt right. I’ve heard that a number of times, it just sort of felt right and unfortunately that is not super helpful but that’s where I’m at.
[0:15:12.7] DA: Yeah, I think so well. There is definitely a point on which is like okay like we feel like we’re pushing against the boundaries of the capabilities of the tool or our knowledge of the capabilities of the tools that we’re using and you know we have to figure out how to push past that but there are other things that may lead you in another direction. There are startups that I have worked with where their MVP was emailing a person for them to do the work for you.
So it was all I kind of vary like Wizard of Oz, like man-behind-the-curtain kind of thing and you know, the person who founded the company had some cousins who live back in the motherland and it was like, “Oh, okay an easy way to make a buck,” or whatever and they didn’t cut over from that model for a very long time because it was working. It was really profitable and it feels crazy to say that that would be a thing but you know, if it is working then you can get a roll with it.
[0:16:38.2] SM: Yeah, I think if you look back on the history of successful startups, the most successful startups do that longer than people want to admit or would like to admit. Uber is another great example. That was just a service where you fill out some web form and they call a taxi service for you and they did that for over a year and so I work with a lot of entrepreneurs today who sort of want the entire Uber experience on day one when –
[0:17:11.5] DA: You have to reset their expectations. It’s like yes, the engineering excellence of the Uber organization starting with a web form.
[0:17:22.8] SM: Yeah, so I think like I said, most successful companies start out pretty low fi and low tech and stay there for a long time, primarily driven by the fact that it is cheap and can be successful. So yeah.
[0:17:39.5] MN: Stephen you got me like I am ready to prototype, right? I am not going to jump right into my single-page app. You know I had the thought that I wanted to do a React front end with the Graph QL backend but I am going to pump the brakes.
[0:17:54.8] DA: No but I am going to say you don’t have to feel bad about it. If you got to the point where you got to do it then you just do it. It’s fine.
[0:18:02.7] MN: No but I want to prototype first because Steve’s definitely sold me on the prototype. So in the next episode part two of this starting something to Starting Something Saga as I am going to call it, we’re going to talk about prototyping and prototyping best practices and whether Stephen has been a little trickster and doing TDD while he is prototyping. We’ll get more of that on the next episode.
[END OF INTERVIEW]
[0:18:27.5] 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 and 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:
