Clockwise from left: Dhrumil Purohit, Nirav Sheth, Don Bealer, Gil Hildebrand and Catherine Moles.

Last weekend the Hirefly team met up in New York City at Gil’s midtown apartment building. After discussing a few last-minute tweaks for Hirefly, we headed to Pure Food and Wine for an awesome dinner.

Hirefly is in private beta at the moment, but a few members of the Louisiana Technology Council got a sneak peek last Tuesday. At the LTC’s “Show and Tell, Tech Tuesday” event on June 17, 2008 we provided a brief presentation and demo.

We had some awesome slides to accompany our talk, but unfortunately the projector they had set up at the event prevented Keynote from entering slideshow mode. (There’s nothing quite like a technical malfunction at a technology council event.) After fumbling through a couple of embarrassing moments, we cut to the chase and showed the people what Hirefly can do.

The response was awesome! We ended up taking more time to field questions than we had spent on our entire presentation, and when it was all over, several people requested an invitation to the next round of our private beta.

Gil and I had spent most of the previous Sunday perfecting our presentation/demo routine, and even though it didn’t go perfectly, it’s good to know we’ve got it in the can for next time.

Over the last few months we’ve been working like crazy to get Hirefly finished. The big news is that a couple of weeks ago we were able to actually use and test a preliminary version of the software. It felt so great, and so strange…

… One of the tough things about building software is that you work for a very long time on an idea- and that’s all it is: an idea. You can’t look at it or touch it or show it to anyone. When you tell people about it, you never really know for sure if they know what you’re talking about. Then, one day, it exists. It’s there in front of you, it’s real, and you realize (hopefully) that it makes sense. The pieces fit together and it works and you stand up and throw your fists in the air and yell, “It’s ALIVE!!!”

Yep, she’s like our own little Frankenstein.

Last weekend Gil flew in from New York and we spent about 25 hours in my office over the course of two days rigorously testing, documenting bugs, editing copy for the user interface and generally making finishing touches. Now the folks at dboost are doing their part.

It’s looking like we’ll be ready to awaken our little monster any day now…

This is the third in a series of three posts introducing Hirefly to the world. If you haven’t read posts 1 and 2, please do so.

“Our splash page announcing that Hirefly was coming soon began to mock us. We had stumbled into a rut.” – Cat

Finally, in the Spring of 2007 we got sick of going through php programmers like paper plates and decided to really get serious about finding our ideal collaborator, no matter what the cost. We listed the job on the 37Signals gig board and collected responses for about two weeks. After reviewing resumes we grilled three freelancers via telecon. In addition, just to remain open-minded to all the possibilities, we decided to listen to a pitch from a development company. Before the interview, we hadn’t seriously considered going with a company like this. I mean, they’re outsourcing work to India. Surely it will be overpriced, the quality will suffer and their client relations skills will suck. Right? Well, we’ve been wrong before, so we gave them a shot. And their pitch was surprisingly impressive. It was impressive because dboost is a group of pretty smart people with some pretty smart connections. In the end, it was dboost who we hired to make the fly, well… fly…

This time around, we had decided to do a few things differently. Based on our experience, here is our advice to anyone who may find themselves in our situation:

1. Take the time to find a really, really good match. (Just having the right skills is not enough.)

We had always focused on one thing when we hired a programmer: How ‘good’ is s/he with the technology? Well, as it turns out, being a super fantastic php programmer doesn’t make you the best fit for us. We need a lot more. We need you to be a good communicator, too. We also need you to be there when we need you. We need you to make us one of your top priorities- in fact, we need to feel like we are your very top priority. And, you know what? We need you to care about our project, too. We need you to take ownership of it. We need you to want us to succeed.

(What do you need?)

2. Relinquish what is holding you back.

In our case, it was the platform. When we began building Hirefly, we saw it as EmployApp’s ‘little brother.’ So to build it, we just took a copy of the EmployApp code and ripped it up. We set out to build a ‘little EmployApp,’ so when we hired a programmer, we handed him a heap of code from an older software application and told him to adapt it. We never took into account that in doing this, we were practically ruling out the possibility of anyone ‘taking ownership’ of the project. In our new, more open-minded approach, we acknowledged this and forced ourselves to consider the idea of starting from scratch using more modern, more ‘exciting’ technology (from a programmer’s perspective). So when we interviewed potential new hires, we asked them if they would prefer building out an established framework in php, or starting from scratch with newer technology, like Ruby. Each interviewee enthusiastically preferred the second option.

(Have you overlooked something that may be holding you back?)

3. Tear Down the Walls!

Initially we had no interest in hiring a development company to build our software. Gil had been a talented, professional and successful freelancer. We wanted a young freelancer. We wanted to replace Gil. We wanted an exact replica of Gil! If only we could clone Gil… alas. We had to face the fact that we hadn’t found a replica yet, and we likely would not, ever. (They broke the mold when they made ya, Gil.) Yet our preconceived notions about hiring a development company were quite stifling. We couldn’t afford it, we thought. We’d go broke before we finished the project. We’d get scammed. We’d call them when we needed them, and we’d be sucked into an endless labyrinth of voice mail boxes. Well, talking with dboost changed our minds. And phew! I’m glad it did. Today the project is nearly finished, and neither Gil nor I have any regrets about our decision. The lesson: open up and be cool. Investigate all your options, even if you don’t consider them real options right off the bat. Tear down the walls that hold you hostage to your plan, and take a long look out over the horizon before you act.

(What confines you?)

This is the second in a series of three posts introducing Hirefly to the world. If you haven’t read post 1, please do.

It was a harsh lesson and a terrific opportunity at the same time. It may have taken us a few years to get there, but suddenly we knew not just what wouldn’t work—but what would. Knowing what you do best (and what’s impossible to do best) is half the battle.” — Gil

Katrina didn’t wreck us. It was our business model that did us in. Katrina just forced us to stand up and face our demons. Perhaps the fact that our lives were in mad, manic disarray made it easier, but in any case, we decided to change course. So, in September of 2005, during a late-night conversation on some of the first working telephones we had used since August 29^th, Gil and I began to discuss the concept that would become Hirefly.

We addressed the reasons we failed:

1. Technology vs. Sales (Sales Wins)

We are good at technology. We are not good at sales. Let’s build a product that doesn’t require a sales team in an environment where technology is valued higher than sales tactics (the Web).

2. Failure to Specialize in a Flooded Market

Let’s focus on small businesses. No one has ever done that with this type of software before.

3. Hurricane Katrina

Let’s build this new thing on a platform that will allow success no matter how far apart we are scattered geographically and no matter what else is happening in our individual lives. Let’s build something users create and manage without much intervention on our part.

The resulting concept: Hirefly, a micro-ATS for small businesses and individuals.

“Over the next few months we crafted a plan that would play to our biggest strength: developing amazingly simple, functional and useful software – and against our competitors’ greatest weakness: reaching people outside of the standard Human Resources Industry echo chamber.” – Gil

We knew the idea was brilliant and we knew it had never been done before, so we set out to build it. Our big challenge was that Gil could not do the programming work anymore. He had taken a job as the Chief Engineer at Squidoo and could not devote the time. We had never sought outside involvement before.

For 21 months from October 2005 to June 2007 we went through a heaping handful of freelance programmers and designers. We had funds, we knew what we wanted and we knew how to communicate what we wanted, but somehow we were never successful in getting what we wanted out of a freelancer. Each php programmer we hired had to spend time learning the concept and the code, and each person who worked on the code had his own style, his own technique. After someone didn’t work out, the next person who picked up the job would have to spend hours “cleaning up the code” and arranging it to his liking, plus learning the application before any progress could be made. Gil and I were too busy with our new jobs and new lives to micro-manage those we hired, and none of the programmers every really took ownership of the project. One by one, each programmer was either deemed unreliable, uncommunicative or too absorbed in other projects.

After awhile we had to admit that the project had completely stagnated. We were emotionally devoted, but we were also frustrated. Our splash page announcing that Hirefly was “coming soon” began to mock us. We had stumbled into a rut.

Stay tuned for our next post: “Back on Track with Ruby on Rails.”

Welcome to the Hirefly blog.

“The first thing you should know about Hirefly is that it’s basically the side effect of an attempt at something else. We created Hirefly because we were working so hard on a different project that we kind of fell down the rabbit hole, so to speak, and we landed here. But the fact that it took all that work to ‘accidentally’ land here- that’s the reason it’s going to be great.” — Cat

Hirefly is a little tool we built that makes the process of hiring simple and enjoyable. The Hirefly story began when Hurricane Katrina forced our small company to recognize our obstacles for what they were, and to find a way to bypass them completely, simply by doing what Katrina forced us to do in all the other aspects of our lives: start over. The purpose of this blog is to introduce Hirefly and share our personal experiences building and marketing the software. We hope that you’ll find the lessons we’ve learned through our successes and failures interesting and informative.

Our first three posts will tell the story of the conception and realization of Hirefly. From then on, we will share our experiences developing, marketing and implementing the software.

The first thing you should know about Hirefly is that it’s basically the side effect of an attempt at something else. We created Hirefly because we were working so hard on a different project that we kind of fell down the rabbit hole, so to speak, and we landed here. But the fact that it took all that work to ‘accidentally’ land here- that’s the reason it’s going to be great.” .” Our adventure began in 2003 when we first started researching and building EmployApp Enterprise, a web-based applicant tracking system for mid-size to large companies.

You see, we were seduced by what we perceived to be a viable, open market. Our friend and business partner, Don, owns a pre-employment screening firm in New Orleans that provides background checks for many of the companies that form New Orleans’ infrastructure: hospitals and health care organizations, utilities, the Louisiana oil & gas industry, etc. New Orleans being what it was and still is– a somewhat closed business climate (we deal with our own friends, family and neighbors) and somewhat behind, technologically speaking (practically third-world), we saw an immediate opportunity as a local provider of applicant tracking technology. Most of Don’s clients, though large, successful corporations, were not up to speed when it came to HR. That is to say, most of them still hired employees using the old system of paper job applications, MS Excel spreadsheets, fax and copy machines, filing cabinets and paper shredders. When we talked to these companies about the concept of EmployApp they were more than receptive. They begged us to build it right away. They were even willing to guide us through development, offering up their resources to our brainstorming sessions and beta testing.

So we did it. We built a state-of-the-art applicant tracking system (using php and mysql) for a pre-existing client base who guided its conception and development. Surely, we predicted, after this strong, local user base provides some road testing and success stories, we can take this thing national—even international! Right? No-brainer, right?

Well, right, but also – wrong, as it turns out. Many of the companies that were ecstatic about EmployApp during its development did sign on upon its release, with zeal. They are still happy customers to this day, and EmployApp does continue to grow and evolve.

However, after we landed those first contracts we hit an insurmountable plateau. In that sense, we failed. And you can learn from our mistakes:

1. Technology vs. Sales (Sales Wins in the Enterprise Market.)

We had performed a competitive assessment and determined that the market for applicant tracking systems was full—flooded, actually, with products. Many of those products were seriously faulted for myriad reasons. We believed that if we could build a better system, with the benefit of end-users guiding development, we could overcome the challenges of a flooded market. We did build a superior product, yet it did not succeed. Why? Because the business of enterprise-level applicant tracking software is not technology business; it’s a sales business, and we are a technology company. End users are enamored by great technology, but decision-makers (CEOs and CFOs) are not impressed by technology companies. They are impressed by sales forces with glossy brochures, seasoned sales reps and long histories. Given this obstacle, we didn’t stand a chance.

2. Failure to Specialize in a Crowded Market

While we slaved over EmployApp Enterprise, another company was building an applicant tracking system specifically designed for the health care industry. They launched just a couple of months before us and snagged most of the hospitals and health care organizations in our “guaranteed client base.” Oh, crap.

3. Hurricane Katrina and our Regionally-Specific Client Base

So, this one wasn’t so much our fault as the Army Corps of Engineers’. The levees that were built by the federal government to protect New Orleans failed, and unless you live under a rock in a subterranean cave, you probably know most of that story. Forces beyond our control ripped our city, our small company and our client base to shreds in August of 2005. You may think you can’t relate to this, but think again: Even if Armageddon seems unlikely where you live and work, there will always be innumerable forces beyond your control. You should at the very least estimate them and prepare a contingency plan. Our main problem after the Storm was that we were scattered and our priorities had necessarily changed, so our business model no longer made sense. Our three person “sales force” was no longer available to make sales calls.

There you have it. That’s the story of the 1-2-3 punch that brought EmployApp to its knees.

A note about item #3: The truth we had to face after the Storm was that even before Katrina, EmployApp Enterprise wasn’t going to make it, anyway.

Stay tuned for our next post: “It’s Half the Battle.”