Back in late 2012, my startup was growing fast, new clients were signing up and paying every day and we were starting to get enough sales to consider going off a ramen diet.

But we were also running into a serious problem.

Our system for organizing clients was cobbled together from several different pieces of software.

Some of the info we needed to run our business was online in web applications, some of it was in spreadsheets and some was still handwritten in notebooks. Our team was distributed, but big chunks of the information we needed to operate wasn’t.

The whole thing felt as though it was on the verge of falling apart under its own weight.

We checked out several web applications that were available at the time, but none solved enough of our problems to be worthwhile.

We needed to build and maintain our own software solution.

At a total loss for where to begin, I started reaching out to anyone I had contact with who was involved in software development. I talked to a local software-development agency. I got in contact with the developer whose software was already providing a partial solution to us. I called a friend of a friend who worked developing software. In all, I probably spoke with a dozen people.

Everyone was glad to talk, but most of them gave me warnings. From a flat-out “don’t do it” to “be prepared to spend twice as much as you want and have it take twice as long, and a lot of heartache.”

The general opinion was that building custom software was incredibly hard and usually went wrong even when people with experience handled it.

Despite the discouragement, my conversations did help me realize some very important things.

One of the most important ones was that I needed to hire someone to do build our software and stay with the company afterward, rather than have it done as a one-off job. There’s a lot of room for debate on this, but we felt we needed someone to be there when things went wrong, and to do updates, upgrades and bug fixes.

I resisted this idea at first. I wanted to build software, not hire another full-time employee. Also, I’d never hired a software developer before.

Was it the kind of job I could just post on a job board? How would I know if I was getting someone good?

I had to figure out how to get the right person for a job that would decide the fate of the company, but I had no idea how to judge a good hire for this role.

A lot of smart people recommend doing a job yourself for a little while before hiring someone for it. I think that’s a good idea, but in some cases, it’s just not feasible. For me, trying to build software would have been a disaster.

Ultimately, I just kept tracking down people who developed software, or who had hired developers, and asked lots of questions.

I think that, if you can’t do the job yourself, this is the way to go. You’ll get a quick education that will help you do it much better.

Making the Hire

After about 6 months of searching for someone to build my software, talking to people, and watching our business start to burst at the seams, I reached out to a former client who was the technical co-founder at a startup.

Going into the meeting, I thought of him as another good source of information.

He listened to the description of what I wanted to build, and then told me he’d just sold his startup and was looking for the next thing he wanted to do.

He met all the qualifications I needed in someone to do the project and already had a good understanding of our business. We had a professional relationship when he was my client, during which time we talked at least once a week over a six-month period.

After a couple weeks of talking, we signed a contract, and my company had its software developer.

About five months later, we had our software, too. It did take about twice as long as we’d expected but stayed within budget and delivered on all the most important features we needed.

The software has been through several iterations now and has helped the company manage tens of thousands of clients.

3 Takeaways to Improve Your Hiring

OK, I can see where this might sound like a pretty fortuitous hiring, something not repeatable.

But I don’t think that’s true at all.

Here are some lessons I think anyone can take from this.

1. Talk to people. Put the word out that you need to hire this position, and talk to anyone you can.

I had the luck of being a journalist for several years, so I was pretty used to calling and conversing with total strangers. I can tell you, though, if people are good at what they do and love doing it, they will be very happy to sit and talk your ear off about it.

The goal here is to learn as much as you can about the position. Find out how to judge if candidates have the right experience for it; know what pitfalls to look out for and what success looks like.

Also, ask for tips on where to find great people for your position.

2. Get it in writing. For this particular job, we signed a contract. At first I was inclined to skip this step, because I felt that I trusted the person I was going to hire.

But we went through with it and found the process of writing down exactly what should go into the contract revealed a bunch of misunderstandings and bad assumptions we’d both made.

Clearing these things up at this stage was quick and easy. Doing it down the road, once work has started and money has been spent, would have been awful.

If you’re not hiring the person as a contractor but as an employee, create a solid job description that outlines just what you expect of the position.

I’m always amazed by how writing things down helps clear up misunderstandings and crystalize goals.

3. Set milestones and do tryouts.
If you can, definitely do a tryout for any position like this. Look for a smaller task that needs to be done, that isn’t mission critical but will give you an idea of how the new hire works and what they’re like to work with. It’s much better than handing them a huge task that your business is dependent on and hoping for the best.

Of course, it’s not always possible to do this. In my situation, I didn’t really have any smaller tasks to be done first, so we did the next best thing and set milestones.

Milestones are good for both your business and the person you hire.

If you set specific goals for the first 30, 90 and 180 days, employees know exactly how they will be measured and what’s expected of them. Your business, meanwhile, knows what kind of work it can expect out of the new employee during that period.

With my software developer, we broke the task of building the software into a few key stages, then set dates and listed exactly what would be done when each of those stages were complete.

With a software project, tryouts and milestones may seem like an obvious part of the process, but these days I use them for any job I need to hire for, even ones I know inside and out.

All in all, hiring for this position was one of my better experiences as an entrepreneur, and trust me—there were some tougher ones! I know that hiring for a position you don’t know can be a bit scary, but following these 3 pieces of advice will take a lot of the uncertainty out of it and help you find the right person.

Paul Peters is content marketer and job ad writer with Betterteam. Before Betterteam he spent 6 years building an education startup, where he was was involved with many aspects of the business, including hiring. He lives in Whitefish, Montana.