The five largest variables to consider when building software are 1) budget, 2) timeline, 3) project scope/complexity, 4) spec clarity, and 5) project management skills.
These constraints and resources will determine whether you should build the project in house or not, where you might outsource work to, what platforms you’ll initially launch with, how you’ll get your initial users, what features your product will have, and many other outcomes.
The most critical thing to realize is that you can’t have it all. You can’t build a $200,000, complex, cross-platform app in 2 weeks for only $10,000. And if you have a completely undefined spec and no clue who will manage the project, you’ll probably pay twice that amount.
For some, you’ll be able to sacrifice on budget, but get everything else you want. For others budget is the only place you can’t sacrifice, but you still need a high quality product. But it’s impossible to have it all since these outcomes are at odds with one another. Anyone who tells you otherwise is lying to you.
What’s critical – no matter what your constraints are – is that you have the right strategy for your situation. Most people who haven’t built a few things before run into issues: get talked into the wrong strategy, get ripped off by an unscrupulous developer or agency, or don’t have a game plan at all. But all of these scenarios can be mitigated with a little preparation and experience.
Common Situations:
1) Budget Constrained
2) In a Rush
3) Huge project, can’t fail
4) Lacking product clarity
5) Need to Find Developers
For the rest of this article, I’ll walk through my preferred strategy for each of these major scenarios and I’ll list a few less common scenarios at the bottom as well.
1) Building software on a limited budget
This got so long that I wrote an entire article on it. Here’s the gist:
– Make a thoughtful budget with realistic contingencies built in
– Outsource, preferably outside of US, to reduce costs
– Scoping is everything – it will make or break your project
– Move as quickly as possible (sprint) but be flexible on your timeline
Check out the whole article here.
2) Building software quickly
In my development business, I’ve successfully completed projects for clients on deadlines as short as 6 days. Miracles are possible, but they’re not free. The cheapest, easiest, and best way to get something done faster is to simplify the spec. And, depending on your budget, you may not have any other knobs to turn. Finding high quality developers on short timelines is not easy so if you’re waiting for designs, feedback, money, or whatever before you start talking to people about getting your project built, you’re setting yourself up to get gouged at the last minute. Start talking to experts now.
No amount of money can buy back time and no developer – as skilled as he or she may be – can reverse time. If you’re thinking about a project and it has any sort of deadline, you’ll be much better off if you start talking scope, budget, design, technical requirements, etc sooner than later.
3) Managing a huge project that can’t fail
Big projects are the worst – unless you break them up into smaller projects that can be managed. If circumstances allow, build each bite-sized project in series instead of all of them at the same time. Project managers become even more important when working on bigger projects.
4) Starting a project without enough clarity
Stop. Do not pass Go. Do not collect $200. You need to start getting clear about what you’re trying to build immediately. I’m very process-driven and find that projects perform poorly when they’re not rooted in a clear and efficient process. We’ve documented and published our process for anyone to use.
5) Struggling to find the right developers for your project
Finding the right developer for you can take months – developer schedules are almost always hectic, deadlines are constantly moving, we often need to rest & recover mentally before beginning a new project, and we usually have a few projects going at any given moment (or maybe even a day job).
Less Common Scenarios:
6) Great in-house development
If you have great developers but need some help managing your project, then you’re in a great positions. You need to make sure you have a very well-defined scope and spec. Someone needs to project manage – facilitating difficult design, technical, product-market fit, and business decisions. The process my team and I have followed for years to build iOS apps is detailed here and I also help teams in this capacity from time to time. Take advantage of my free consultation and hit the ground running.
7) Learn to code
Depending on the language you plan to learn, make sure you plan to study 4 hours per day for between 6 and 18 months before you want to launch. Most people either start to gain confidence or give up about 3-6 months in so make sure you plan to try at least that long. I’ve written about how to learn to code in detail here.
When considering this path from a purely financial perspective, make sure that you’ve compared the time it would take to earn the money you’d need to pay a developer to the time it will take you to teach yourself a new skill. I give this advice as someone who actually taught myself to code starting in 2010 and the skill has proven to be immensely valuable and enjoyable to me. Just be aware that many people set out to learn to program every year and very few are realistic about the commitment it takes just to get decent, let alone highly effective.
8) Technically challenging (high security, disallowed functionality, complex algorithms.. etc)
If your project contains real technical risk, then you absolutely need to have experts on board. Almost always, your expert won’t be the same person as the generalist who will actually put all the pieces together – for both cost and skill reasons. The vast majority of projects I hear about don’t have much serious technical risk but if yours does, then you probably need to de-risk as much as possible before building anything. If you’re in this situation and need some guidance, let’s chat.
9) Extremely well-scoped
If you’re a Google-trained PM (or similar), then you know how to scope a product, write a technical spec, and work with technical people. Finding the right developers is probably your only remaining hurdle. Just don’t forget your training.