Beginning modern application development with .NET Core – Part 1: Getting started and writing some code

This is the second post in a free series of tutorials on “Beginning modern application development with .NET Core”. To view the series, click here:

All of the source code used within this tutorial is available within a publically browsable Gitlab repository, located here:


Welcome to the second post in the series of tutorials on “Beginning modern application development with .NET Core”. This post is going to cover your first step towards writing a modern application: the setting up of your development environment and writing your first, small piece of software. You’ll learn how to download and install the .NET Core SDK, you’ll install a code editor and you’ll get your first bit of code running; exciting stuff!

Installing the required tools

First things first, you need to install some software on your machine. Don’t worry: these are all developed by and downloaded from Microsoft; so no need to worry about viruses making their way onto your system.

1. Installing the .NET Core SDK

In order to run, build, compile or test any .NET core code, you will need to install the SDK. This is freely available on the Microsoft website, and has great instructions on how to get the SDK installed on your operating system.

2. Installing an editor: Visual Studio Code

Next, you need some software called a code editor. You could use regular ol’ Notepad, but using a tool specifically for the job of programming will help you in more ways than you could imagine once you start writing more complicated code (syntax highlighting, snippets, intellisense).

We’re going to use an editor called Visual Studio Code. It’s a relatively new, free editor from Microsoft and is a great tool for programming in the .NET Core languages.

So, go ahead and download it from here:

Once you have installed the editor, there is one last thing you need to do and that is to install an extension within Visual Studio Code that helps you with programming in C# (the .NET Core based programming language we’re going to be using).

To install this extension, open Visual Studio Code and click the extensions icon in the sidebar.

Then, in the extensions search bar, search for ‘csharp’, and install the extension provided by Microsoft. It should have over 3.5 million downloads, so it’s not difficult to spot what is the correct extension. If you are struggling to find it, then you can sort by ‘Most popular’ by clicking the ellipsis icon and then selecting the relevant menu item.

Once you have installed this extension, reload Visual Studio Code when prompted and you are ready to go!

3. Checking the .NET Core SDK installed correctly

Inside of Visual Studio Code, click ‘View’ in the toolbar and then ‘Integrated Console’. Alternatively, press Ctrl + `. You should see a terminal window open where you are able to type commands. A terminal window is a place where you are able to execute commands against the system.

Inside of this terminal window, type the following:

$ dotnet --version

If you see something like the below (even with a different version number), then the .NET Core SDK has installed successfully and you’re ready to write your first piece of .NET code. Congratulations! If you see an error, first make sure you have installed the SDK correctly and then reboot your machine.

$ dotnet --version

Exploring the CLI and creating a new project

The CLI (short for command-line interface) is your new friend when it comes to programming in .NET core. It contains helpful functions that allow you to create, compile, test and publish your applications with no more than a few keystrokes.

Taking a look around the command line interface

If you’ve followed the tutorial so far you should have Visual Studio Code open with a terminal window visible. If you don’t: get that ready again, if you do: great.

Most command line interfaces come with a ‘help’ command embedded within them that advises you on what the CLI can do for you. Let’s run the .NET Core CLI’s help command (dotnet --help) and have a look over what the CLI can do for us.

$ dotnet --help
.NET Command Line Tools (2.0.2)
Usage: dotnet [runtime-options] [path-to-application]
Usage: dotnet [sdk-options] [command] [arguments] [command-options]

The path to an application .dll file to execute.

SDK commands:
new Initialize .NET projects.
restore Restore dependencies specified in the .NET project.
run Compiles and immediately executes a .NET project.
build Builds a .NET project.
publish Publishes a .NET project for deployment (including the runtime).
test Runs unit tests using the test runner specified in the project.
pack Creates a NuGet package.
migrate Migrates a project.json based project to a msbuild based project.
clean Clean build output(s).
sln Modify solution (SLN) files.
add Add reference to the project.
remove Remove reference from the project.
list List reference in the project.
nuget Provides additional NuGet commands.
msbuild Runs Microsoft Build Engine (MSBuild).
vstest Runs Microsoft Test Execution Command Line Tool.

Common options:
-v|--verbosity Set the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].
-h|--help Show help.

Run 'dotnet COMMAND --help' for more information on a command.

--version Display .NET Core SDK version.
--info Display .NET Core information.
-d|--diagnostics Enable diagnostic output.

--additionalprobingpath <path> Path containing probing policy and assemblies to probe for.
--fx-version <version> Version of the installed Shared Framework to use to run the application.
--roll-forward-on-no-candidate-fx Roll forward on no candidate shared framework is enabled.
--additional-deps <path> Path to additonal deps.json file.

As you can see, there is a great amount of functionality within the CLI that we can use. As you become more experienced with development in .NET Core, you’ll use more and more of these commands.

Creating a new project

The command we’re interested in for now, however, is the ‘new’ command.

new Initialize .NET projects.

As the description alludes to, the ‘new’ command will generate a new .NET project for us based on a pre-determined template, meaning we spend less time on administrative tasks and more time programming. If you run the help command for dotnet new (by suffixing the option --help), you will see that there are a number of templates we can choose from.

To start with, let’s just create a regular console application. Run the command below (dotnet new console -n modern-app-dev-01) to start a new project based off of the ‘Console Application’ project template.

$ dotnet new console -n modern-app-dev-01
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on modern-app-dev-01/modern-app-dev-01.csproj...
Restoring packages for /home/liam/modern-app-dev-01/modern-app-dev-01.csproj...
Generating MSBuild file /home/liam/modern-app-dev-01/obj/modern-app-dev-01.csproj.nuget.g.props.
Generating MSBuild file /home/liam/modern-app-dev-01/obj/modern-app-dev-01.csproj.nuget.g.targets.
Restore completed in 219.68 ms for /home/liam/modern-app-dev-01/modern-app-dev-01.csproj.


Restore succeeded.

Then, open this newly created folder within Visual Studio Code by going to ‘File’ and then ‘Open Folder’. After doing this, you should see that the sidebar updates with the list of files in the newly created project directory.

Writing some code

By default, creating a new .NET Core Console project automatically creates a ‘Program.cs’ file with a ‘Hello World!’ statement in it. In most tutorial posts, this would constitute the end of the series and the author would announce that you are officially a programmer. Unfortunately, this isn’t your Grandmother’s programming tutorial, and this isn’t the final post of the series, so we’re going to dive straight in by first dissecting the program the CLI generated for us and then writing a small program that asks us for our name and then greets us, instead of the entire world.

Dissecting the current application

Open the ‘Program.cs’ file and look at what is in there currently.

using System; – A using statement within C# (or an import statement within VB), allows you to access types (classes, interfaces, structs etc) that do not exist within your current namespace (explained next).

namespace modern_app_dev_01 – A namespace groups sets of related types together within a wider assembly (or project). You can have many namespaces within an assembly, however for the purposes of this tutorial we’re going to stick with just one.

class Program – A class is essentially a grouping of variables, methods and events. Think of it as a bucket, where you put things that are related to each other to keep them organised.

static void Main(string[] args) – Is a method that is the entry point of the application, or what is called whenever the application is ran. The string[] args part within the parentheses is what is known as a method parameter. The first part of this parameter (string[]) tells us that the args parameter is an array of strings.

Console.WriteLine("Hello World!"); – This line calls a static method (meaning you do not have to declare an instance of the class) on the System.Console class. Having the using System; statement at the top of the file means we do not need to call this method by its fully qualified, namespaced name: System.Console.WriteLine.

Writing our introductory application

Remove the Console.WriteLine("Hello World!") line and prepare yourself to write some code. Then, write the code below, line by line. I have included comments which explain what each line does.

using System;

namespace modern_app_dev_01
    class Program
        static void Main(string[] args)
            // Writes a line out to the console.
            Console.WriteLine("Please enter your name and then press enter");

            // Reads input from the console into a variable.
            string myName = Console.ReadLine();

            // Writes an interpolated (i.e. putting variable string representations into a piece of text)
            // out to the console for the user to see. 
            Console.WriteLine($"Why hello there, {myName}. Press any key to exit the application.");

            // Waits for someone to press a key and then exits.

Running our introductory application

Once you’ve written the above code (you don’t have to include the comments, they’re just there for reference), open the terminal window in Visual Studio Code (if you’ve hidden it, go to ‘View and then ‘Integrated Terminal’ or use the hotkey Ctrl + `) and run the dotnet run command.

If everything has gone to plan, you should see your application run! Type your name when prompted and see your program come to life:

$ dotnet run
Please enter your name and then press enter
Liam Symonds
Why hello there, Liam Symonds. Press any key to exit the application.


Within this tutorial you have installed the .NET Core SDK, installed a code editor, learned about command line interfaces, dissected a generated program and wrote your own basic program. All for free, in the comfort of your own chair. Great work!

Get notifications for more tutorials on ‘Beginning modern application development with .NET Core’ by following me on Twitter (@liamsymonds). If you need any assistance with anything in this tutorial, feel free to tweet me your questions.

This is the second post in a free series of tutorials on “Beginning modern application development with .NET Core”. To view the series, click here:

All of the source code used within this tutorial is available within a publically browsable Gitlab repository, located here:

Test Guardian – The beginning of my open source business journey

If you are interested in reading more about my open source business journey – follow the business account on Twitter:

If you are interested in signing up for information on the product itself, visit the website:

I dislike using the word ‘startup’ to describe most side projects or businesses, as I think in most cases what that entity is doing is not what most would describe as ‘startup’-esque. There are no flashy offices, no desire to work a long work week from any employee and no desire to become a unicorn business; something that seems to have become part of the core definition of a modern startup.

Instead, I like to describe those entities as businesses. That’s right, just plain ol’ businesses.

I do realise, however, that the phrase ‘startup’ has come to colloquially mean ‘internet business’ in most social circles.

Mine are no different, and it is with great excitement that I would like to announce the start of a project called ‘Test Guardian’, an open source automated testing application for those with little or no experience. At its core, it brings powerful automated testing techniques to those with little or no coding experience, in the browser, for free (or paid if they choose to use our hosted version). If you’re interested in learning more about the tool, then feel free to visit its website:

What I want these blog posts to be about is less about advertising the product and more about the journey that a ‘solo-entrepreneur’ (aka me in this case) travels on when they are creating their business. What’s more: I want to commentate on the open source side of the business, ranging from the source code to the infrastructure to the profit figures every year, how I plan on monetising something that is given away to users for free and the ups and downs of being an open source maintainer.

I have no idea what the outcome of this business will be. It could fail catastrophically, leaving me and my business at a net loss on this investment and without seeing a penny repaid. Or, it could end up as a comfortable lifestyle business for me. Only time will tell, and, I don’t want to weigh in on where I think this business could end up.

The journey thus far

I’ve been writing software now for over half of my life. Professionally, I’ve been writing software and web applications for companies all of my working adult life (unfortunately, or fortunately depending on how you look at it, that’s only 5 years!).

Since I was old enough to understand what a lifestyle business was, that has been my goal: to provide a solid foundation for me to live my life on. I don’t want to become a unicorn, I don’t want to change the world (though it would be nice) – I want to live life comfortably, and enjoy it whilst I can.

It was therefore only natural that I would start my own business when the time was right and I had the opportunity to do so.  Fortunately, I was lucky enough to be able to do that recently and ever since (and before, albeit dreaming), I have been thinking about what project (outside of consultancy work) I should create.

At first, I was trying extremely hard to come up with ideas, so much so that I spent hours upon hours coming up with potential products that, in my head, were great, and the best thing since sliced bread.

Once I’d gotten an idea I thought valuable I’d spend even more time creating my perfect logo. I would then buy a domain, set up hosted infrastructure for my project and then start creating it.

The previous paragraph is one of many things that led me to write my popular article “The art of over-engineering your side projects”:

After getting two to three weeks into the thick of the project and getting to what I thought was a shippable version I’d push it to production, only to find that:

  1. Nobody knew it even existed.
  2. Nobody, other than the imaginary people I was thinking of when I came up with the idea, wanted my product or even had a need for it.

Looking back, it’s hard not to laugh at myself. I have repeated the aforementioned process two to three times, and it was only in the past few months that I realised I had been doing every possible thing wrong. People have literally written books on why I should not do what I was doing. But, the ego in an unprepared mind always prevails.

I had not validated my idea, I had over-engineered my project before I had even started and had came out at the end with nothing more than a bruised ego, a useless domain and an even more useless logo.

I then decided something had to change, and spent time researching the best ways to create a profitable business from an idea. One common theme was reciprocated in every, single, article and every, single, guide that I read:

Validate your ideas with your target audience.

Something so simple, yet something that you instantly look over when you think you have come up with the next Facebook, Instagram or AirBNB.

So, I took heed of that advice and spoke of my idea to colleagues at my places of work, potential clients and businesses – to check that my dreams of creating a successful lifestyle business were not clouding the fact that nobody had a use for my idea. Turns out they thought it was a great ideat that they would use and, after some more market research, have decided to launch the product in its most infantile version: the post-validation internet validation phase; where I want to check with people online that I’d be able to market the idea to them and potentially sell it to them.

Plans for the future

Naturally, there are many things that need to be done in order to turn this validated idea into a live, functioning product.

Firstly, and in parallel with the rest of the points below I need to continuously market the product. This means social media interaction with potential customers, blog post writing, search engine optimisation and targeted advertising. All things I have a little experience in so am excited to put those (rusty) skills to good use and hopefully learn things whilst I am at it.

Secondly, I need to create an MVP (minimum-viable product) to show to potential users (with it being open sourced I need not worry about ‘people stealing muh code’ or complicated legal agreements). With this, I can then incorporate their feedback into the first beta release that is suitable for production use.

Thirdly, I need to create a roadmap of features that should be in the product. I can then use this to create a shippable version 1. With this version 1 release, I’ll be able to incorporate masses of non-developer friendly documentation to give anyone, anywhere the ability to utilise the product.

Fourthly, and most importantly for a lifestyle business, I need to put in place a plan to monetise the product. With it being open sourced, it’s a little difficult (aka impossible) to convince people to pay for the product itself (not that I would want to do that!), so my current ideas are to sell support agreements and hosted versions of the software to people who do not want to invest in the infrastructure or tooling to host it themselves and those who need support and advice.

Finally, though perhaps unrelated to turning the idea into a live, functioning product: I’d like to blog every aspect of the journey to turn my idea for an open sourced project into a viable lifestyle business; something I hope many of you will be interested in.

If you are interested in reading more about my open source business journey – follow the business account on Twitter:

If you are interested in signing up for information on the product itself, visit the website:

Beginning modern application development with .NET Core – Part 0: What is .NET core?

This is the first post in a free series of tutorials on “Beginning modern application development with .NET Core”. To view the series, click here:

.NET Core is an exciting open source project from Microsoft that brings the power of the .NET development environment to all platforms without having to make use of a third party tool (like Mono). It is relatively new, with version 1 released in June 2016, and is fully supported by Microsoft as one of their first-class products.

The release of .NET Core brings with it a re-architected platform for creating modern applications that consists of the following components:

  • CoreCLR – the core compiler and base types for .NET programming languages (mostly written in C++).
  • CoreFX – the standard libraries, consisting of the main packages used in most applications.
  • DotNET CLI – a command line interface that brings powerful development tools to your favorite shells such as Bash and Powershell.
  • Roslyn – .NET compilers and code analysis platform that allows IDEs other than Visual Studio to provide a better development experience.

What’s different from the regular .NET Framework on Windows machines?

Well, to start with, .NET core runs on nearly all modern operating systems (including Mac, Linux, BSDs and Windows); so you can easily develop your software on Windows and deploy it to a Linux server (or vice-versa).

Secondly, .NET core applications are package based – so you pull in the libraries you need from a package manager and you don’t have to worry about installing the full .NET framework. Everything you need to run your application is shipped with it, making deployments easier to predict and making it simpler to keep all environments the same.

Finally, every component from the compiler to the standard library is open sourced; meaning if you face an issue you can very quickly raise it with Microsoft and community developers.

I’ve heard a lot about different “target platforms” – what are they?

When you develop a .NET core application or library you have the ability for it to target different platforms. There are three main ones, and each has a slightly different meaning or benefit to it than the others.

  • .NET Framework target – this targets the full .NET framework (i.e. .NET 4.6/7) that is only available on Windows operating systems and will therefore only run on environments where that runtime is present.
  • .NET Core target – this targets those applications that run on the .NET Core runtime.
  • .NET Standard target – (libraries only) this targets any runtime that is .NET standard compliant – if you’re using the most up to date frameworks, then you’ll be able to use projects that target this platform anywhere.

For example, if you created a .NET Core class library, you would only be able to use it in other projects that also target the .NET core platform.

However, if you created a .NET Standard class library, you would be able to use it within all projects that target a platform which complies with the .NET Standard.

I thought .NET core had migrated to using JSON files instead of .csproj files?

In the first few versions of .NET Core, the project setup and structure was indeed described within a project.json file. However, as .NET Core was adopted more widely within the eco-system, Microsoft needed a way for all platforms to work together, sharing one project file layout.

It was therefore decided that instead of modifying the tooling for all of these platforms to work with the new JSON format, the ones currently using it would be rolled back to utilise a modified .csproj XML format: one where the pain points experienced by many had been removed.

What will I miss if I migrate to .NET core?

There are a number of major items that are not available in .NET core.

  • WinForms – there is no WinForms support in .NET Core, so you will not be able to update your existing projects.
  • WPF – there is no WPF support in .NET Core, so you will not be able to update your existing projects.
  • WCF – it is currently not possible to create WCF services within a .NET Core application. You can still consume them using the WCF client libraries (, but if you want to build them you will need to target the full .NET Framework.
  • SignalR – neither the client or server libraries for SignalR are available in .NET Core (though they are scheduled for release with .NET Core 2.1).
  • AppDomains – AppDomains were discontinued as part of .NET Core.

How do I get started?

This post is the first of many in a series of how to begin modern application development with .NET. Follow along, and you too can build cross-platform applications with the newest framework from Microsoft.

Follow the series by bookmarking this tag. Alternatively, follow me on Twitter, where I will tweet whenever a new post goes live.

How to make your responsive mobile website hurt my heart

I think the most ironic part about responsive websites is that of the first word: responsive. It seems to have become a pattern wherein people take their over-complicated, bloated website: add a few media queries or use a few framework components and hide the elements that do not fit. The concept of optimising the website for mobile (which includes more than just the visible aspect) seems to have been ignored for about 70% of mobile websites I visit.

I was initially going to point out examples of bad responsive website designs: but, I’m not the internet police, nor am I always right; so it feels wrong to victimise websites that have made mistakes. Instead, I hope they read this article and think: “you know what? some of these apply to me”.

The points below are a collection of my most heineous annoyances with some modern, responsive mobile websites.

Unoptimised, image heavy pages

A mobile user’s worst nightmare: a page that loads multiple, large, unoptimised images on the page. Not only does it stop you looking for the content you visited the website for in the first place, it slows down the rendering of the finalised layout AND uses up your data allowance. If the web page has some sort of carousel without lazy loading, it wouldn’t take long to use up 10% of somebody’s 1GB allowance.

Synchronous web-fonts with no backups

Nothing is going to make a user as frustrated as them visiting your website, having the layout load and being unable to read any text. Why? The 23 fonts you are bringing in are done synchronously and without backups, making all text on the page invisible until the font files have finished loading in.

Research and multiple user experience tests online show that you have only a few seconds to capture your user’s interest: why would you waste that improperly loading a bunch of funky fonts?

Post-load DOM manipulation

So, the user waits the 5 seconds your site needs to load. They begin scrolling and suddenly, the entire page layout changes. Why? Because the desktop site that has been converted to a mobile site ends up getting “bodged” through Javascript to accomplish what should have been done properly in the first place.

Doing this is not only harmful for your end-user, but it also shows that you have a severe amount of technical debt surrounding your responsive mobile website (after all, if you’re having to resort to front-end hacks to accomplish something that could easily be done server-side, something is wrong).

Too much going on

The average modern mobile device has a screen size of around 5 inches. That means you have 5 inches of screen real-estate to fit your most important content on, regardless of the resolution of the phone. Too many websites fill this space with advertisements, pointless images and text that is irrellevant. If you purchased an advertisement board in your local super-market, would you waste 70% of your visible canvas on something that no-one will be interested in? No, you wouldn’t. So why should your home page be any different?

Scroll manipulation

Everybody knows their phone’s scroll speed, they know exactly how much of a swipe they need to make to get where they need to go. Websites that override this behaviour cause the user to get frustrated, something you cannot afford when first impressions count.

(this is also ridiculously annoying on desktop, but I’m trying very hard not to rant)

Sticky headers/footers

(thanks to drngdds for reminding me of this)

As mentioned previously, you have a limited amount of screen real-estate in which to sell your product/services/content or inform users of your goals. Having sticky headers or footers can take away this in-demand space and the focal points on your website. This will undoubtedly annoy your users, especially when the content they are trying to view is blocked by the header/footer elements.

This again is down to poor optimisation of the responsive mobile website; where elements are just hidden and no attention is paid to the experience the user will have on the website.

So – what can be done to solve these problems?

I think the solution to having an awful responsive website is to know your limits. If you begin experiencing performance or user experience issues with the “mobile view” of your responsive website: it’s time to make a change. Best practices are only best practices when they are applicable to you and your circumstances; they are not gospel. Release your website, speak to your users and adapt accordingly.

I really like the look of the accelerated mobile pages and the benefits they deliver, though I hate the idea of vendor lock-in and their ability to push their own agenda unknowingly onto their users. Instead, like the Wikimedia foundation are doing, I think it’s a good idea to implement their best practices in your own way. In short:

  • Render as much server-side content as you can.
  • Reduce/remove the third party dependencies you have on your pages.
  • Lazy load images whilst maintaining page layout.
  • Stop hacking fixes for your mistakes with Javascript.






The art of over-engineering your side projects

Many software engineers who develop software as a hobby often have side projects. The sad thing is, those software engineers often have the tendency to over-engineer their side projects, put all of their effort into mundane and, let’s be honest, pointless tasks and burn out before they’ve even finished their MVP.

Now, I don’t want to sound like a broken record, so I’m not going to preach ‘ship often’ to you, but I’m hoping that by reading this post you’ll be able to see the mistakes I used to make (and stop yourself from making them!).

Mistake 1 – Project managing

So, you have a great idea and a view of how you’re going to go about completing it. Logically, you will try to put together some sort of plan of approach. However, focus too much on this initial plan and you risk falling down the ‘project management’ rabbit hole: writing user stories, creating backlogs and finding tools for a project that you haven’t even started, let alone need copious amounts of rigid management for.

Solution: don’t try and project manage a non-existent project. Note down ideas and rough timelines – that’s it. If you start predicting what you’ll be doing in 2 months on the project, you’re not in Kansas anymore Dorothy.

Mistake 2 – Over-architecting infrastructure

You’re so hyped for this project and confident that it will succeed that you start thinking about the future: “how will I scale my application for the millions of users it will have?” “How do I ensure I have multi zoned redundancy?” “How do I keep 100% uptime? ”

“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!”

Now, reading that – you might think it sounds ridiculous – and you’d be right. Scale the numbers down though and it will probably sound familiar. So many people are guilty of over-architecting their application’s infrastructure before they even have that application in a state for it to be deployed!

Solution: Develop your project. Then, put it on the bare minimum architecture that it can run on (be that a 512MB instance from DigitalOcean or a medium instance on AWS). As you get more users, monitor, and modify the infrastructure appropriately to account for load and redundancy.

Mistake 3 – Worrying about “tech stacks”

The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. They don’t. A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are).

Solution: Write in a language that  suits the task at hand and one that you are comfortable/experienced with.

Mistake 4 – Creating custom frameworks

Bootstrap? Too basic. Materialize? Too fat. Foundation? Nah. Better create my own.

A made up statement, but relatively common nevertheless. I have many-a-time started a new project, thought the statement previously and set out writing my own framework. By the time I had completed it, I no longer had any desire to work on the project I had thought of in the first place.

Solution: Use frameworks and customise them – only refactor/build your own when absolutely neccessary (and when you have appropriate metrics).

Mistake 5 – Continuously delivering nothing

Similar to the way you can easily over-architect your infrastructure, it’s extremely easy to over-architect your continuous delivery practices before you have anything to deliver! Jenkins, Drone, Travis are all great tools – but you shouldn’t spend time configuring them until you have a working MVP.

Solution: Build your project first – then worry about continuous delivery.

It’s easy to believe you’re doing the best for your project by doing the above things but you aren’t. The best thing you can do for your project is to market, market, market, and then do a bit of development.

Edit: as many people on HackerNews are pointing out, this article focuses more on side-projects that people wish to use to generate income or turn into successful lifestyle businesses. If you’re working on something personal (with no plan to monetise it in the short term) or just for fun, then as long as you’re happy doing it – who cares!