In this episode, Tyler helps Rick create a plan to teach himself how to code a web-based application. Rick isn’t sure where to start and asks Tyler for help. Tyler shares best practices he’s learned from teaching more than 15 people how to code from scratch. 

After going back and forth, the following framework emerged for teaching yourself how to code a web-based application:

Takeaways include: 

Rick: Now that we've got PandoLabs steady and GroupCurrent on a good trajectory, I'm starting to turn my attention to how I can finance the development of a minimally viable product, specifically in the business-to-business software application space. One of my constraints at LegUp Ventures is I don't want to give up control of the company as I scale it, so I have to be very cautious about giving up equity early in the company because I need to be able to give up equity later without losing control. In our episode about technical co-founders, I realized the person I need is a full stack developer, and basically that's a unicorn that is going to cost me an arm and a leg in terms of cash and/or equity. So I reflected on that. I talked to some people. I talked to you offline. What I came to was I was a computer science major at Duke, so I'm not some person who doesn't know anything about how a web application works. But from what I learned, the Duke computer science program when I was there, we were doing assembly classes. My eyes were glazed over. The best classes were the programming classes where we actually built something that resulted in something that worked. Facebook was just getting started at the time. The whole idea of building a web application and building a business around it was no part of the curriculum.

Tyler: Well, if I can interject for a second, I think a lot of people who didn't major in computer science don't appreciate the fact that most computer science classes, you don't code at all. You write your answers down on a piece of paper and turn it in. You really don't learn much about software engineering, which is a whole different discipline from computer science.

Rick: Exactly. And the reason I majored in computer science was to learn how to code, but I ended up not learning much about how to code. But I learned a lot of theory and I learned the history of the internet, and some valuable things. And plus I can say I majored in computer science and people think that's cool. But I did learn some things about coding through that major. But there's been 12 years, 13 years since I've coded past HTML and CSS. So there's a huge gap between how I think in my head based on what I learned about how building a web application works, and what the truth is today. There's been significant evolution in the no-code space for example, which allows people who have no ability to code to logically and visually design applications. There are also significant infrastructure automation tools that massively reduce the knowledge you have to have about setting up and running servers, and worrying about security, and all these things that you really had to know back in our day, my day, 2007. So I've decided that I need to learn these things and I don't know where to start. So I think there are a couple of approaches. So why do I want to do this? I want to start there. I am terrified of making a mistake hiring someone to do this and wasting a ton of money. I'm also terrified of bringing the wrong co-founder on because I don't know enough about what I truly need. When you say I need to hire a full stack developer, that's good. That's like a unicorn to me and I feel that's very risky. So through this effort, my main goal is to reduce risk. I don't actually expect my myself to actually learn how to code a full application. I do expect to de-risk bringing on support to build the application.

Tyler: If I can add one other reason to do this, I think it'll make you a better executive overseeing future technical hiring. There's no business in the world that doesn't have some technical component to it anymore. And if you want to run businesses, knowing how to code will help you even if you never write a line of code ever again.

Rick: Totally agree.

Tyler: Cool.

Rick: My problem is not necessarily to learn how to build an application. It's to address my fear of really wasting money in early stage product development. Where do I start?

Tyler: Yeah. Well I think it's good that you have that constraint here because for anyone listening to this episode, it's like how to learn how to code is such a broad topic. We need a constraint. And the constraint here is you're not trying to go get a job as a professional developer. If you were, I'd say you'd probably need a much better theoretical background first of all. And second of all, the technology you use would need to be really focused on what's sexy and trendy right now because that's how you get hired. You don't care about any of that. So it's really how do you build an MVP as quickly as possible, ignoring your learning, and the sustainability of the software long term because someone else is going to come along and rebuild it probably.

Rick: Yup, exactly.

Tyler: Okay, so my background here, I majored in computer science at the exact same time you did and got sounds like the exact same education you did. But then became a professional software engineer after that. And I don't code a ton anymore. I probably maybe put in 10 hours a week at this point, but I think I'm relatively up to speed on how things go. My attitude is that it was much, much easier to ship a working software product 10 years ago than it is now. Let me clarify. You can still do it the way you could 10 years ago, but the technology that's really hot right now is way more complicated and engineering heavy, whereas 10 years ago was kind of the sweet spot where the internet was mature enough that there are lots of really great tools, but it hadn't gotten super complicated yet.

Rick: That seems to go against what I thought was true.

Tyler: Yeah. So let me give you an example here. Basically the quality of web apps has gotten a lot higher in the last 10 years. So I'll take Less Annoying CRM, my company. When we built it, we built it with old school technology. We can dive into the specific tech later. But we built it, it was almost exactly 10 years ago. We started, built it with that technology. And it wasn't great. Every time you did something in the app, it had to reload the page, right? It wasn't really slick. There weren't cool animations going on, but it was what we described in the other episode. It's a CRUD app. Create, read, update, delete. All I could do is put data into a database, get data out of a database, and give the user the information they needed in the moment. That's what most software fundamentally is. But if you use software nowadays, first of all, the page never reloads. Everything is happening. It's more like a desktop application in that things are happening all over the screen. Things are fading in, notifications are coming in, everything is real time. So it's not that building web apps is harder. It's that the expectation of users is a lot higher. And to satisfy those expectations, you need to build a much more complicated tool.

Rick: Is that necessary for MVPs?

Tyler: I don't think it has to be, but I think this is, I know you sort of already have ideas about what you want to build. It depends a lot on what you want to build, and I think you can put constraints around yourself. Say, well you Rick are not going to build for example, a Slack competitor. The user experience matters too much there. You wouldn't want to anyway. But that would be a really difficult technical thing to do. So I would think about what product is going to be an easy one to build without having a really, really polished UX. Do you want to describe at all what you want to build here?

Rick: I have no shortage of ideas on things that could be built. That's not the problem. My goal is not to build something, my goal is to learn how to build something, and build something if I can. Does that make sense?

Tyler: Yeah.

Rick: When you actually started to minimize the UX focus, one of the things that I was thinking was if I could figure out the UX stuff, maybe I could ... one approach is a generalist approach, where I learn a little bit about the full stack, and don't become an expert on any one, and have a solid macro understanding of everything that's going on. And then supplement my macro understanding with experienced contractors in each area.

Tyler: Sure.

Rick: The other approach that I thought about was what if I just said, okay, if you think about everything it takes to get a product off the shelf. There's product/marketing, which includes market research, customer development, that kind of stuff. Then there is design, right? And that gets into the intersection of what does it look like and what does it do, and how does it feel, and actual HTML and CSS, and JavaScript, or whatever language is appropriate. Front-end development is what I'm talking about. And then there's back-end development, which gets into the database and then somewhere there is the infrastructure piece on the other end. I guess one approach is I'm not going to worry about design, I'm just going to focus on making something functional. Another approach is that I'm actually going to worry more about design and less about the functional piece. I don't know which is more valuable for me.

Tyler: Yeah. So I have a suggestion here, which is just to reiterate the areas you said, I'm going to go in the reverse direction. You've got infrastructure, which is keeping your servers running. You got database. I'd say database is a part of back-end, but back-end also involves a server-side language. PHP, Ruby, Python, Node, something like that. And then you've got front-end development, and then you've got design. What I would do is pick a product idea that needs very little front-end development. But that doesn't mean you don't have design. So let me give you an example of this. The product that you and I started working at right out of college, the company was Zane Benefits. You eventually became the CEO of it, but when you weren't, when we were just the new kids there, the product was it let employees of companies go in and get reimbursed for their health insurance basically. Most users logged in what once a month maybe? And if they logged in, it's effectively upload a file, hit save, and leave. All of the work that went on, all the business value that was being provided was happening either in back-end code or in actual literal human services we were doing on the back-end. It did not matter to the users how slick the front-end code was. Was the page reloading when you submitted the form or did it do it in the background without reloading the page? That is, in my opinion, the vast majority of the complexity that's been added over the last 10 years is in that front-end code area. You can even have a great design. But as long as it's the interactions and the real time stuff, as long as that doesn't need to be real complicated, as was the case at Zane Benefits, I think that'll be the easiest thing for you to tackle an MVP of.

Rick: So you're saying avoid trying to become an expert on the new age design technologies and front-end technologies, and instead focus on learning how to basically make logic work with a database?

Tyler: Yeah, more back-end heavy. And whatever front-end stuff you do, how it looks is fine. But you don't want really heavy, really complex interactions.

Rick: Why? Why are you suggesting this?

Tyler: It's just a lot harder to code. So I'll give you an example. Less Annoying CRM started with that old technology. As we've gotten more advanced and more polished, we switched to this newer technology called React, which I find to be very complicated. The joke I've heard is that it's 10 times more effort to build for a 20% better experience. You never see the page reload, everything happens instantly. But I build a CRM. People are in that all day, every day. Little tight, shaving milliseconds off of an interaction, make it a lot better for the user. There are so many applications out there where, a nice thing to say is could this be something that people log into no more than once a week? If you can do that, it's almost a guarantee having really, really complex, sophisticated user interactions is not going to be a part of that experience. You know what I mean?

Rick: I think you may be right, but there's something bothering me about the approach of just focusing on the back-end. I guess where I get a little nervous about... so one constraint I have is I'm starting this now and on December 31st I will end the project. Okay? I'm time-bound on how much I'm going to spend on this. My goal is first to clarify my own capabilities, it's like 50% of the goal is just where does my ability stop and begin. And then second is if I can build some application that's billable. The one concern I have with approaching it from the back-end side is I don't know that I'm going to be good enough at the end of it to truly, from an MVP standpoint, remove a layer from the stack of the person I need to hire. Do you understand what I'm saying?

Tyler: I understand what you're saying. I want to clarify my point though. It's not that you're focusing on the back-end. There's all the back-end stuff, and people can't see me. But my right hand is saying back hand, and on the left and you have design. And then you have front-end engineering between the two. I'm not saying you don't focus on UX and UI design, and having a great user interface. I'm saying that the technical complexity of the front-end is what you pull out of there. Just because it's the hardest thing to, it's in my opinion, by far the most complex and difficult thing to code these days.

Rick: Interesting.

Tyler: I think you can go in and build a simple CRUD app with even relatively sophisticated back-end capabilities. It's like yeah, anything's hard, it's hard. But you could learn that in three or four months, no problem.

Rick: And then maybe the person I bring on is a front-end expert versus a full stack developer.

Tyler: Potentially. And a lot of businesses are made without ever having this person. Like once again, Zane Benefits never needed it. And I don't know if they have it now, it's PeopleKeep now ... they still probably don't need this to be a successful business.

Rick: That's helpful. That's interesting. Okay. I'm bought into this. You're basically taking a more generalist approach to build an app that's functional so you understand everything across the stack and focus on something that won't require significant front-end complexity. Because if it does, it's going to slow my ability to get the full thing done.

Tyler: Exactly.

Rick: What's the best way to learn this stuff? Is it to go be an apprentice? I talked to one guy the other day, he's a member of PandoLabs, and he's building a software shop up in Deer Valley, or Park City. And he was like the ex-chief engineer at Booz Allen. So he's super smart and interesting. And one thing I talked about him was maybe I can intern. My dad when he was little really wanted to learn about automobile mechanics. So he interned as a mechanic for basically free to learn how to work on a car. And it resulted in a garage filled with cars that didn't work when I was in college. But it was always fun to tinker with them.

Tyler: Isn't your dad a lawyer or something?

Rick: Yeah, he's a lawyer. This was something he was really passionate about and interested in learning, but he probably was never going to be a full time mechanic. As a result, you walk into our garage and you see two engines out of a car. And that's a project from five years ago that hasn't quite been completed. But it will be completed at some point, you know? But I guess that's what I'm trying to get to is do I go apprentice here, do I take online classes? Do I learn by theory, or do I learn by building components? Or do I just say, "Hey, I'm going to go build something and I'm not going to stop until it's done."

Tyler: Okay, yeah. So I'd say A, you absolutely have to be building something, whether it's working, doing an apprenticeship, or working on your own project. I don't think purely studying theory makes any sense. It just doesn't work. And the second thing say is, because I've taught my fair share number number of people how to code at this point. Three of our full time software engineers here didn't know how to code when they started working here. I'll say the biggest thing that kind of levels you up a lot faster that you might not otherwise get is being able to get code reviews from an experienced programmer. So this doesn't necessarily mean a tremendous amount of mentorship. But basically when you write code, someone just looking over it, they could immediately just be like, "This thing you did here, it works. But that's not the right way to do it." And you're going to learn so much from those comments. And it actually doesn't take that much of the other person's time to do it.

Rick: Interesting. So one maybe accelerator is having some sort of mentor that is willing to basically grade my code on some semi-regular basis and get feedback from that?

Tyler: Yeah.

Rick: Where do I start? So tomorrow, let's just say after Labor Day, I'm going to start building a simple CRUD app that I have no idea what it is, but I'll figure that out. Where do I start?

Tyler: So I'll tell you what I've had success with in the past with people. So first of all, there's a ton of different technologies you're going to have to learn. I think one misconception here, I know you don't feel this way, but some people do is that you learn one programming language, and you just write code, and that's it. There are at least five languages that are going to go into this, and there's database, infrastructure, back-end, front-end. So you need to pick these one at a time. What I recommend doing is you start with just HTML and CSS. I know you already have some experience with that stuff, but these are the pieces that you can make something that visually looks like any website you've ever seen with just these two things. Right? So what I've recommended for people before is take a website that's not too sophisticated. Hacker News is one I've used before. It's a really simple looking site. And just clone it. Don't look at any of the source code. You can if you want to, but just make your own HTML file with CSS that looks exactly like Hacker News or some other really simple site. Probably for most people that only takes a few days to get pretty comfortable with those two technologies. I'd say that's the easiest part. And you already know HTML and CSS reasonably well, right?

Rick: Define reasonably well.

Tyler: I mean like you know there are tags. You know what CSS does and what HTML does. And even if you don't, you can Google this and read about it.

Rick: I'm good on HTML and CSS. I guess the one thing I'm interested in there is with the no-code movement, it seems like a lot of HTML and CSS can be produced visually, in a responsive way, and then imported into the application. How do you take that into account with this project?

Tyler: You could do that. Honestly, it's so easy to learn. I don't think you save much time. I think it might be harder to learn a no-code tool than it would be to just learn to code. It's really simple. And I've taught now 15 people because every summer we bring people in and teach them to code. Some have been really, really strong, some have really struggled. Nobody has struggled with HTML and CSS.

Rick: Okay, got it. So first I'm building the HTML and CSS and cloning some simple front-end app out there that I can take a look at. What's next?

Tyler: So then what I would suggest is pick a simple app to build that probably isn't the one you actually want to build. This should be a throwaway app. The one I always recommend as a blogging tool because a blog is just a perfect abstraction of coding concepts. You put data in, you get it out. You have a list of blog posts. It's all the basic concepts are in a blog. So that's what I normally suggest people start with. So you code the blog in just HTML and CSS. You make a few blog posts, a homepage that links to everything. It's all totally static. There's nothing dynamic or database driven about it. And then, bit by bit you pull it off and move it into the back-end and make it dynamic. Which basically means instead of having three HTML files, one for each blog post. You say, "I'm going to make one in my case PHP file, which is the back-end language that pulls whichever posts I'm trying to look at from the database." So bit by bit, you can just take this, what starts as a totally static site. And make it more and more dynamic over time until eventually you've got a full blown blogging platform.

Rick: You totally lost me.

Tyler: Okay, sorry.

Rick: Okay. So I have a static [site] with three pages, three or four pages. A homepage that lists all the blogs, and then three blogs. And then a CSS file that styles everything. And then you said do something with a PHP file?

Tyler: Yeah. So, sorry, let me go into more detail here. The way a dynamic website works, and by dynamic, what I mean is the user is seeing something that you did not necessarily hard code in there. If you go on to Facebook, you'll see a different newsfeed than I will if I go into Facebook. That's dynamic, which means it's coming from a database. A blog or pretty much every website, it's not going to have a separate webpage for every post you can look at. It's going to have one page that's view post or something like that. And then you can specify which posts you want to see. So you could say viewpost.PHP?BlogpostID=1, or BlogpostID=2. You've seen these in URLs before. Those are called URL parameters. You know what I'm talking about?

Rick: Yep.

Tyler: Okay. So what happens is the URL parameter tells your code which blog post you're trying to look at, and then it goes to the database and says, give me just that one post. And it generates the HTML on the fly and sends that to the browser. So you just have one file that can serve every single blog post that you write.

Rick: And does that file actually create the HTML?

Tyler: Yes.

Rick: Got it. So in other words, instead of having to manually code each blog page individually, I create a new thing called a PHP file. What do you call this generally without saying PHP? A dynamic file?

Tyler: It would be whatever your server-side coding language is. So PHP, or Python, or Ruby, one of those things.

Rick: Okay. So we create some sort of server-side file that says, "Hey, you don't have to code these anymore. We're going to take some inputs from the database. And then we're going to create an actual HTML file based on those for each blog post that is populated based on inputs.

Tyler: Yup.

Rick: I got it.

Tyler: Just to clarify some of this, the only thing web browsers can run is HTML, CSS, and JavaScript. That's it. So you use some kind of server-side coding language. No matter what you use, all it does is it generates HTML, and then that gets sent to the browser.

Rick: Got it. Okay.

Tyler: And then what's nice about this, so now you can read any blog post from that one file. And what this means is in order to make new blog posts, you don't have to code anything. You just put new data into the database. So what's the next step? You make a form that says here's the title of the blog post, here's the body of it. Whatever other SEO stuff. Whatever you want, you save the form and that puts it in the database. And then boom, you've got a new blog post published on your website.

Rick: Got it. Okay. And then what?

Tyler: Well, so let's go back to the term CRUD. Create, read, update, delete. So far, read was the first step. Read blog posts from the database. Create was inserting a new blog post. So let's do the other two. Let's make an update one. So we can take all our blog posts and some admin section and say, "I want to edit this blog post." So you pull the data from the database, display it in a form, let yourself edit it, save it, and that saves it back into the database.

Rick: So basically walk through the acronym CRUD. I got it. Once I'm through the CRUD stuff on this throwaway app, what do I do next?

Tyler: So I think you could gauge for yourself at that point how comfortable you are at stuff. You could potentially build your full app with just those skills. 80% of software in the world is just that.

Rick: So one thing I want to do is I want this MVP to be billable. What is required outside of CRUD to set up the ability to charge customers money? That's really important to me.

Tyler: Okay. So first let me push back a little. You need to be able to charge people, the software does not necessarily have to. So you could create a Stripe account and just manually invoice people. And you can even set up recurring payments and all that in Stripe without having any code written if you want. Is that of interest to you?

Rick: Yes, but not for purposes of this project. I'd like to challenge myself to code that.

Tyler: Okay. So back in the day, this was really, really complicated. Now, I would recommend Stripe, but I think they have competitors that are similar now. You know what an API is, right?

Rick: Application programming interface.

Tyler: Yes. It's a way for one program to interact with another program. Right? So the company Stripe is really good at processing payments. They have an API. So if you want to charge somebody, you just call their API functions. So you write code on your server that says, "Here's this user, here's how much I want them to pay. Go charge them." So there's still code writing involved, but Stripe makes it pretty easy.

Rick: They actually make it a CRUD interface. It's all create, read, update, delete, but just via their API.

Tyler: Right. And there's all kinds of complexity behind the scenes, like we have to contact the merchant account and this and that.

Rick: I don't have to worry about that.

Tyler: Yeah, exactly.

Rick: Okay, cool. So through APIs, I can expand my CRUD app without actually having to learn the complexity outside of CRUD?

Tyler: Yup. When you talk about the no-code movement, my understanding, what that means is basically you've got all these different tools that exist that you don't have to code them up yourself, and they connect to each other with APIs. So you can either be pure no-code, like some people build companies without ever writing a line of code. But even better, I think is that you write a little bit of code and then you can say, "Okay, I'm going to pull someone's events down from Google calendar. And then I'm going to do something to them, and then I'm going to push them into whatever other app. And boom, now I can charge money for that."

Rick: This is really helpful. You talked about CRUD in our last episode. I'm starting to realize that that is the curriculum. Create, read, update, delete. How does your curriculum differ for your new hires and software interns from what you're telling me right now?

Tyler: So we literally do the blog example exactly as I just said it. And then at that point, I sit down with each of them. They're all college students. So in addition to mentoring them on technical stuff, I'm mentoring them just on how to work at a company and stuff like that. But I'll say, "What do you want to build this summer?" And then we just start on it, right? Once they've built the blog, they have all the core skills. The only final missing piece is JavaScript. So let me talk about that for a second. Any website that has any interactivity to it, meaning something changes on the website without reloading the page. It's always JavaScript. So if you think back in the day, like in the 90s, a webpage was text, links, and forms, and nothing else, right? Or images maybe. But the only way to make the webpage change was to click a link, or submit a form, and the whole thing reloaded, right? Nowadays when you use a webpage, stuff's changing all over the place. Chat messages are coming in, notifications are coming in. Anything that changes without reloading the whole page is happening in JavaScript. That's the only programming language that web browsers are capable of running.

Rick: Where does React, that concept you talked about earlier fit in?

Tyler: Yeah, so I said 10 years ago is easier to do this, right? 10 years ago, JavaScript was pervasive. Everyone knew JavaScript. But it was pretty simple still. Nowadays, this extra complexity I'm talking about is JavaScript is not a programming language that was really intended to build web apps. It's just a normal programming language that kind of got co-opted for the web. There's all these frameworks, React being one of them. Vue, Angular, Ember. All of these things came out to make it possible to make really, really sophisticated apps with JavaScript that don't feel like web apps. They feel like native desktop apps.

Rick: They basically inject JavaScript with steroids?

Tyler: Yeah. If you're building a really complicated app, it's easier to do it with React. But if you're building a simple app, you'd be better off not using it at all because it's like overkill. It's like using Salesforce as your CRM. If you have really complex needs, absolutely go use it. If you're a one person business that just needs a contact list, it would be incredibly complex to use Salesforce for that.

Rick: Okay. So JavaScript is another thing. Is there anything else about your curriculum that you'd add to this?

Tyler: No. So after that point, it becomes very personalized. So it depends on what each of, some people use APIs, some people don't. It just depends on what they need.

Rick: Okay. So I want to back up. Before I start, I know how to build an HTML website. In fact, I could use Squarespace for this and just hard code the HTML in CSS without using their model. I can also go to GoDaddy and just upload HTML files and CSS files, and work that way. When it comes to the database part, where do you start in terms of setting up a database and actually doing the create part?

Tyler: Yeah. We're getting to the infrastructure side of things. So you can make HTML, CSS, and JavaScript. You can write that on your computer, just open it in a web browser and it'll work. You'll have a working website. As soon as you introduce your server-side language. PHP, Ruby, Python, whatever. Database, either of those two things, you need a server, right? The normal model here is you're going to have a local server running on your machine, and then you're also going to have a production server out on the internet that anyone can access. So you write code on your machine, you run it on your local server. And then once it's ready, you deploy it to the live one.

Rick: Lost me again.

Tyler: Okay. Where?

Rick: When you started talking about servers.

Tyler: Yeah. Okay. So you should think of a server like this. We said earlier that any server-side code is really just generating HTML so that your browser can open it. So effectively, what happens is when you make a web request to any website, you go to like www.whatever.com. That request is going to the server. The server is going to execute whatever their server-side languages. Once again, PHP, Ruby, Python, Node. That's going to generate HTML and send it back to your browser.

Rick: I got that.

Tyler: So in order to develop this, you need a local one of those on your computer that basically can take fake web requests. They never go out on the internet. It's like your version of chrome or whatever you use on your computer is saying to the server, "Hey, I want to load this file. Can you run the code that I wrote and send me back the HTML." It's also what's going to host the database. You should just think of a database as an Excel file more or less. But each row has a unique id and you can say save something to the row with this unique id, pull that unique id out, and give me the data.

Rick: So if I want to go build a database on the internet, where do I go?

Tyler: Yeah. So you're going to need some kind of hosting provider. If you're building a robust, sophisticated web app, that's probably going to be Amazon Web Services or Microsoft Azure, or Google, whatever they call their thing.

Rick: Should I do AWS?

Tyler: Well, I wouldn't do that personally.

Rick: Why not?

Tyler: So I'll admit infrastructure is my weakest point. So you're not talking to an expert here. But AWS, it's back to the Salesforce analogy. Really, really robust. It's not easier by any means. It's probably quite a bit more complex than how web hosting works 10 years ago.

Rick: Okay.

Tyler: Eventually, you're going to want to be on it. But for this project, I wouldn't do that.

Rick: Where would you go then?

Tyler: Yeah, so there's a few options. Heroku, I've heard a lot of bad things about it. But I think basically it's an abstraction layer on top of Amazon Web Services more or less, or something like Amazon Web Services that makes it easier to do ... they're basically like if you need the normal setup, they just do it for you and it's a lot easier. So that's one option. Or you said earlier, go to GoDaddy, or I've used Namecheap, which is the same thing as GoDaddy. There's a million commodity hosts out there. I'll say it kind of depends on what language you're going to use. I use PHP, which there are plenty of reasons not to use it. But every single web host on the planet supports PHP. So you go to any of them, set up a $10 a month account. It's actually easier to use than Amazon Web Services.

Rick: Okay. All right. So I got to set up a server, whether I use Heroku or whatever. AWS, GoDaddy, that allows me to upload the files, that hosts all this stuff.

Tyler: Yeah. Can I give a little caveat here?

Rick: Yes.

Tyler: So it's possible to build a software with no back-end at all, in which case your hosting gets way, way easier because you don't need a database or anything else. And the way that works is you're effectively using other people's APIs for everything. You're not storing anything in your actual server.

Rick: Okay. How do I do that?

Tyler: Well, the use cases for that are pretty limited. I personally wouldn't want to build a company that has absolutely no data. But if you want to, I'll just say some names so you can Google it if you want. Netlify is one really good way to host that. Way, way easier to do the hosting. But the problem is you don't have a database, you don't have a server-side coding language or anything like that. And then I would say probably use something like Google Firebase which is effectively a database that they host that you can connect to so you can send data to them and get it back without actually having your own database. So it is possible.

Rick: Cool.

Tyler: I wouldn't recommend it

Rick: You wouldn't recommend it? Well we won't go into that today. So, okay. I think I'm ready for takeaways. Would you add anything else before we go there?

Tyler: Okay. So, why don't we do the takeaways and I'll find out by the end of that if I have anything else?

Rick: Cool. So one of my takeaways is there's a bird’s-eye view that I don't quite have yet, and I need to do some generalist research to be able to visualize in my head all the components out there in order to build a CRUD app. We've kind of simplified it into design, front-end, back-end infrastructure. But there's a layer down that I need to go that actually connects those so I can see all the pieces to the puzzle. Then it's basically working through building an application, starting with a static HTML version of what it would look like, and doing everything manually. And then working through the C-R-U-D of CRUD. Create, read, update, delete one at a time, until I have a fully functioning web application. In order to do that, I'm going to need to set up the infrastructure to support it. You mentioned a number of different ways to do that. So I guess it's first general approach. Second, set up the infrastructure. Third, static. Fourth, create. Five, update. Six, read. No. Create, read, update, delete, in that order. And then it's polish on top of that with either improvements to the UI, or even adding an API to add more functionality.

Tyler: Yeah, let me just editorialize a little bit. I think that's a good summary of everything. One thing I should've mentioned, for hosting, you can develop this locally and not worry about a host until it's done if you want. It's a lot easier to get working on your local computer. So that's a good place to start is to pick your languages. That's going to be one of the hardest things here. What is your server-side language going to be? What is your database going to be? Database is easier. But with database, you're either picking MySQL or PostgreSQL probably. With server-side languages, you're probably picking Node.js, PHP, Ruby, Python, those are the big ones. Once you have that though, you can just get a local environment on your computer and start going, and worry about hosting it on the internet later.

Rick: Okay. Where do you get this local hosting stuff? Does that come on your computer?

Tyler: Yeah, it depends on what language you use. So I use, once again, PHP. If you just googled Wamp, W-A-M-P. That stands for, you're a Windows user, right?

Rick: Yes.

Tyler: That's Windows, Apache, MySQL, PHP. Those are all the technologies you need. There's the same thing MAMP if you're on a Mac. But if you choose to use Ruby, I'm sure there's something similar to that, but I don't have experience with that.

Rick: Got it. So there's basically local setups that you can go find online by googling that a to run this all on your local computer?

Tyler: Yeah, exactly.

Rick: I got it.

Tyler: And then a final thing I'll just say is get into GitHub. When you're writing code, get in the habit of checking all your code into GitHub so that it's backed up.

Rick: What is GitHub?

Tyler: GitHub is a, so Git is a version control system. Which basically means every time you change your code, you want to log of all your old code so that if you introduce a bog or whatever, you can roll it back. GitHub is an online host of Git repositories. So you just push your code up to GitHub, and you've got a repository. You've got an online record of everything you've ever written. You can share it with other people. That's how you do code reviews is you say, "Hey, here's a link to this chunk of code. Can you please review it and let me know what you think?"

Rick: That's helpful. I've got it, man. Well, I'm interested to see how this goes. I don't know. The other thing I left out was just I need to find some people that can be a support group to me and mentor some of my mistakes out of me.

Tyler: Yeah. I have no doubt you'll be able to find that somewhat easily. But I think a big thing is what technologies are you going to pick? For example, if it's PHP, MySQL, React, I'm happy to help personally. If you go with Ruby on Rails, I'm not going to be much help for you.

Rick: That makes total sense. Macro understanding comes first. Second is picking the languages, and third is starting to work on it, and then while finding someone who can troubleshoot with you, or mentor you. I got it. Cool. We'll, let's wrap up. Everyone, thanks for listening. You can join the conversation on this topic, and review past topics by visiting our website, startuptolast.com. We'd love to hear your thoughts and ideas. We really want to engage with our listeners. We're not so concerned with adding a bunch of listeners right now. We're really concerned with finding out who out there is listening, and who is interested in what we're saying. And whether it's positive feedback or negative feedback, we want to hear it so we can improve. Reach out to by whatever medium you see fit. Twitter, we're both on Twitter. We have a website, you can reach out to us there. We just want to hear from you. So with that, we'll see you next week.