This Slack discussion by , , and occurred in 's official from Nov 5 - Nov 11 2020. Dane austin Arthur David hackernoon #slogging-beta channel Protips for building a new app from scratch Dane Nov 5, 2020, 4:22 PM oh boy 😅 where to begin...ok let's say you're on a new machine: first thing i do is install my preferred shell: with the package installed. that goes a long way, having a shell you're comfortable in austin Nov 5, 2020, 4:23 PM zsh oh-my-zsh Whenever you get started with a new app, it is tempting to dive in and go deep figuring out how to solve the most relevant problem. But this approach can often lead to a half-baked solution with no foundation. When you start, think about your app as a blank canvas and be concious about investing a significant amount of time on the broad strokes. It's ok to think about details because that's really why you're setting out to build a new thing in the first place. But don't overly fixate on a single detail. Dane Nov 5, 2020, 4:27 PM austin of course you are going to start with the shell! 😂 Dane Nov 5, 2020, 4:29 PM haha i'm starting at the foundation, naturally 😉 ooh, that's good advice. different approach to the question... i think of it like painting a room -- don't want to paint yourself into a corner, with the early decisions. every decision you make is going to limit what you're able to do from that point also, validate your problem people! too many apps start as an idea that you think people will like, but really have no idea. most startups fail because they either build something people don't want, or they run out of money doing it. you vastly improve your chances by just talking to potential users austin Nov 5, 2020, 4:30 PM Another problem I see all the time with developers starting new apps is the draw of using a new language or framework. This isn't entirely bad but so often people get so caught up learning new technology that they lose sight of the underlying problem they are trying to solve. In many cases, I'd say it is better to try and reuse tech you are already familiar with instead of using entirely new tech. Dane Nov 5, 2020, 4:31 PM austin validating is tricky. I actually think it is better to build something minimal and go with a trial by fire approach to validating an idea over doing a bunch of user research before you get started. Dane Nov 5, 2020, 4:33 PM Dane definitely!! was just gonna say, do not reinvent the wheel. to paraphrase that old tech adage, "no one ever got fired for using vanilla JS". or whichever established tool you like i also agree with your second point. i wouldn't recommend spending a ton of time on user research. in short: 1. build something small, quickly, then 2. release it early and talk to your users a bit. the early release bit is important austin Nov 5, 2020, 4:34 PM Optionality is a good way to think about early decision making though. Don't lock yourself into a solution you can't back out of. Focus on building a minimal foundation that solves the problem and iterate from there. Dane Nov 5, 2020, 4:35 PM I'm against the approach. I think you should be absolutely mentally prepared to approach the problem in an entirely new way. I'm talking more about using tools you are already familiar with when build the new thing. Dane Nov 5, 2020, 4:36 PM Don't reinvent the wheel If the focus should be on using a tool rather than learning a tool. Dane Nov 5, 2020, 4:36 PM When it comes to learning about user needs, there are a lot of ways to approach that. Talking, listening, and asking questions is an entirely viable approach. Watching behavior and taking more of an analytics approach is also viable. The big thing is you need to continually think about user needs and gather new information to help aid in that pursuit. Dane Nov 5, 2020, 4:40 PM definitely, that's what i was getting at, but i wasn't quite getting there. listening to users can mean a lot of things but serving user needs is the goal. also, when i say "don't reinvent the wheel", i'm talking more about...don't roll-your-own base64 decoder. they exist already, and it's a very well defined problem and solution, very mechanical. i agree, you shouldn't be afraid to dig into the guts if need be, and create new solutions, novel solutions. austin Nov 5, 2020, 4:44 PM Oh yeah. I think we're on the same page. I just wanted to dig into the idea of a bit because I think a lot of people take that to mean which I don't agree with. Dane Nov 5, 2020, 4:46 PM Don't reinvent the wheel Cobble together a solution based on existing solutions oh for sure. to give a concrete example, i saw a drone for saving people lost in the mountains the other day. awesome idea, right?! they could've done so many things to make it good at its job...but they cobbled together preexisting solutions and wound up with a black and white camera on a stock helicopter-style drone that could pick up cell phone signals. neat, but doesn't quite solve the problem as well as you could have if you dug into the guts of "how do we find lost people? and what if they don't have a working phone?" austin Nov 5, 2020, 4:47 PM Think about tools in terms of explore vs exploit. If you are continually looking for the next tool to use, you can't really exploit your knowledge of existing tools. In some ways this is a good thing because you become a generalist at using tools and can quickly make use of a new tool. But people should do more to exploit the tools they already know. Dane Nov 5, 2020, 4:48 PM exactly. so in this example, i would exploit the existing drone tech, that's great. i would also exploit existing thermal cameras, for one, to make it easier to find people in the wilderness. but i would also explore pattern finding on the regular camera and the thermal camera with tensorflow or something. definitely want a balance or you'll spend all your days in the docs 😛 austin Nov 5, 2020, 4:52 PM a doc worker, you could say austin Nov 5, 2020, 4:52 PM Another topic to consider when starting an app is figuring out how to create a habit out of making progress. You want to avoid scenarios where you avoid making progress because you get stuck on a problem or aren't motivated by some particular part of the app. The most important thing is to make sure you are always making progress. One way to achieve this is by having a backlog of "fun tasks" that you can dip into whenever you hit a roadblock. Dane Nov 5, 2020, 4:53 PM now this is something i definitely struggle with! i start personal projects and don’t keep a fun backlog, i’m just hammering away at the problem in my spare time, and if that short amount of time per week becomes unproductive…you lose steam. i do, anyway. so then you find another project, and suddenly it’s a lot more appealing because hey, you’re stuck on that other thing anyway… austin Nov 5, 2020, 4:55 PM Create GitHub repository Arthur Nov 6, 2020, 11:09 AM Call me old school, but I still love starting by drawing the first couple screens by hand. There's something about my brain that can approach the problem in a simpler way when the pen is in my name. It's just how it was when I started learning. David Nov 11, 2020, 6:45 PM Sketching is definitely a great way to get started. It's a specific example of "painting with broad strokes" before you dive into the details. Dane Nov 11, 2020, 8:53 PM Another tip. Make sure you create a distinct separation from the and the . This is important because people are negatively biased against the work they are responsible for. Instead of objectively evaluating the idea, people push back against the idea. Bad Example: PM: Hey Joe, how long would it take for you to build a wind sail for a skateboard? Joe: Let me tell you the 10 reasons that won't work. Good Example: PM: Wouldn't it be great if a skateboard could be wind-powered? Joe: Oh yeah! I'll bet a wind sail could capture enough wind to easily power a skateboard. Dane Nov 11, 2020, 9:01 PM todo list people responsible for delivering each todo item In both cases, Joe might end up doing the work. But the second example frees Joe from the obligation of doing the work and invites him to think through the problem and the solution. Dane Nov 11, 2020, 9:06 PM Here is a slightly different tip related to the previous tip. Be problem focused and solution agnostic. I don't remember who I heard this from exactly but it is something that has stuck with me as a generally good thing. It is so tempting to think of a problem and immediately jump to a solution. The decision to jump to the first viable solution is good in many cases because it can reduce the amount of time to deliver value. But so often, the first viable solution is a pretty terrible option. So you've got to have a constant awareness of the problem and continually challenge your assertions. Dane Nov 11, 2020, 9:14 PM I guess the last few tips could be thought of as startup tips rather than bootstrapping a new app tips. But the way you think about your app is as important as how you build it. Dane Nov 11, 2020, 9:16 PM By taking a problem focused approach you can reduce the chance that you achieve the wrong goal. For example people generally assume more time using the app to be a good thing. But if an app like Uber made that their goal, it would really annoy people from solving their problem, which is using the phone as a little as possible for a ride to show up as soon as possible. David Nov 11, 2020, 11:33 PM

BUNCH

Slack

Uber

2022 - HackerNoon Contributor of the Year - Climate Change

SLOGGING.com

First 200+ Slogging Stories

Yahoo Interview

#Slogging

Nominated for 2022 - HackerNoon Contributor of the Year - Climate Change

Art is Dead Dude: AI-Generated Image Wins State Art Fair

Why Has NASA Stopped Exploring The Oceans?

Netflix Plans to Launch its Own Video Game Studio

Too Long; Didn't Read

Protips for Building a New App From Scratch

Protips for Building a New App From Scratch

Too Long; Didn't Read

Companies Mentioned

Slogging (Slack Blogging)

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Protips for Building a New App From Scratch

Too Long; Didn't Read

Companies Mentioned

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES