Outsourcing your code development makes a lot less sense with the radical changes in the way innovators now create software .

Over brunch in a cheap restaurant, a long-time MIT friend proudly demonstrated his latest start-up's software. The idea is clever, and its beta implementation is sweet. I liked it; usually the stuff I see turns my stomach. So I'm pleased that Hans Peter Brondmo's Web-based "personal information organizer" has technical chops and global business potential.

Then again, I usually pay close attention to Brondmo's digital designs. He's not an uber-geek who'd rather write code than chat up prospects. A reasonably successful entrepreneur, he's a get-it-done pragmatist who won't coddle programming prima donnas. He wants to hit the market cheap, fast and hard with products that aren't hard to upgrade or maintain.

So when Brondmo told me his software, called Plum, was the first time he'd done serious coding in over a decade, I was taken aback. "I couldn't believe how much things have changed," he confided. "When my development teams wrote code 10 years ago, it took us three days to find and kill a bug. Today, it takes us only three hours."

What's more, he continued, whenever his (geographically distributed) development team runs into trouble, they can usually instant message their way into a just-in-time partnership that simultaneously solves the problem while alerting everyone to potential conflicts. "We do better real-time collaborative development and review now remotely then we did back at MIT when we were all in the same building," he notes.

Brondmo's favourite development discovery occurred when he was stuck for a few lines of code. He realized that by Googling he could see if anyone anywhere had posted something he could use. He and his team found quite a few virtual solutions this way. "But what about context?" I asked. After all, not everyone documents their C++ in English. He dismissively waved his hand: "Code is code. I found something that looked like what I needed in the middle of what looked like a bunch of Chinese. You paste it in and see what happens. It worked."

The ultimate result? He's never done a start-up where the software development has been better, faster or cheaper. "In the past, I've had to raise lots of money to support the burn rate and the licences necessary to develop real software over a couple of years; the costs are huge," he said. "You had to deal with the venture capitalists. They had the money.

"Development cost is still significant, but it's now focused on value creation, not infrastructure development," he added. "Open source and the availability of tools reduce our infrastructure cost. We don't have to pay for expensive software licences and engineers to implement 'commodity' functions. So more money can be focused on innovation, not plumbing. We do more features faster. Development isn't really an obstacle."

Even allowing for hyperbole - perhaps Brondmo's "three days to three hours" time compression is really closer to "two days to five hours", we're still describing at least a fourfold productivity leap. That's impressive. Marry that to the evolving array of development-oriented communication, collaboration and search tools spilling into the global digi-sphere, and the serious CIO might want to delay that Bangalore RFP. The new economics of software development may have rendered India and China yesterday's fad.

Plum's provenance may not be typical, but there's nothing extraordinary about it either. A savvy entrepreneur is exploiting technical innovation to cost-effectively generate technical innovation. The stuff works. This is where savvy CIOs need to sit up and take notice. The implementation implications are enormous.

I'm the last person to suggest that busy CIOs should immerse — or, God forbid, reimmerse — themselves in code. But any CIO preaching the gospel of productivity better know if his organization's methodologies discourage — or invite — healthy experimentation with these nascent development platforms. A CIO should know if he can now consistently get a year's worth of software development in 90 days. A CIO should know if 75 percent of a project portfolio can go to value-added features instead of infrastructure maintenance. This matters.

Transforming the economics of software development completely transforms the economic rationales for outsourcing. Reducing both the cost and time-to-market of new features and functionality completely transforms a company's economics of innovation. Ideally, CIOs should "own" these transformations. Do you?

Three clear implementation transformation scenarios emerge. The first scenario is the easiest and most obvious: These development economics create a new generation of Salesforce.coms and other ASPs that offer suites of mix-and-match business processes for enterprise consumption. For example, while Brondmo has given little thought to Plum as an enterprise "knowledge management" platform, it could easily be adapted to become one. With a little goosing, it could become an "account management" app too. More choice, less money.