The following is an excerpt about development tools and processes from my book about building, launching, and supporting your own app, Starting and Sustaining.

Developing a hosted web application involves several moving parts, and if you’ve never been responsible for the full development stack and the process for your team, you might not fully grasp their value, but rest assured: now that you’re building your own company, you’ll want to involve these tools in your team’s process.

In almost all cases, I’d recommend setting up these tools the day that you start development—but I also recognize that can be overwhelming and occasionally even counterproductive. Nobody wants to spend all of their time configuring tools, and if configuring half a dozen tools would kill your momentum, then put it off a bit and add them as time permits.

Development is an ongoing process within a larger context; ultimately, design and development are pieces of a larger feedback loop. 1 The faster and more efficiently that your team can navigate the feedback loop, the better your product can become. Choosing the right tools that compliment your team, your product, and your process will help speed up that loop.

In some cases, it may be tempting to think that your team is too small and agile to need some of these, but you’ll find it easier to create good habits if you start with them. Invest in good processes and tools up front, and you’ll see countless benefits down the road.

Source and Version Control

This goes without saying, but most projects should be using source control. 2 If you’ve only ever managed a hosted instance of a blogging platform, you may not have needed source control since you simply updated your platform when they released new versions. But that won’t fly if you’re building a software company. Imagine what would happen if you were to lose all your source code or if you were to completely botch a significant module. If code is your capital, then source control is your vault. It’s more than that, really, but let’s keep it simple.

Your project’s source control system will probably be one of the first decisions that you make for your development process. Fortunately, there are quite a few capable systems for this with little setup involved. GitHub, Beanstalk, and BitBucket are some of the more popular options these days. The challenge is to pick one that works well for you and your team. Many of your development tools will need to integrate with your source control system, so I’d suggest selecting a system that has extensive options to play nicely with your other tools.

Release Automation

As as you start to write code, you’ll want to set up an environment that you can regularly release updates to. 3 While you may not want to share the application publicly, your release process will soon become one of the most important factors in determining how quickly and reliably you can release updates. The sooner you can incorporate a release process into your development, the easier it will be to extend it as your architecture expands. Getting a head start on your release process also lets you work out any kinks before you start your beta or launch your site.

One of the most significant benefits of a release process is that it forces you to think in terms of “shipping.” If it’s the end of the first day—or the end of the first week—and you’re already thinking about releasing a stable version of your application, you’re on the right track.

The main goal of release automation is be able to deploy code and to update your application with a single command. You may have additional commands for manipulating your servers, but if you have to manually intervene in your release process, you’re creating long-term problems. Start running releases as soon as you have a codebase, and stay on top of your release process.

Automated Testing

You might have heard people refer to “unit tests” or “specs”; these are forms of automated testing. Automated testing can be a touchy topic. On one hand, you’ll have some people who insist that you’re building software, not a test suite. On the other hand, some folks will insist that you need to write a failing test before you’re allowed to write working code. Wherever you fall on this spectrum, I’d strongly recommend that you use automated testing. 4

I had never written a unit test before I started working on Sifter. So I had to learn as I went along. When we launched, Sifter had about 55 percent coverage, which means that our test suite ran tests against 55 percent of our codebase. We’ve become much more serious about our test suite since then, and we’ve managed to increase our coverage to around 75 percent. If I could go back and change one thing, I would spend more time on unit tests in those early days. Unit testing has not only increased the quality of Sifter, but it’s also played a part in helping me to write better code.

Your testing framework will depend on the language and development framework that you choose. If automated testing isn’t your strong suit, I’d recommend setting aside some time to work on that—the benefits are immense. But whatever you do, don’t neglect it entirely. Your ability to rapidly evolve and to improve your application could be held back if you’re not confident that your new code isn’t breaking existing functionality.

Bug and Issue Tracking

You’ll probably want to set up a formal bug and issue tracking process. 5 Let’s face it: software will have bugs. You can’t prevent them, but you can do your best to handle them. Plus you’ll invariably have other problems and issues that aren’t necessarily bugs but still require attention. You’ll want a bug tracker to make sure that those problems don’t slip through the cracks.

There are several approaches to bug and issue tracking, and the one that you choose will depend on the size of your team, the technology you’re using, your personal preference, and the project’s technical complexity. Whichever approach that you choose, the important part is to make sure that your bugs are captured and tracked in a central, shared location. Some teams try to use spreadsheets or email to keep track of bugs, but these inevitably break down. I could write about this topic in absurd detail since Sifter is itself a bug and issue tracking system, but I’ll keep it short: just make sure that you have a system in place.

Continuous Integration

Unit tests only help if you’re running them. You can set up tools to monitor and test your code while you write it, but you’ll probably also want to set up a continuous integration (CI) environment. 6 With CI, whenever you update your source control system with new code, your continuous integration server will immediately see the change and start running your tests against the updated code. You may have heard teams talking about “breaking the build”—sometimes even having fines or penalties—if someone updates code in the source control system and their continuous integration environment reveals that it fails their test suite. Fortunately, like source control, there’re quite a few great new tools like Travis, Jenkins, and CircleCI that can handle continuous integration for you with minimal setup.

Code Reviews and Code Quality

You want to make sure that your team members review each other’s code. 7 It may be tempting to skip this process when you’re in startup mode, but it has several significant benefits. First and foremost, it ensures that you’re shipping higher quality code. Second, it serves as an amazing educational opportunity for team members. Finally, it helps ensure that no one is the sole possessor of knowledge for any one area of your application. You don’t need everyone to be an expert on everything, but you don’t want to be in a situation where one of the founders decides to move and you discover that no one knows their area of the application.

Many source control systems make it easy to review code—formally or informally—by commenting on the code in a web interface. There are several automated tools available to help test for code quality and even to look for security holes. With Sifter, we use and love Code Climate. It’s only for Ruby, but if you’re using another technology stack, I’d strongly suggest finding a similar tool.

Release Management and Environments

Writing code isn’t enough. You also need to get your code onto your servers. Enter release management and automation. 8 It’s easy to have an informal process in place if you have a small team, but if things start slipping through the cracks—or if releases aren’t running smoothly—you’ll want to invest some time toward improving your process.

Release management includes your continuous integration environment and your scripts for releasing new code. And I think it’s also worth setting up additional environments for testing your code, such as staging and quality assurance (QA) in addition to production. These additional environments should mirror your production environment as closely as possible. If your production site uses SSL, then they should too. If your production site is behind a load balancer, then maybe they should be as well. Similarly, they should run the same web server, application server, database, and any other software that your application relies on. Fortunately, if you’re managing your servers with the right tools—which we’ll cover in the next topic—this will all be fairly straightforward.

In addition to staging versions of your servers, you’ll probably also need to set up staging versions of your vendor accounts. For instance, if you have an external provider for your transactional email, you’ll want an account with them for staging and an account with them for production.

A staging environment serves two major purposes. First, it creates a shared environment where team members can test their code against a consistent representation of your application; this gives you a predictable and reliable version of your application that helps minimize the “works for me” problem. Second, it creates a production-like environment for testing any features that may work slightly differently in a production or staging setting than they would on a local development environment—this helps you detect any issues that might not otherwise be visible until you’ve released your code into production.

I can’t stress enough the benefits of a dedicated staging environment. Time and again we’ve been able to detect small production issues earlier and fix them more easily because we’ve had a staging environment.

Creating a High-Quality Culture

Some of these might feel like overkill for a small team, but the earlier these habits form, the easier it is for them to adapt and grow sustainably. Investing in these tools today will save you hours of pain down the road.

I’ve worked with dozens of teams over the years, and I’ve seen countless processes. I think it’s no coincidence that the teams with the best development processes produced the highest quality products and the most reliable results. The sooner these tools become part of your culture, the better off you’ll be.