Let's talk validation, briefly

The conventional wisdom on building software is to avoid it if you can. If you must build software, it should solve a really painful aspect of your business, and you should only build it after validating that people are willing to pay for it.

This is great advice, and in general it's a good thing. This post is not about validation — it's about what to do when, for whatever reason, you've decided to hire someone to build software for you.

Co-founder vs. agency vs. freelancer vs. employee

Someone has to build this thing for you. Ideally they are collaborative, have an ownership mentality, and don't cost a fortune. I have bad news on all these fronts: you're going to have to compromise.

Unless you have a really compelling pitch, finding a technical co-founder ranges from difficult to impossible. I won't belabor this point.

Choosing an agency will almost certainly get you the result you want, but it will cost a lot. If you're bootstrapping this is an instant dealbreaker, assuming you don't have mid five-figures to spend. Agencies do have advantages, however: they're really good at gathering requirements and finding great developers to execute against them. You're more likely to get a software that's well-tested and has less technical debt.

This leaves an employee or freelancer. If you're well-funded, by all means, hire an employee! Odds are, though, that you're not, in which case you need to find a freelancer to help realize your dream. Allow plenty of time for this step, but don't get started right away.

Get the product out of your brain and on to paper

Developers need requirements to work. They don't have to be spectacular or even completely fleshed out, but they do need to exist, and they need to be written down.

The minimum needed to get started is a set of wireframes covering the core functionality of the product. To produce these, use something simple and low-fidelity like Balsamiq. Alongside that, write user stories to explain further how it should work.

This exercise serves two purposes: it communicates clearly what needs to be built and it forces you to clarify your thinking. You'll find holes and functionality gaps, as will the developer with whom you're working.

Fit scope to budget

After you have clear requirements it's time to start cutting. In all likelihood you'll present the wireframes to your developer(s) and they will inform you that the project will take twice as long and cost twice as much. This is normal!

Here's what you do: identify every part of the product that isn't absolutely critical. If there are parts you can do manually behind the scenes then cut it. Think of this as the software development equivalent of losing your job: cut your "budget" down to only the essentials like food and shelter.

After you've cut as much as possible, work with your developer to prioritize the task list and start with the highest priority. This way if you run out of budget or time you can make the call to cut lower priority items if need be.

Get started; you're the tester

Now that everything is in place it's time to give your developer the green light to start building. Don't just run away and focus on other stuff! You need to keep track of your developers to ensure what is being built matches your vision.

It's your job to demand regular deployments to staging. It's also your job to thoroughly test everything, even if you've already tested it. Building good software needs more than one pair of eyes!