How to choose the best approach for your software development project

In this post, I will cover a couple of very practical tips on how choose the best approach for your software development project. It is important to start off your development project on a good footing, as this will set the tone, and impact you years into the future. This article is a continuation of a previous post – “How to reduce the cost of software development” – and I will continue along that same theme.

Be realistic with your timeframes

A developer will propose a development approach and outputs based on the (time and budget) constraints you provide them. If you are not realistic about your timelines, your developer may propose an inefficient approach, or sub-optimal outputs – and end up wasting you a lot of time and money in the long run. 

For example: Let’s say you have 5 months to deliver a project, but you tell the developer you have 3 months. You assume this is a good negotiating tactic because:

  • The developers will be more aggressive with their timelines
  • The more aggressive timelines would reduce your costs
  • You’re allowing for a risk factor, in case of things “taking longer” or “costing more” than you anticipated. So you want to add in some safety-buffer to cover yourself. 

Although it’s good to be conservative with your estimates, and setting some contingency time and budget aside – overdoing this could end up hurting you in the long run. Let me elaborate.

Continuing with the above scenario, a developer may propose an “out-the-box” approach – instead of a custom-build approach. The “out-the-box” approach may start presenting development constraints – 6/9/12 months into the future. At that point, you would be faced with a tough decision. Do you throw everything away and start from scratch? Or do you continue down the path and try to bend the “out of the box” solution to your will? What happens when you’re struggling to differentiate yourself from the competition because of the limitations of the decisions you made before? Or if you need to do a drastic pivot based on market feedback?

I’m not suggesting that a custom-build is always the correct choice, but by incorrectly stating your constraints, the developers will take certain approaches, off the table, and this ultimately limits your options. By being open, honest and realistic, the developers will provide you more, or at least more suitable options to work with.

How long do things typically take?

It would be helpful if you approach a development project with a sense of realism. If you have an idea of how long things typically take, and an understanding of what your various options are to approach a project, you will be empowered to make better decisions, and have more meaningful discussions with your developers. You will also provide them with some comfort that “you know what you are doing”, which would reduce their risk factor in doing business with them (which affects costs).

As an extreme example, if a customer approaches me, and asks me “how much money it would cost to build something like Facebook”, and expect a product to be delivered in 2-4 weeks – I would flag that customer as a super-high-risk proposition – because they clearly have no idea what they are doing. Yes, this really happens, all the time. 

Sizing the project – key features

To say it simply: keep it small. It’s great to invest a lot of energy into your big picture, and build out the product roadmap, but every project needs to start somewhere – you’re not going to build the whole thing at once. There’s going to be 1 key feature, and then some obvious, basic things you need to build to support that key feature. For example, if you want to build:

  • A social app, your core features could be user-profiles and a news feed
  • A commerce product, your core features would probably include something like a catalogue and products
  • A communications app, your key features would be profiles, and messaging infrastructure

Sizing the project – supporting functionality

Based on the above, you can make a couple of other assumptions:

  • You’re probably going to build an “acquisition” flow – attracting new users to your product
  • Users may need to create accounts, log-in, reset passwords, maintain their information
  • There will probably be a back-end with administrative functionality
  • There could be a website, mobile site and a mobile app
  • And you are highly likely to need analytics or custom reports – there’s really no point in building something if you cannot measure its performance

If you combine the MVP functionality and the “supporting” functionality, you typically end up with somewhere between 4-7 features – which would be your project scope. It’s very difficult to build anything useful with less than 4 features unless youre adding functionality to an existing product.

Options, Approaches, Timelines, Outputs and Typical Costs

There is some flexibility in how you approach a software project, depending on what you want to achieve, how much time and money you have. A typical software project usually combines a number of these processes, producing deliverables in succession.

Based on the same project scope above, here are some of the typical processes you can run, and what the requisite outputs could be:

Time Output Resources Typical Cost
1-2 weeks Wireframes UX / Designer $1,500 – $3,000
3-5 weeks User Interface Designs UX / Designer $2,000 – $3,000
4-6 weeks Interactive Prototype UX / Designer $2,000 – $3,000
2-8 weeks Out-of-the-box customised product Full team $10,000 – $25,000
10-16 weeks Custom-built “Minimum Viable Product” (MVP) Full team $30,000 – $75,000
12-22 weeks Custom “Minimum Marketable Product” (MMP) Full team $40,000 – $100,000

These numbers are indicative of course and will vary depending on the specifics of your project, but they give you the general idea of what you’re looking at.

What’s the best approach for you?

This topic warrants a full post but can be summarised as follows

  • Wireframes are good for “figuring out” your scope, and major user flows. This would also allow you to get closer to the real project cost – by reducing the uncertainty factor applied to the estimations
  • Designs help you visualise the product, and can be useful in gaining early interest in the product, communicating the functionality to visually oriented people
  • An Interactive prototype gives you a real feel for how the product would function, how users would find their way around the interface. Prototypes can be used in the User Research part of your project too. Making changes to your user flows and designs is still relatively low-cost and low-risk at this stage of the project, however, it’s not a necessary step to continue with the development
  • Out-of-the-box products are built on existing technology, that is usually intended for this purpose. A simple example is to use WordPress for a web CMS, Magento or Shopify for eCommerce etc. An out-of-the-box solution will get you going very quickly, but you may face some flexibility constraints at some point in the future. It’s typically an interim solution.
  • Custom MVP products are custom-built products. They typically take longer to build than out-the-box solutions, but they give you more flexibility to build upon for the future. An MVP product is not meant for commercial release, it may not be ready to scale, and completely polished from a user perspective
  • An MMP is ready to go to market and scale. It’s important not to confuse the MVP with the MMP – you will not be able to scale and roll out the MVP for mass consumption. The MMP is the product that you can start planning to monetize.

Approaching developers

Now that you have an idea of what various approaches are, and what you can expect to have as output, now you can start engaging developers.