1. The Idea

Think of a market of one and ask yourself:

What’s a tool or idea that I’ve always wanted for myself?

The reason you think of yourself is that you’re accessible. You know your own likes, dislikes and pain points on the daily. Secondly, the chances that there are people in the world similar to you is fairly high. Therefore, whatever you build is likely to find at a home or interest with least one other person.

Solving a real world problem (at any size) gives you something more ‘shippable’, which demonstrates an ability to take:

Idea  → Design → Product → Launch

Your initial idea doesn’t need to be grandiose, but it should be something that you personally think is interesting to use.

Avoid building “TODO app, or “Clone x in y language”, these types of projects are rarely inspirational or finished.

2. Design

Before heading off to the binary jungle, try put a designer hat on and ask questions like:

What is the core concept or task I am trying to accomplish with this product? Who would be using this? Why? What old systems or tools might this product be replacing? What kind of features would be important to someone using this?What might this look like? Does this make sense as a website, Mac app, mobile application?

This can be as free form or structured as you want. But I do recommend grabbing a pen and paper to:

1. Mind Mapping the core concept to identify deeper concepts
2. Answers the questions with pen and paper
3. Doing 2–3 free form napkin sketches of the the product

This work is throw away style, it’s a technique to distill an idea further and narrow down what to build. Don’t get obsessed with the details.

3. Getting Technical

Once you have a concrete idea and some sketches, it’s worth thinking about the technical aspect of the project.

3.1 Websites

Full Stack Web apps are the types of websites we interact with everyday. A monolithic app generally consists of 3 main components:

1.Front End Interface: An interface that allows users to manipulate the data, view pages and retrieve resources from the application.

2.Backend Logic: The logic or code that manipulates data and interacts with the database

3.Database: The place you store your data persistently

If you’re building a website it’s easiest to use a web framework.

A framework is a set of tools and software created by other developers to automate mundane tasks, reuse common logic (like database manipulation), and generally speed up the process of development for software projects.

A list of popular frameworks includes:

Don’t obsess over the best framework focus on learning just one.

3.2 Mobile Apps

Mobile apps can be more straightforward to get started with compared to web apps as a novice. The distribution is handled, and all APIs are included in the platform SDK from Apple and Google.

If you’re having trouble deciding, just pick the platform you have a phone for and the tools to build on.

4. Managing the Process

Creating a plan to manage your project can make an idea more concrete. Adding process makes the building phase more deliberate and thoughtful with deadlines to discipline yourself to.

Additionally, planning out a few features, and having a system around it, enables you to pick up where you left off in the road map.

Context penalties are the price you pay to get “back into the zone” after stopping a task and coming back to it at a later time. These penalties are huge costs in software development, but can be mitigated with a plan or road map.

Finally, planning improves your own accountability and awareness to keep yourself on track — which translates well to leading teams be it technical, design or product teams.

4.1 Planning and Features

The system can be as simple or complex as you’d like, for example, just using GitHub Issues to track features and bugs.

Figure 1: An example of managing and performing product and developer management with GitHub Issues

Even creating two simple tags: Feature or Bug, and writing down the features you want to build before building, can save a lot of headaches.

4.2 Setting Deadlines

Setting deadlines for the project is critical. Without a deadline you can keep putting off releasing to the world. The project will never be “quite good enough” and there’s always “one more thing to add”. Better yet, you can “forget about the project” to work on something else without a goal in mind.

Deadlines keep you accountable, and increase the pressure for you to learn and build. By formalizing a deadline, you can prioritize or de-prioritize features, versions and bug fixes in order to hit the release. Your deadline will be arbitrary, don’t worry. Just get a reasonable date sometime in the future and let that be your goal.

Try to work in deadlines somewhere between 1 to 3 months to ship and publish a minimum build!

4.3 Setting Criteria

Make a set of criteria under which you would be minimally satisfied with the product you produce and will release under.

This could be a set of features, or a special feature milestone, under which a application will be considered a “release candidate”.

Example:

Once we implement the database upgrade, and new profile design, we can launch

It’s critical to set a finite number of criteria and not to let things keep creeping in (also known as “scope creep”). Otherwise you’ll delay release, testing, or worse, create potential upgrade and usability conflicts.

GitHub milestones are useful for this activity.

Figure 2: An example of a GitHub milestone

How many features should I put in a milestone?

5–20 depending on complexity

5. Pre and Post Releasing Your Product

Releasing is it publication of a project or product to a general audience freely

Before release understand how applications are released on the web versus mobile.

Web applications have a different protocols for deploying, releasing, and marketing compared to mobile apps. For example, web apps lack dedicated distribution channels (e.g. no “Web app store”), or rigorous standards to enforce. This offers flexibility but complication.

Mobile applications, on the other hand, have straight forward distribution channels such as the Apple App Store or Google Play store. This creates simplicity but rigidity in the process.

5.1 Releasing Full Stack Web Apps

A consideration of releasing a web app is your infrastructure or hosting platform. Before services such as Amazon Web Services (AWS), companies would purchase their own servers or lease physical space from a data centre.

However, today, services like AWS , Digital Ocean , Heroku , Firebase and others, act as Infrastructure as a Service (IaaS) or Backend as a Service (BaaS) platforms. These services offer computing resources on a cost per utilization (time, api calls, requests) basis. Such offerings have simplified developers workflow by enabling them to scale up or down the resources (CPU, time, memory) needed on a regular basis. It’s a great exercise to go through deploying on any of these platforms.

5.2 Releasing Mobile Apps

Mobile applications are unique in that the distribution is handled entirely by the parent company who owns the operating system. Both distribution paths provide you the opportunity to see analytics, installs and update your applications accordingly.

5.2.1 iOS

For iOS your distribution will need to sign up for Apple’s Developer program. You’ll need to sign up as an Apple Developer which costs about $99/year. You will have to endure a set of quality assurance tests to ensure your app meets Apple’s quality standards.

5.2.2 Android

For Android based applications you will need to get access to the Google Play Developer Console. You will need to sign up as a Google Developer which costs about $25 one time fee.

5.2.3 Paying Developer Costs

Some individuals often complain and opt not to create “unnecessary” expenses for side projects when asked to host on cloud resources, or sign up to a developer program to build their project.

This is cautioned against. Just like planning makes a project feel “real”, so too does adding expenses. For two reasons: first, by adding expenses you create something at stake. Second, any of the costs (if you can afford them), are investments in the greater product you are working towards: yourself.

5.3 Post Release

After releasing your application, you can get some feedback or users to test it, by submitting to a variety of websites.

6. Final Thoughts

Building a polished product is impressive and shows great initiative, potential and competency. Anyone who has released something can tell you the process goes much beyond the code, but most do not get past that stage. Consider each project a learning opportunity and have a goal in mind to learn a new piece of technology or concept with each endeavour you begin.

Once you’ve release, get feedback and continue working on the product or iterating different designs or ideas. Perhaps you want to add payments, a new set of features or a complete overhaul on the design. Getting people’s feedback will allow you to improve the product and take it from a “just you” to many people kind of idea.

Finally, do not get too frustrated if your app isn’t perfect. Everyone is growing, learning and improving. A helpful heuristic to know you’re learning is:

If you can look back on your code from the past few months and ask, “What the heck was I thinking?” then you know that you’ve made progress.

Have fun!