Protips for Building a New App From Scratch

Protips for building a new app from scratch

oh boy 😅 where to begin...ok let's say you're on a new machine: first thing i do is install my preferred shell:

zsh

with the

oh-my-zsh

package installed. that goes a long way, having a shell you're comfortable in

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.

austin of course you are going to start with the shell! 😂

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

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.

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 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

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.

I'm against the

Don't reinvent the wheel

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.

If the focus should be on using a tool rather than learning a tool.

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.

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.

Oh yeah. I think we're on the same page. I just wanted to dig into the idea of

Don't reinvent the wheel

a bit because I think a lot of people take that to mean

Cobble together a solution based on existing solutions

which I don't agree with.

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?"

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.

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 😛

a doc worker, you could say

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.

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…

Create GitHub repository

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.

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.

Another tip. Make sure you create a distinct separation from the

todo list

and the

people responsible for delivering each todo item

. 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.

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.

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.

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.

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.