How to start a Startup: Choosing a development strategy
Updated: Sep 14, 2020
You have a vision!
You have an idea for a software startup and may have written a requirements document. You may have done some designs (wireframes or full designs) and even a user specification. You may have knowledge of, or have researched, the problem space, market size, competitors etc. You may even already have some funding and possibly one or more prospective customers waiting to use your solution with the promise that development will be tailored to meet their exact needs. You now want to get to market as quickly as possible to maximize your chance of growth and success!
There is so much that you should and even more that you can do at this stage it can be quite daunting (but hopefully exciting too!). You can start documenting your solution (requirements, UX, information the solution works with). If you are technical yourself, you may start writing code (a proof-of-concept only hopefully at this stage)! If you are non-technical, you may start more along the business side of things, focusing on getting funding to pay for development.
In this article, I won’t cover everything; all the decisions you need to make, the considerations for each one, and the tasks you need to do. This is just an overview that touches upon some of the considerations and steps to turn your concept into reality. In future articles, I will go into more depth about some of these things.
From the perspective of technology, the general process that has always worked for me is:
No project/product that I have ever built or worked on has ever got it right the first time. You may have heard of the waterfall method and I'm sure you've heard of agile. Waterfall is intended for the perfect situation where there is very little to no iteration - this just does not work! Agile is an attempt to just wing it (IMHO), with many iterations and the idea that you don't need to get everything right the first time - in my experience though, this also does not work for new products; it leads to minimal requirements gathering and unfinished specifications. I believe that a balance should be struck. The more you can get right early on the more time and money you will save (and better quality you will have because this is almost always the trade-off). But, because it never happens, you need to plan for changes and iterations.
Experienced analysts and architects will attempt to 'future-proof' your designs, allowing for some unforeseen changes in the future but this is more of an art than a science (or engineering practice to be pedantic).
First things first
As mentioned above, there are many things you can do but a huge early decision to make is 'who will build my product?'. If you are technical, you may decide to build it yourself (with or without help). If you are non-technical, you need to decide if you will hire your own team or outsource design and development.
When thinking about whether or not to outsource, consider the following:
How quickly do you need to get started and finished with the product design and development?
Should you use the same partner to do the UX designs as the implementation?
Should you use the same partner to do the front-end (web app / mobile) development as the back-end (server-side)?
Is there a lot of know-how in your product design and development that may be lost when the partner hands over?
What is your budget? Can you afford office space and recruitment fees or is a fixed-cost solution better?
How detailed and clear are you able to communicate the requirements to prospective partners?
If you are planning to outsource, here are some of the considerations:
Do you know people that can recommend an outsourcer partner?
How much will the solution cost to develop?
How long will it take?
What is the quality of the work?
Will it be reliable (i.e. bug-free, fast enough and available)?
Will it be secure (e.g. protect against hacking, DDoS etc.)?
Will it be compliant with appropriate regulations?
Will it be scalable?
Can the delivered solution be operated and maintained/extended effectively?
What is the design, development, test, handover process?
Will you own the solution?
What is your recourse should the delivery be late or sub-standard?
Will the solution be exit-ready (e.g. well designed, implement and documented using best-practice documented processes)?
How do they handle changes to the requirements/designs?
What technologies can/will be used?
Whichever way you go and whoever you use to develop your solution, it is my firm belief that the more detailed and finalized you can determine your requirements, the lower will be your cost and time and the higher your quality. If outsourcing design and/or development, it also allows you to refer back if there are any areas that need adjusting if they don't match these requirements (without extra cost to you). 'Requirements gathering' as it is sometimes referred to is, again, as much of an art as a 'science'. It can contain anything you like (with the caveat that your requirements may not be possible (within time/cost budget at least)!) but is typically split into functional and non-functional requirements.
In a future article, I will go through some of the things you should include in a requirements document.
Please don't hesitate to contact us at Platform Gurus if you think we can help. Even if we are not the right partner for you, we pride ourselves in helping people get the right solution for them.