You make a big, bold bet. You bet wrong. You mess up. Now what? Figuring out when it's time to cut your losses is never easy. When it involves pushing aside your handpicked team, the decision is all the harder. That's exactly the bind Steve Sarowitz, the CEO of Paylocity, was dealing with.

Sarowitz's story began one chilly spring morning in 2003. This was to be the day that saw the transformation of his company from a mere supplier of payroll services to one that sells its own proprietary software. When he left his office in suburban Chicago the night before, he was confident that his new software would be up and running for one of his company's biggest customers, a company with more than 1,000 employees.

What Sarowitz woke to instead was disaster. The data had never fully loaded overnight. As a result, his customer's employees couldn't see their pay stubs when they logged on. "I was spontaneously combusting," says Sarowitz. Soon, he was huddling with his project development chief, Roey Ben-Yoseph. "Roey, what's going on?" he asked. "I've got a thousand people who won't be able to see their paychecks like I promised." Ben-Yoseph, both men recall, quickly replied, "Steve, we only tested it for a maximum of 100 people."

Sarowitz couldn't believe his ears. OK, he hadn't specified the scale he wanted. But wasn't it obvious that Paylocity's new software program would need to handle more than 100 employees? The company already had several customers with more than 1,000 employees. Why on earth would his development chief have created software that could handle only 100?

When Sarowitz set out to create his online payroll software in 2002, he was sure that he and his team could provide a cutting-edge, money-saving new service for his customers. The idea was to nibble away at the giants in the industry, notably ADP (NASDAQ:ADP) and Paychex (NASDAQ:PAYX), which were pulling in billions of dollars in revenue but hadn't yet succeeded in offering a strong Web-based product.

Sarowitz, then 37, had taught himself how to customize software he was reselling for another company called MPAY and figured he had the tech know-how to spearhead his own software project. Plus, he could tap the expertise of Ben-Yoseph, a friend since college days at the University of Illinois whose programming skills had helped Paylocity build a Web service that worked with MPAY's system.

As 2003 progressed, however, it became clear that Sarowitz was asking his development team to produce a product far more ambitious than it had anticipated. Sarowitz found himself butting heads with the programmers over nearly every detail. "One of the developers wanted to give direct deposit accounts friendly little names, like My Checking Account, and I said that's going to complicate the program," says Sarowitz. " 'Well, I like my idea better,' " Sarowitz recalls the developer's saying. Sarowitz shot back, "You're a developer! You know nothing about this industry!" Ben-Yoseph, looking back on the experience, says Sarowitz had unrealistic expectations and frequently demanded more than the team could deliver. Says Ben-Yoseph: "Steve kept changing directions."

About the only thing Sarowitz felt he could control was his morning running routine, which he used to clear his head and confide in his running partner, Tim Hendershot, a trust officer at a Chicago bank. "If I asked for a peanut butter and jelly sandwich for lunch, they'd say they couldn't do it," Sarowitz complained to Hendershot at one point. Says Hendershot: "He vents, and I just run along."

As summer turned into fall, Sarowitz began to face the facts: He had made some bad calls by betting that programmers with limited Web experience could create an advanced Web-based program. He knew, too, that he had been wrong to assume he was skilled enough to oversee a full-scale software development project while running the rest of the business.

Sarowitz knew he needed to make some big changes in staffing and strategy. He deeply wanted his Web strategy to succeed, but his gut was telling him the project was off course. He had just spent 18 months and more than $1 million on the project. He didn't want to see all that effort and money go down the drain. Could he replace his team with new software developers to patch up the problems? Or was it time to cut his losses and pull the plug?

The Decision As it turned out, Ben-Yoseph, too, wanted to make changes. In early October, he came to Sarowitz to tell him he wanted out of the project. The two agreed that Ben-Yoseph would help find his replacement, then step down to a programming job to help with the transition.

This time, Sarowitz wasn't going to make another hiring mistake. He retained two recruiting firms and put ads on technology job sites like Dice.com. He spent three weeks interviewing dozens of candidates. He ended up choosing the second person he interviewed: Chuck Cooper, who had 17 years of experience running major software projects at software vendors and at large companies like Washington Mutual. Cooper came on board in December 2003.

"I messed up," Sarowitz told Cooper on his first day on the job. "And I want you to fix it." Cooper soon discovered the six-person development team was split down the middle over how to get the program back on track. "Both camps were wrong," he says. Just as troublesome was the lack of any real process. Feature lists were often written down on whiteboards or on napkins, only to be erased or lost before anyone had a chance to implement them.

Everywhere Cooper looked, he saw problems. The system often crashed, and the design left no possibility for creating the simplest of new features, like buttons that allow users to choose from a list of options. His conclusion: Junk it all, and start over again. Sarowitz was relieved. Deep down, he knew it was the right decision. "It was exciting to realize we could have a fresh start," Sarowitz says.

That fresh start included replacing most of the software development team, including Ben-Yoseph, who departed on friendly terms and now works as a software architect for a Chicago technology firm. The five new hires, each with plentiful Web programming experience, soon paid off: Code development went reasonably smoothly this time. Cooper's team, without being asked by Sarowitz, designed the new system to work for companies with as many as 10,000 employees, far larger than Paylocity's biggest customer. It took another year and nearly another $1 million to develop the new program. Profits from Paylocity's existing payroll processing service continued to foot the bill.

In late 2004, Paylocity started rolling out the new software. The first version, later named WebPay, had the usual kinks, but Cooper's team was able to fix them. Even for its 1,000-employee customers, data transfers took about two to three minutes, a whole lot better than the eight hours they took on that dreadful night in 2003.

Sarowitz says about 75 percent of Paylocity's customers now use its WebPay systems; the rest have stayed with MPAY's product, which Sarowitz continues to resell and support. Sales, growing at 35 percent a year, are now about $20 million a year. (One of Paylocity's 3,700 customers is Mansueto Ventures, parent of Inc. magazine.) Of course, that's still tiny compared with ADP and Paychex. The recession, moreover, could quickly cast a shadow over Paylocity's future.

Still, the company's success has recently attracted $10 million in expansion capital from VC firm Adams Street Partners. If Paylocity had not developed its own technology, the firm wouldn't have been interested, says Adams Street partner Jeff Diehl. "It tells you a lot about someone when they can admit a mistake, recognize a sunk cost, and restart."


The Experts Weigh In

Watch for red flags

People often fall victim to what I call the sin of arrogance. They don't take the necessary steps to make their software project go well, and in particular, they don't look at whether the people they have are capable of doing a good job. You can't just assume they will grow into it. There are clear red flags. One such flag is failing to set up metrics so you can measure progress. A great way to break this pattern is to establish steppingstones, smaller pieces of the project that can be done rapidly to force communication about the project.

Jim Johnson
Chairman
The Standish Group
Boston

Letting go is never easy

The decision to kill a project is very difficult. Psychologists tell us about "escalation of commitment." People think something is fixable, and that makes it hard for them to kill a project. It's easier to rationalize continuing something than killing something. You think about the sunk costs not only in terms of money but in terms of time -- success is right around the corner, and companies throw good money after bad money. So to pull the plug on it, even though it was a costly decision, speaks a lot of Steve Sarowitz as an entrepreneur.

Julio De Castro
Management Professor
Babson College
Wellesley, Massachusetts

Hire slowly, fire fast

When you are building software, it's harder than other kinds of goods, because it all builds on the same foundation. If your base isn't good, you have blown it. You not only have to redo the product, but you have to figure out how to migrate customers to your rewrite. It's excruciating. The biggest lesson you could learn from this is that all the good intentions, all the "I can do it, boss" energy -- all that doesn't matter if you don't have quality people. You have to hire slowly and fire fast. Sarowitz learned that the hard way.

Michael Braun
CEO
Intacct
San Jose, California