Almost anything that can be automated can be done manually (or with minimal scripted automation) first, often with pretty good results. It's generally a good idea to start simple, and don't add complexity and extra work (like configuring/managing automation!) until you are addressing actual needs that you have... at that point, you can measure the pain to decide how much effort to put into the fix.
The first step to automated deployment is manual deployment using a checklist. Before automated unit tests, you have to write unit tests, and be able to execute them manually. Before automated rollback, you have manual rollback. Etc..
Are your developers able to run the entire project locally? If so, you are starting off with frequent local deployments, and if you encourage them to implement features in small steps and sync with version control after each step (i.e., at least once a day) then you also have achieved frequent integration builds - each developer is doing them independently. Next, throw in a script that executes all of your unit tests, and run that yourself daily (don't automate it into every build... that'll swiftly make them too slow and devs will start avoiding builds...), then email everyone when something is failing.
In other words, with a simple cultural standard -- don't hide in a hole and code for a week, and write unit tests! -- you have already solved (for a small team) most of what continuous deployment addresses. And you haven't put any time whatsoever (or spent money/time hiring someone) into setting up some non-trivial automation yet.
The other advantage is that by the time you are seriously ready to automate your build, it may be quite different from what you have now -- it depends on where your project goes, if you make a large pivot, mix in new technologies, and so on.
This solution might work for quite a long time; are there good reasons to implement continuous deployment instead, from the start?
Other than the cool factor, I don't think so.