How Software Development Works

Have a software idea but don’t know how software development works?

Then this article is for you.

It’s exciting when you come up with an idea for a new software or app.  Figuring out how to get it made can feel overwhelming.  Before doing anything else, I recommend learning a bit about how a a software development project works.  This way you can start with a basic understanding of how software development works.  You’ll soon see that this is something you can figure out.  You have a lot of options and don’t need to be a coder to make software.

Idea, Refine, Research

You’ve got an idea for a new app or software – awesome!  Before jumping right into hiring someone to do it, there are some things you can do first.  First, think in detail about the idea – what problem are we solving?  Who would use this?  Why would using this be easier than using something else?  What else is out there that does this?

Refine the idea to make sure you answer these questions.  Research what else is out there, and have an understanding of how you’d want to do things similarly or differently.  Don’t worry if you find other things very similar to your idea – this almost always happens.  The question is do you have a plan to make that better/easier for users?  If you go through this process and decide you want to proceed to developing something – the next step is to figure out how you will find the person or company to actually build the thing.

Want some inspiration?  Check out this article to help get the juices flowing.

Find someone to make the software or app

If you can’t make software, then obviously you need to find someone who can.  We’ve covered this in detail here and here.

Do a feasibility study

Before doing anything else, we need to make sure what you want to do is actually possible.  The feasibility study is confirming that it is possible to make the idea happen.  For example, if your idea is to make an app that will let you print any picture from your phone onto toasted bread – we would need to research if any toasters have Bluetooth technology and the ability to process data from phones.

Outline Requirements

The requirements are a detailed list of all the components you want in your app or software.  The initial draft should include anything that you may want to include, in one place.  If you might want something in the app, this is the time to include it in the plans.  As a quick example, the requirements of a simple registration form may look like this:

  1. User enters First and Last Name (mandatory for user to complete this)
  2. User enters email address (mandatory)
    1. Once form is submitted, system sends a confirmation email to user – user will click to confirm, only then will account be active
  3. User enters password (mandatory – must have 1 special character and 1 numeral in password)
  4. User re-enters password (mandatory)
  5. User clicks submit (once form is submitted, email is sent to user to confirm address, after that confirmation happens the user can now login using the email and password they listed in the form)
    1. Email to user include link to the login site, a button for user to click to confirm, after which they will be directed in their browser to the login page.

The initial requirements will be a long and detailed document.  And, this is important, you will CUT the scope down as you go along.  We strongly encourage you to think about stating with a minimal viable product, or MVP.  To get there we’ll need to cut out the things that aren’t essential to start.  The result is that you’ll end up with requirements for your MVP, which lists in detail the specific components that we want to build to start with.

Scope – Time and Cost Estimate

The next step is to create the road map for making the software, which is the scope.  The scope includes:

  • How much time and effort each item in the requirements will take
  • Allocating who will do what
  • Setting a schedule for what sequence the work will be done in
  • Estimating some breathing room for unexpected challenges or changes in plan
  • Estimating the cost for this project

The scope will vary depending on a variety of factors, including how many developers are working on it at once, what their rates are, etc.  Software developers often work on one of four pricing models: full time salaried, hourly billing, fixed monthly retainer, or fixed project fee.  It is very important to keep in mind that whenever you change the scope of your project, additional time and costs will almost always be needed.

This is why it is important to put a lot of thought into this process.  Understand that even things that seem like small changes may require a lot of work.  The ideal scenario is to deviate as little as possible from the scope.  Want our help scoping your project?

Front End/Back End Development:

This is when the work actually starts on building your app or software.

Front end development refers to building the things that the user will see on their screen.  This includes the design, button placement, icons, colors, features, etc.

Back end development refers to the stuff going on behind the scenes.  Think of how the software will store data, how to process algorithms, etc.

For example, let’s think of an app to order food delivery.  The front end includes:

  • The visual way  you see the menu on the app (is it a pdf, or clickable menu, etc?)
  • How you add an item into your cart (do you hold and drag it, do you press a plus button?)
  • Where you enter payment information (do you click on a button that says ‘pay?’)

The backend work would include:

  • How the app communicates with restaurants to update the menu listings (are they entering it manually, or sending a spreadsheet?)
  • How the order gets from the app to the restaurant (does the system email them the order?  Does it text them the order? How does it do these?)
  • How the credit card information is processed (is our system communicating with Paypal to pay, or are we processing credit cards?)
  • How the order progress is sent to the user (does our system send the user an email? Does it text the user?  How are we doing this?)

When building an app or software both of these are equally important.  It is also important to note that often software developers tend to focus on either front end or back end.  It’s important to keep this in mind when building your team.  One benefit of hiring a company is that they will usually have different people with these different skills.

Setting up the Architecture

Your app or software is going to need an infrastructure to support it, which is the architecture.  The architecture is the design of this infrastructure.  Think of this as the frame of a house.  What connects to what else?  Where does data live?  How is information transmitted between different elements of the software product?  The architecture needs to be built with your business goals in mind.  For example, If you envision having a huge number of users quickly, you need to build your software to be able to process this much use.  You might take decisions that maximize high numbers of users and speed.  Doing so may mean you need to compromise.

As an example: your software sends text message notifications to users and you expect to have 10,000 users.  Building an infrastructure from scratch to do this can be very complicated and unstable on a tight budget.  A better option may be to integrate a third party tool into the architecture that sends SMS notifications for you, with no limits on how many texts are sent.  This will make your product scaleable – you can grow users and handle the texting needs.  It may also create some restrictions/issues.  For example, the third party may start charging when you exceed 10,000 users.

It’s important to understand that changing the architecture after it’s built is very difficult and expensive.

Testing/Bug Fixing

Once your app or software is built it is time to test! You can do this on your own, ask friends to help, or even hire a company to test for you.  You will always find errors, or bugs – that’s to be expected!  You probably want to do a few rounds of testing and get as many eyes on the app as possible so that you can list these and fix them.  Remember to test using different devices (Android, iPhone, tablet, laptop, different web browsers, etc.) and to try every feature in the app.

Going Live

Once you’re confident that you’ve fixed the bugs that you can find, and want to get the app or software out to users – it’s time to go live.  This means making it available to users. If this is a web application living on your website, going live can be as simple as flipping a switch and making everything public.  If you’re building a mobile app keep in mind that you will need to go through approval processes to get into the Apple Store or Google Play Store (and that these have additional costs).

Final Thoughts

The steps above are the basic steps when building an app or software – of course there are more variables that can come up on a case by case basis, but this is the basic process you should expect.  It’s important to have a strong and detailed plan.

Two final things that I’d like to emphasize are that changes to scope can really impact a project, and that bumps in the road will happen!

If you are working off of a specific scope, making changes later to the specs of the project can be very difficult.– It is very important to put lots of time and thought into your scope.  Even  things that seem simple can be complicated to change.

The other thing to keep in mind is to expect bumps in the road and be ready to roll with the punches.  Developers make very detailed plans and estimates, but often times things happen that were impossible to expect.  For example, you may be integrating your app with a popular social media site – and after you’d done the scope the social media site changes the process for integrating data, meaning your developers will have to figure out the new changes and may need to take other steps to comply.  Delays and setbacks happen, but a good team can almost always figure out the way forward.  It’s important to build some ‘padding’ or extra time and funds into your scope to anticipate unforeseen changes, just in case.