When you don't know what you don't know, decisions can come back to bite you, including whether to buy workplace software or build your own. The founders of San Jose-based recruiting technology start-up Hiretual found this out the hard way in late 2015 when they opted to write their own applicant tracking system (ATS). A project they estimated would take a couple of engineers two weeks to complete turned into a six-month nightmare that cost $300,000 in man-hours. It fractured the team so badly that two people quit.
"It was definitely a journey—a long, grueling journey," said Ninh Tran, Chief Marketing Officer at Hiretual.
At a time when even the smallest start-up can get off-the-shelf options for every conceivable human resources (HR) function for less than a couple bucks a month per employee, a small but significant portion of companies still take the do-it-yourself (DIY) route. Of 1,204 organizations in the 2015-2016 Sierra-Cedar HR Systems Survey, 12 percent said they used in-house or homegrown talent management software, including applicant tracking (AT) software.
"I wouldn't say that's widespread, [but] it's on par with some of the individual vendors we track," said Erin Spencer, a Research Consultant at Sierra-Cedar.
Good Intentions, Bad ConsequencesThe Hiretual team had good intentions. In Q4 2015, the company had 11 people, a different name (HireTeamMate), and a different goal: to create a virtual recruiting agency that would use artificial intelligence (AI) to match tech industry companies and job seekers. For that, they needed an ATS they could integrate into the AI they were building internally for the matching service. They tested some popular ATS for small businesses but concluded the platforms were too expensive or would require too much additional coding to integrate. So they decided to build their own.
That was their first mistake. Their second mistake was underestimating how long it would take to build the kind of ATS they wanted. Because they'd previously crafted a barebones ATS in a week for a different project, the company's CEO estimated needing twice as long (two weeks) to come up with the more sophisticated platform that met their requirements.
"Looking back, it was a trick to get everyone excited," Tran said. "One of the things we learned down the road: if you don't have firm deadlines, people will [slack off] and development will get slower."
Since they were creating an ATS from scratch, they kept adding features. That was their third mistake. More features meant more code and more code meant more time. The team blew by a revised mid-December release date. Instead of heading to their respective homes and families for the Christmas and New Year's holidays, they continued to spend 12 or more hours a day at the office, up to seven days a week.
The start-up-tinged enthusiasm for the project waned and then turned into burnout. To make the final, mid-January release date, they pulled three all-nighters. Two programmers responsible for creating the ATS's back-end infrastructure were so unhappy, they quit.
In March, the company pivoted to a new business model after deciding that a recruiting agency—virtual or otherwise—wouldn't scale as quickly as they wanted because of the time it takes to gain a reputation in the industry. While they still run HireTeamMate, the newly renamed Hiretual is instead focusing on building tech-based recruiting tools. Today, they don't even use the ATS they spent all that time and labor to develop, at least not in the way they'd intended. According to Tran, parts of it were cannibalized to run Hiretual's peer rankings and analytics.
Don't Do What We DidTran learned many lessons from the experience. Even after the software was released, it was so buggy it took another three months to clean up. "A lot of the code that was written in a rush was buggy," he said. "Once [programmers] stopped caring about the project, that's what happens."
Putting resources into creating software instead of buying an existing solution takes programmers away from other projects that might have been better to focus on in the long run. One engineer who quit was also building the companies' Android and iOS applications. Because the start-up didn't replace the departed workers, "we don't have an app," Tran said.
If you're building an app as part of a service you offer customers, don't publicize the release date until you're sure you can deliver when you say you can. Company executives didn't tell anyone but investors about the ATS project until after the New Year's holiday. Once Tran put out a press release, though, it was a line in the sand that programmers couldn't ignore—which led to the all-nighters.
Unless you're a Facebook, Google, or a recruiting agency using a homegrown ATS as its secret sauce, DIY software doesn't pay, Tran concluded. "If we had the foresight and went back, I'd probably save the time and all the resources we poured out," he said. "It was a very expensive mistake."