What is a good develop, build, deploy process for a team of 3 developers?

The best advice to get moving is as said in his answer: start small and iterate. You'll be dumbfounded at how much a difference a little automation can make, and you will get addicted to it. I'd like to expand on that and hopefully bring the focus to developing quality software from the start. I have a background in larger systems, so I apologize if this all seems very 'big picture', but my hope is that by thinking this way now, it will empower you later. You will not always be three young developers. There are X-as-a-service companies for damn near anything these days, including continuous integration and cloud deployment stuff, so that's a non-issue on the hows and whys -- just do some Googling, read, pick one and go with it. There's a lot more to it than that on your end, though, and it mostly revolves around quality. A few salient points: quality is built in. That means during the application's development, not injected afterward. This is arguably the most important. pre-commit hooks. Make sure your syntax is right and that your local unit tests pass. No sense wasting time and resources if it won't build at all. vagrant or ec2 micro. Learn/use Vagrant, or otherwise make sure you're all working off the same image. Use http://packer.io to create images for both. automated builds. Use a build server like Jenkins, or a service like CircleCI or CloudBees if that makes sense for you. Jenkins is not without a learning curve, but it's worth it. the pipeline. Generally, your tests should be run in a go/no-go fashion in an increasingly production-like environment. Functional, in-house integration, full-stack integration, performance, regression, all with the closest possible settings as production would have. It depends a lot on the complexity and requirements of your applications, your users, and your environment. don't forget to actually write the app. You're not writing a mathematical proof of your application -- don't lose yourself in meaningless test-writing. If you are writing tests for simple accessor methods, you are doing it wrong. feature toggles. You should probably embrace feature toggles (ex. java's Togglz) as it will save you frustration both in the testing phases and more importantly, in production, where shit-to-fan collisions are known to occur. integrate against master. There are several workflows for this (check out git-flow, github-flow, and others). You're not really continuously integrating a whole lot if you still have 'merge days'. The extension of this process is by nature deployment, referred to as continuous delivery. Continuous delivery is really a balance between moving forward with features that are tested against all other live code and code in dev, (hence the term continuously integrated), but also keeping the software in a releasable state -- at all times. It is a comfortable feeling knowing that if the build light is green, you can ship. You know it works with all the latest updates and everyone's half-busted code, which is of course conveniently disabled by using feature toggles in the production environment (by your build/deployment server, no less!) While you might not think that all this matters for a crack team of three developers, I'd argue that it matters even more for you, as you can't waste time screwing around with bug-finding/fixing/production outages/deployment woes -- you need to be doing the opposite (read: making money and building stuff.) Martin Fowler's http://www.martinfowler.com/articles/continuousIntegration.html article is a good read, as well as the aptly-named book http://martinfowler.com/books/duvall.html by Duvall et al. For even more from the firehose, I suggest you pick up the book http://continuousdelivery.com/ by Humble/Farley. Hopefully this gives you a few concrete ideas of where to go next and a few new tools/concepts to think about in how you write software. Good luck.

I recommend http://blog.launchdarkly.com/feature-flag-driven-development/ or https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow (for a different manifestation of it).  But, make sure you don't accumulate too much technical debt while doing this. According to Atlassian, "Feature Branching: The Feature Branch Workflow still uses a central repository, and master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061 . The idea is to give a clear, highly-focused purpose to each branch."From the https://blog.travis-ci.com/2014-03-04-use-feature-flags-to-ship-changes-with-confidence/https://blog.travis-ci.com/2014-03-04-use-feature-flags-to-ship-changes-with-confidence/, here are the main benefits of feature toggles: Enable a feature only for a specific number of users, or even just for yourself to try it out in isolation. Trial a new feature for a sample set of customers to compare how they're using it compared to the previous version of the feature.This allows you to run experiments with actual users before you put it live. You can collect feedback and iterate based on real production usage. Enable it for your team to try out and give feedback on. At GitHub, this is known as staff mode. Next time you see a hubber in the wild, peek at their version of GitHub, I'm sure you'll notice some subtle differences. Enable a feature for a specific set of users, or just your team for them to try it out before it's rolled out for everyone. Getting Startedhttp://featureflags.io/ is a great resource to find current feature flagging libraries and information.