DonTheDeveloper Podcast
DonTheDeveloper Podcast
Every Junior Developer Needs a Capstone Project
In this, I break down why every junior developer needs a capstone project that goes beyond simple tutorial or clone apps. I share why code-along and copycat projects may reinforce your skills, but ultimately fall short in showcasing true problem-solving ability. Instead, I explain how to create a meaningful project built around something you genuinely care about—one that solves real problems, targets real users, and demonstrates practical, hirable skills.
I discuss how capstones teach user-centered thinking, why it’s essential to iterate over months (not days), and how to utilize feedback. You’ll hear tips on brainstorming ideas from your previous industry experience or personal passions, plus the importance of picking a marketable tech stack and sticking with it long enough to master it. While freelance projects, open-source contributions, and smaller practice apps have their place, your capstone is the real game-changer that can set you apart from hundreds of other junior developers.
If you’re tired of being “just a code monkey” and ready to show you can tackle actual product development, user feedback loops, and innovative features, this one is for you. Whether you’re aiming for a product-based company or even planning to monetize your own application, a well-executed capstone project proves you’ve got what it takes. Let’s move beyond surface-level projects and create a robust portfolio piece that tells the world, "I’m serious about software development."
---------------------------------------------------
🔥 Webdev Career Help - https://calendly.com/donthedeveloper/coaching
🎮 Join Discord - https://discord.gg/TpQe2k8Ab3
❤️ Support What I Do - https://www.patreon.com/donthedeveloper
Disclaimer: Some product links are affiliate links which means if you buy something I'll receive a small commission at no extra cost to you.
===========================
WEBDEV COURSES I HIGHLY RECOMMEND:
🎓 Learn Frontend - Scrimba (20% off): https://scrimba.com/the-frontend-developer-career-path-c0j?via=donthedeveloper
🎓 Learn Backend - Boot.dev (25% off): https://boot.dev/?promo=DONTHEDEVELOPER - Get 25% off your first payment with code "DONTHEDEVELOPER"
🎓 Already Experienced? Level Up Here - Code Crafters (40% off): https://app.codecrafters.io/join?via=donthedeveloper
Every junior developer trying to break into the industry right now needs a capstone project. I'm not talking about just putting your top projects on your portfolio and maybe listing what you think is your best project as a top project. I'm talking about a project that you actually care about, a project that you have worked on for months, a project that you actually care about, a project that you have worked on for months, a project that you have thought through and that is practical. It's valuable. You're trying to actually create something that gives value enough for people to use it. It's something that can showcase that you could build stuff for the world with the skills that you're learning and be hireable and be paid for it. Now I'm going to go into detail of what that looks like and what it's definitely not, but a lot of junior developers you guys have a lot of variety of projects. A variety of, especially smaller projects are really good for reinforcing concepts. You're solving a bunch of different problems to work through different implementations, maybe libraries you're picking up, languages you're picking up and it's really good for just reinforcing a lot of the implementations that you're learning and using them in a slightly different context. It really helps solidify it. It does. Variety is good for learning, but depth, serious depth in a capstone project is where you finally start tapping into solving real complex problems and I don't see enough of that. So before I go into essentially what a capstone project is and flush that out in a little bit more detail, I want to go over some misconceptions. There are projects that junior developers will kind of prop up on their portfolio that aren't as valuable as they think they are to employers. So, for example, like we'll just start out with code along projects, code along projects, code along projects are just projects you are building throughout whatever course you're going through to learn the concepts that you need to. You know essentially build full fledged applications, websites, whatever you're trying to build. But these projects can help reinforce the concepts that you're learning in a practical manner and I think they make courses fun and I think they make courses practical, useful. Good, they help reinforce those concepts, but they don't really showcase your skill at all. Right, these tutorial-based projects employers really don't know how much time you spent on your own, critically thinking, problem solving on your own, without the dependency of that tutorial and them kind of walking you through it. They're probably some of the lowest value projects you can have in your portfolio, but there's also clone projects which are really effective at reinforcing concepts. So I say this a lot with CSS A lot of people struggle with CSS for a while until they don't and then they start to enjoy it.
Don Hansen:But cloning a website and building it locally can help, especially building the layout. If you're trying to aim for front-end, you're trying to get better with CSS, building out that layout, writing good semantic HTML and styling it properly to look like the website and making it responsive. And even if they don't have a mobile version, that, uh, looks great. You can kind of come up with your own mobile version, just experimenting with, like building a full-fledged website, not having to come up with a design on your own whatsoever. Um, it can just help reinforce concepts and you could use this clone model to also reinforce. Like you know, as a front end developer, if you were trying to get better with JavaScript, you're trying to build interactivity with a website, like building a clone that has some of the functionality that maybe Spotify you really like Spotify. Cloning some of the basic functionality of that, at least on the front end, and if you're kind of learning backend as well, building that on the backend can help reinforce the concepts that you're trying to learn. It's really good for reinforcing. But you don't really have the rights for any of this copyrighted material. You keep it local, you don't put it on your portfolio. But also like a clone, you're not really thinking through any problems. You're kind of just mimicking how these features work, which will help reinforce, because you're thinking about how to apply the concepts that you're learning and you are mimicking features that have already been thought out. You don't really have to think about the user at all. You don't have to think about the drawbacks to this feature, not really doing any critical thinking. You are just kind of turning your mind off and just focusing on applying the concepts that you just learned, to build out these features that you didn't have to really think of.
Don Hansen:Clone projects are really good for reinforcement. They're not good for portfolio projects and then open-ended tutorial projects. Essentially, these are projects where courses will encourage you to. They'll tell you what to build, but they won't tell you how to build it, so the implementation is up to you entirely usually. But they still have this kind of defined type of app that you're supposed to build and it's usually curated to reinforce the concepts that you've just learned. The idea was well thought of for that purpose, but you're not really being creative. You're not really going out identifying problems that need to be solved through technology, through code, and you're not really building any solutions that could provide real value to people. You are just essentially building a templated project where you get creativity with the implementation but not the idea. And this templated project is on you know hundreds of other people's portfolios as well. There's nothing unique about it. It doesn't say anything unique about you or the types of problems you want to solve, so it's still a low value project.
Don Hansen:And then sometimes people go for open source projects because they hear oh, contribute to open source, that's going to help me break into the industry. Well, it's another misconception. I think if you're using a developer tool, if you're using even just a web-based app, that is open source. If you are using that frequently and you like it and you kind of maybe even like the missions of the contributors, the authors, whoever created it, whoever's trying to run it, whoever's trying to solve a certain problem in the industry, if you believe in what they're doing and you want to give back and you want to spend a significant amount of time contributing to open source and getting to know their policies and their way of doing things and build relationships with other people that also care about that app and you just slowly ramp up the issues that you solve and start solving more complex issues that come about. That is an awesome reason to get to open source. That is an awesome. Those are great open source contributions that can look really good when you're trying to break into the industry.
Don Hansen:But often people are just trying to use that as a checkbox where, oh, I make one contribution, very minor. I put it on my resume I am a contributor to this project. You're full of shit is what you are. That's not a good reason. To check off. That box of open source is not a good reason to get into open source. It's not a good reason to make contributions and I promise you it's not going to provide you any value and sway any opinions in a positive manner towards hiring managers. So a lot of people get into open source for the wrong reasons. So stop, just stop that. Please just stop that. That's a huge misconception.
Don Hansen:And then the last one, before we get into the capstone, is freelance. A lot of people here and I've given this advice myself with extra context, but I've given this advice to other people where they were kind of stuck building tutorial based projects or they didn't know what to build and I'm like, well, you know, what you could do is build something practical, doesn't have to be complex, just like go in your local community and look or look up local businesses in your community. Do their websites suck? Do they have any? A lot of businesses just have a social media presence but no website right, and they're missing out on organic traffic that could come from search engines. So you can go to local businesses and you can kind of build a landing page for businesses or something basic or something even a bit more complex.
Don Hansen:But often, very often, especially when you don't have experience in the industry, especially when you don't have a fleshed out portfolio, you are not going to get the trust of clients that are going to pay a lot of money or what complex projects built. You don't have that trust because you don't have that reputation built up as a freelance developer. Yet when you get that reputation built up, especially over years, that's when you start getting a lot of the more complex projects and trust and big contracts. And that's its own headache, by the way, but you need to build up to that. So even just introducing a couple of freelance projects on your portfolio, it shows initiative but it doesn't really show depth of knowledge. A lot of people getting into freelance are building very surface level things and that, quite frankly, can just be built with WordPress or a site builder. So you know, if you're building it with your stack, who gives a shit, you're not really solving any important problems. So that's the problem with freelance.
Don Hansen:If you want to dip into agency work professionally, you might consider working with clients and going that route. They are going to value that much more than a product-based position where you're going to be like most people. When they break into the industry, become software engineers, they're usually kind of working on a product and that product is iterated on over and over and over and over and that's what you're doing. That's your day-to-day, potentially for years. Right, and there could be different products launched, different apps that you're going to be working on, but essentially it's internal. Well, you're going to be working on apps of the company that might be facing outward and might have users, or it might be like a business to business model, but still like an actual product, think of like a SaaS product. That's typically what you're going to be aiming for for a lot of open debt positions when you're breaking into the industry initially when you're breaking into the industry initially. So agency route and going the freelance route could be an option.
Don Hansen:But even if you consider building your skills up and going into depth to really be hireable for product-based roles, that will carry over into other types of contract and agency work as well, into other types of contract and agency work as well. So the goal is to really focus on a capstone project, a single project. You could build other projects on the side, but there should be one project that you never stop working on. You always come back to, you always iterate when you get user feedback, when you get new ideas to make it even better for the people that use it, and we'll talk about that in a bit. But the capstone project is your project. That really solidifies a lot of what you're learning, a lot of the concepts that you're learning, and it shows that depth of knowledge. It shows employers that depth of knowledge. It creates more interesting conversation in the interview. It looks professional but it creates a lot of interesting conversation in the interview, especially product-based positions, because you're going to go over, like, if you get users, like real users, using your app, which is what you should aim for, that's awesome.
Don Hansen:Why the hell did you decide to build it? That's an interesting question that comes up. Why did you decide to flesh out these features? Okay, now let's dive into the implementation. Why did you decide to implement it this way? What do you think is going to happen if, right now, you have what? 50 users? What happens when you have 10,000? Do you see where this implementation breaks down?
Don Hansen:These are interesting conversations that are going to come up in an interview you might be challenged with and some of you might not have thought about some of these, but they're still good questions to think about and eventually come up with answers for. But these are questions that come up with important projects, valuable projects, capstone projects. That's where the interesting conversation comes up, where employers can start digging into this project, your implementations, your decisions, your care or non-care for the users that are using your app, your process for iterating. Now the employer can start building trust with you. Just because you've been forced to think about some of this right, because you're flushing something out for months and months and months and potentially over a year, and you have users. You've encountered problems and tribulations that you could talk about.
Don Hansen:What an interesting conversation to have in the interview that you're not going to have with your cat gallery or your random e-commerce app or your CMS that you built. Who gives a shit? Those are good for reinforcing skills but, like these are generic basic projects and you know they are that you don't care about, the employer is not going to care about. Like a lot of people that are applying for positions the same position you are applying for like a lot of them are just building these crud projects to reinforce their skills that are meaningless and that just die, go to die in a graveyard, gain no users whatsoever. They're incredibly uninteresting. So to think about, like what you can build for a capstone project, I think some people really struggle with this idea of like okay, so if I'm supposed to work on this project for a long time, what the hell do I build, right? Oh, by the way, if you're trying to become a front-end developer, I highly recommend you check out Scrimpa.
Don Hansen:I'm specifically talking about their front-end developer career path. They have a fun, interactive way to learn how to code and become a web developer, and while that's true, that's not the main reason that I want to promote them honestly. The main reason is their curriculum is solid. There are a lot of curriculums that do not prepare people to actually be competitive in the market, and I've reviewed a ton of programs and to this day, it is still one of my favorites and one of the best front end curriculums out there for self taught developers. And they're backed by MDN, a leading and well respected resource in the developer community, and I actually personally run my own mentees through the program to prepare them for front end developer jobs. And if you choose to sign up via my affiliate link below in the program to prepare them for front-end developer jobs, and if you choose to sign up via my affiliate link below in the description, you actually get 30% off if you sign up for a paid plan, but you have to sign up by the end of February to take advantage of that, because it expires after that.
Don Hansen:Anyways, check it out for yourself. What do you have to lose? And let's get back to the topic. Here's a few ideas to kind of get your creative juices flowing or just get some ideas in your head, but I want you to understand that coming up with project ideas, identifying problems that exist in the world. That can be solved with the code that you're learning. That can be solved through solutions that you build. Think of it like a muscle. You have to train that and there are strategies to brainstorm. There are tons of guides to be able to do that, but it is something you have to train.
Don Hansen:A lot of leaders in the industry, especially like a lot of product owners and CEOs, they've kind of trained their mind to identify problems in the industry, especially like a lot of product owners and CEOs. They've kind of trained their mind to identify problems in the world, and a lot of them will have like a notepad where they just write down ideas over and over and over. But that didn't happen instantly. They kind of train themselves to do that over time and that's what you can do. But I'll give you a few ideas to start with.
Don Hansen:So think about your old industry. You are going into a new industry where a lot of other people are learning a lot of what you're learning and there's going to be some differences, because your curiosity should let you spend time kind of doing side quests and learning extra things that you're curious about, and that's kind of what makes you unique. The idea is like, what makes me a unique developer? But one thing that automatically makes you a unique developer is you and your old industry. What industry did you come from? Almost always there are developers in that industry. What the hell are they building? They're probably building the apps and tools that you use to be able to do your job. Now, if you're like me, I've used a lot of crappy software in my old industry, a lot of software that if I had the time at that time and I had the knowledge I would have built, and very differently. What could you go back and build in that industry that you wish you could have used when you were on the job?
Don Hansen:One thing hiring managers look for and companies look for is to bring in people that care about their product. It's probably going to translate into more longevity of the company. When you care about the users, it's not just about impressing your manager, not getting fired. It's about like oh, I'm actually finally starting to build real things for these users. I'm seeing the feedback come in. It's helping them out. This app seeing the feedback come in. It's helping them out. This app helps them in their life. Like this is rewarding. That can translate into longevity of developers at that company that give a shit about the product and the users right.
Don Hansen:So you went through that old industry. You might not like your position, you might not like the direction that your old position was going in. But what if you were a developer in that industry? Do you think you would like that industry again? Maybe you left and it's not like you disliked it, you were just trying to kind of up your game a bit and learn new skills. But but think about what you would build in that industry. That would probably catch the attention of some tech teams in that industry. You already know the industry, you know the users, you know the problems that exist.
Don Hansen:So you don't have to do a lot of critical thinking to be able to identify those problems. You just have to think about all the times that you were frustrated using the crappy software that you used. What would you build differently? And that's an avenue where you can take your old industry experience and you can really show the uniqueness that stands out among the crowd of a bunch of surface level devs that don't give a shit about what company they work at, when you kind of express yourself as someone that, like hey, came from this industry. This is your story. I came from this industry really crappy software. We were all really frustrated with it.
Don Hansen:So I built something entirely different that, like you know what I'm doing right now. I'm actually reaching out to a lot of these companies. I'm saying, hey, I know my software is kind of like fundamental basic right now, but like, this is what I plan on fleshing it out to, very open to feedback. But I am willing to, you know, outsource this to you guys to at least give it a try, even if it's for free and, if you like it, 30 days we could talk about kind of like some payment plan. You could look at some monetary value with that. But still, the idea is to build something that's useful and think about like, how do I put it out in front of people? And you might have to learn a little bit of marketing and cold emails and reaching out to people. These are all extra skills that will eventually help you out in life.
Don Hansen:But you know, this is a valuable, practical project that most junior developers are not willing to build, and a big reason why is because a lot of junior developers just get bored. They have a ton of graveyard projects. Because they don't know where to go with a project, or they get discouraged with it, or they encounter a problem that's too difficult, and then they move on right. They give up too easily or they don't care about the project enough. You could be that junior developer that actually continues to flush out this product for many months. I'm telling you that is one thing that'll make you stand out from many other junior developers.
Don Hansen:But also you could think about, like what apps do you want to build? I had a fitness timer that um would do like interval training, but I wanted custom intervals where this my rest periods were um less in the beginning where I was doing lighter weight, and then they were greater, like up to two minutes when I was doing heavier weight over the course of my workout. I could not find a timer for the life of me, and this is a while ago, but that's an app that I could have built for myself. That is practical and useful, and if it's valuable to you you find it useful it's probably valuable to other people. You just have to think about how to market it, how to present it with a proper landing page, and that's another thing that you really got to flush out with this capstone project, like make it look like a professional looking project that people would want to use. You focus on that and it really helps your capstone project stand out from so many other people.
Don Hansen:But what apps do you want to build? They could be useful apps for you. They could just be something that, like you know what this sounds like a really cool idea. I want to go ahead and flush this out. You know, I wish Spotify had this feature where you could create a community and you could have give certain permissions to people to be able to add and edit playlists and stuff like that. And you know what you know, streamers might even find this useful. Or, you know, maybe just my friends would find this useful. But if my friends find this useful, I bet you other people that, like wanted to build communities, or even like fitness groups that wanted the option for flexibility in like building a bunch of playlists and their members could contribute, like maybe you know, gyms would find this useful and you could just like.
Don Hansen:It's just that, trying to expand your thought about who would find this useful and how would they find it useful. What features would this group care about? What features would this group care about? That's user-centered thinking, that's becoming a user-centered developer, and that is one of your primary goals. It's to understand what you're building, because you understand what it's solving and who it's solving this problem for. When you start leaning in and diving into becoming a user-centered developer now, you're going to get a lot of product positions that are kind of like now they're looking at you, now they care about you, especially when the problems that you're solving line up, even at a basic level, with what they're trying to build, what they're trying to solve, what industry they're in. You look for that alignment.
Don Hansen:A lot of junior developers will just build a variety of apps and just throw all that spaghetti on the wall and see what sticks. You don't want to be that developer. 500 other people are doing that for that same position. Don't be that dev. You're just wasting your time, your valuable time, trying to be that dev. You're a developer that actually gives a shit about their craft and you care about the problems that you're solving. It doesn't mean you can't expand and solve a variety of problems and you might find like I actually really like solving this problem more. I'm going to double down on this and get better with this. So I think variety is also good for exposure. Just building a variety of apps to get a feel for like what you like building, you can do a variety of technologies and just try different stuff. That's completely fine.
Don Hansen:But when we're talking about a capstone project, the thing that really makes you stand out, we're thinking a little bit differently. So think about, like what industry you care about you, you know, maybe like mental health is a big thing for you. Maybe the environment is a big thing for you. Maybe just social issues are a big thing. Maybe fitness is a big thing, maybe cooking is a big thing, like what's important to you. What do you care about? There are probably devs in that industry. But no matter what you choose, there are probably devs in that industry.
Don Hansen:But no matter what you choose to build, you eventually want to double down on a tech stack, to try to get very good with a bunch of tech stacks. No one has that amount of time in the world. I think getting exposure to different things until you really find something you like is valuable. But eventually you need to really go deep into a tech stack and sometimes you might hopefully you're doing a bit of research to see, like, okay, what big cities around me are like, what are they hiring for? What kind of tech stacks are they hiring for? Do I even want to stay in this area? Do I want to try to relocate to a different area? What are they hiring for? How about my entire country? Like, if I had to, like, get the average top three tech stacks that are um companies are hiring for? What are they? You should do some of that research on your own, but I want to actually and this might be controversial but I want to encourage you to just double down on a marketable tech stack and then build or solve problems that you want to solve through that tech stack, even if that tech stack isn't the best use case or it's it's not the best tech stack to solve that particular problem.
Don Hansen:I think sometimes people get hung up on, especially in the JavaScript world. I think it's completely fine. Completely fine If you are, you want to stick with JavaScript, you want to apply for JavaScript positions. It's completely fine to build stuff with node, even though it's not going to be the most or the best organizer, the most efficient to be able to solve your problem, especially if you I'm not even going to get into it. That's. That's a whole can of worms, um, but building something with node, building a full stack application with node to be able to flush out this idea and build, solve problems in the industry that you want to solve them in, um, maybe node isn't the best tool. Maybe react isn't the best tool. Maybe you're just really aiming and gunning for front end positions. React isn't the best tool for a lot of front end apps, but you probably want to utilize react and build complex things with it, to be able to deepen your knowledge with react and solve. You know several problems or a deeper problem with the react, so I don't think you need to choose the best technology for every single problem at the junior level. I think eventually, you just got to pick a stack after you've done your research and double down on that and then focus on the problems that you're solving, the apps that you're building and eventually, that capstone project that you're building to really go deep as you flush out a ton of features. So, um, a few other things to consider.
Don Hansen:Um, we talked about making your app valuable, but like aim to for users. If you launch an app, what communities are going to care about that? Are there subreddits? Are there Twitter groups? Are there LinkedIn groups? Where can you go to advertise this? Maybe you just do paid advertisement to get your first 100 users to be able to use your app so they can start giving you feedback and you have a way for them to be able to submit feedback and what happens with that your app, so they can start giving you feedback and you have a way for them to be able to submit feedback and what happens with that.
Don Hansen:You can start involving the Scrum and Agile process where you kind of like document what you think is important. You identify that. You talk to users if you want, but now that I have some feature ideas or bug fixes that I need to do, let's go and document it. Even if you're just creating GitHub issues to start with, right, you're documenting it. You're listing out the requirements. You're fleshing these out. Maybe you flush out more technical requirements and you break it down a little bit more. You have a bit of a history with that. Your repo could. It probably should be public if you're trying to get a job to be, you know, so employers could dig into it if they really wanted to.
Don Hansen:Um, and a lot of you'll find that employers will start to dig into your projects a little bit more when there's complexity in it, when it kind of piques their curiosity. They're taking you seriously as a candidate and they want to dig into your implementation, to be able to ask you questions in the interview. But, um, yeah, you're, you're fleshing out issues and then you are um, and once you flesh out the requirements you are building, you're coding it out and then you are pushing out changes as you get new features out, you're pushing them out to production and then your users can use them. They can give you feedback again, even if it's just positive. But then that feedback comes in as you're just iterating in a loop. Now you're going through the agile process, so you're documenting a lot of these features, a lot of what you need to get done, and push out into your app the scrum process and you are iterating with the agile process. You know you could expand on both of those to make it a little bit more complex, but like that alone is more than what most people are doing and that's going to be impressive to an employer when you can talk through your process of being able to get feedback, write the requirements, plan things out and then code and push out those features. That question comes up pretty often in an interview. Now, if you get customers using it, you get monetary validation. That's also something to highlight with the project. That's impressive.
Don Hansen:A lot of junior developers can build SaaS products. I think a lot of you don't think you can, but you can With many, many, many months diving into a capstone project and even potentially over a year. Now when you think about it it becomes a little bit more realistic, like, yeah, I could probably flesh out kind of this application that people would pay for. I probably could. You're not gonna be good with pricing models necessarily, or maybe you are, maybe you're a salesman who knows, but you might have to learn additional things and you got to be careful about how much time you spend outside of coding to really grow as a developer, which is why freelance can kind of sideline you, because you're doing a lot of client work. You got to focus on your legal, your communication skills, your marketing, your outreach right. So this is why I usually caution people to not go the freelance route because it can sidetrack them entirely from growing as a developer, unless they really want to do that. But same with, you know, trying to push out a sass product you're trying to monetize. Be very careful.
Don Hansen:Your your goal isn't to build this, um, this sass product that is bringing a significant amount of income in. It's just like let's build something, let's build a mindset to be able to build something that people would probably pay for. And maybe over the coming months I'll kind of learn where I could market it. Maybe I'll learn pricing a little bit and, yeah, I'll just toss maybe, um, a PayPal link or something like that where people can donate, uh, users can donate if they appreciate the app. You could start with something like that, but some of that monetary uh, that that revenue can show some sort of like social validation that your app is useful. You're building real shit people would pay for and that could be powerful, but it doesn't have to be. It's more about developing the mindset of building something that people would probably pay for, even if you had to flesh out the idea a little bit more. And if you're building dev tools, keep in mind, like not everything is.
Don Hansen:I talk about front-end a lot, I talk about web development a lot, but you can build dev tools. You can build mobile apps, you can build kind of like native applications for Mac or Windows so you can build, like, different types of applications. It doesn't have to be a website, but you could also build a dev tool I think a lot of people think of like CRUD applications for web dev where, like, your users are essentially users that are using your product. But what about building a developer tool? You use developer tools right, so you know what they are. What about building a developer tool that's useful for other devs? So your users are devs and your goal is to create a better developer experience. Maybe not like the best UI if it has a UI at all but you are creating the best developer user experience possible and you got to do a bit of research to create good developer experiences and you can learn from the apps that you or the tools, the developer tools that you already build on what a good developer experience is.
Don Hansen:What do I like about this tool? What don't I like? What don't I want to replicate in my product. You can learn from the bugs and the bad experiences of the tools that you use. I would try to get some sort of presence, like even if it's like a landing page for your website, if it's a social media presence where you're kind of building a bit of an identity for this app and you're showing like this is a real tool that you can use and that's going to provide you value, whether it is a landing page, whether it is a social media presence, whether it's you going on podcasts and talking about it, potentially whether it's you just starting off sharing it on LinkedIn and joining a couple of communities and asking the mods if you could share that, or giving practical advice like, let's say, you build like we'll just go back to fitness, maybe you build like a fitness app and your goal of marketing, essentially, or your branding for people to learn about you as a passionate fitness enthusiast who also builds dev tools. You're getting that story out because you start a blog and you talk about building this app and you would wish that you in your situation 5, 10 years ago would have had a tool like this, right, and you wish that your friends would have had a tool and your gym would have had this tool. It could have been so useful for everyone and you create a story around this by talking about it over and over and over, and a blog is a really good way to do that. Twitter is good, linkedin is good for that.
Don Hansen:You could do different mediums. You could start your own podcast giving fitness advice. It doesn't have to be talking about your app, but just like talking about the industry that your app is in. That's what a lot of companies do. Uh, make sure for your repo, you know. Make sure it just has proper readme. You can look up, like, what to include in your read readme but at the very least, like the readme should include installation instructions, how to get it up and running and you could talk about some of the features or the customizability of it and how to do that in your application. But you could also talk about some of the user-focused features in your Readme as well. You could really flesh out a very professional-looking Readme. A lot of employers will care about that.
Don Hansen:But get a professional domain. If it's a website, get a domain, a professional one. Stop with these subdomains that deactivate like. You're going to have a variety of projects where you can have, like whether you choose heroku or another tool. You could have some subdomain that links to your second and third project. But your capstone make it look professional. Get a professional looking domain for less than $10 a year, same with your portfolio. I highly recommend it.
Don Hansen:If we're talking about building and fleshing out a capstone that looks like a real professional project, splurge a little bit with that. Work an extra hour to be able to afford it. Work an extra two hours if you need to, for the entire year to be able to get that domain. I do think it makes your project look more professional. But you know, if you really just worked on a project for a week and that's what you're labeling as a capstone, it probably isn't worth paying for a domain. Um, is there anything else? No, that's it. That's all I have. I had a pretty big outline for today and I think I covered everything. I think this video is, uh, pretty long, but I like the main thing with this is I think one of the worst questions I get asked is what, what do I build? And often the question, what they're really asking is tell me what to build, or they're not asking it. They're telling me tell me what to build and I'll build it.
Don Hansen:You are not a code monkey. You bring a ton of uniqueness to you that no one is going to know, but you and you need to creatively think, you need to critically think, you need to problem solve on your own. You need to do proper research. You need to creatively think, you need to critically think, you need to problem solve on your own. You need to do proper research. You need to do a little bit of soul searching about what the hell you give a shit about to develop this unique persona, this your unique presentation of a developer to showcase the dev industry. Why you? Why should a company hire you out of like 500 other developers? Why? Why you? What is unique about you? What do you bring to the team? And a lot of people aren't thinking about this stuff, but it does take a bit of soul searching to figure out what kind of projects that you want to build.
Don Hansen:Stop Like, if you're looking for templated projects to reinforce skills, that's fine. But if you're looking for portfolio projects to make you stand out, stop asking other people to tell you what to build. You are completely missing the point. And if you get to this part of the video and you, I swear, if I see one comment, one comment about what you or what I think you should build, I'm going to lose it. But if you got to this far in the video and you aren't going to take time after this to do a little bit of brainstorming and think about what I said. I think you're going to have a really, really rough time in this industry and you're probably never going to break into this industry. So please take what I said seriously. Be creative, find what makes you unique, because that is what is going to make you stand out.