HealthCare.gov was meant to create a simple, easy way for millions of Americans to shop for subsidized health care.

Instead, in a little two more than weeks, it has become the poster child for the federal government's technical ineptitude.

A dysfunctional contracting system clearly bears some of the blame. But entrepreneurs in Silicon Valley likely would have approached the project differently from the start.

A week after the site launched, NPR spoke to Suzanne Cloud, a jazz musician based in Philadelphia. At that point, Cloud had spent hours on the site, trying to sign up for coverage. "Something went wrong, and it just went to a page with all kinds of html stuff," she said.

This week, Cloud says she gave up on the website and ended up registering by phone. The folks on the phone took all of her information — then asked if she'd like to pick out her plan online or receive information about her health care options via snail mail.

Cloud chose snail mail. "Once I signed up with the telephone, I didn't go back and try the site again," she said.

At 17 days old, HealthCare.gov has become a bit of a joke — even to folks like Cloud, who were eagerly awaiting its rollout.

So how could a roughly $400 million software project that had been in the works for years have so many problems at its launch? One bit of advice from Silicon Valley: Start small.

"It's not as if Facebook says, 'OK, here is our six-year plan for how we're going to make Facebook.com,' " says entrepreneur Ben Balter. "They build one feature at a time, and take a step back, look at how the feature is be used, before they go on to the next feature."

Balter says you build something small, you test it, and when it works for your users, then you take the next step. Right now, Balter works for GitHub.

"GitHub is a social code-sharing service," he says. "Think of it like Facebook for code. So instead of posting pictures of your kids or posting ... on Twitter what you had for lunch, you are showing what projects you're working on."

By sharing the code you are writing, lots of people can critique it, find the bugs, offer ideas and make sure it works. It's called open source, and Balter believes HealthCare.gov should have been written that way from the start.

"Why would you make that code private?" Balter asks.

But often when things don't work in government, the impulse is to duck and cover and clamp down on information.

"I think the key reason is the way projects get funded," says Michael Cockrill, who used to work in startups and is now the chief information officer for Washington state.

He says to get a software project funded in the public sector, typically you have say exactly what it is going to do, spell how much it will cost and when you will finish.

"As a result, you end up creating this culture that is all about doing what you said you were gonna do," Cockrill says.

It's a culture that is risk-adverse and terrified of public failure. You can't learn from little failures or adjust course midstream. And instead of taking big jobs, breaking them down into small tasks and testing for success at each step, a project like HealthCare.gov becomes a giant all-or-nothing gamble.

Cockrill says too often it's a gamble taxpayers loose.

"You've made all these commitments about what you are going to build. What is it going to look like upfront," Cockrill says. "And even if the market changes underneath you, and even if your customers need something different — which you know always happens — you made a commitment a big public commitment, and they've written it into budgets and law."

Cockrill and many others around the country are trying to help governments become more flexible and agile as they embark on software development projects.

"It's really hard to convince people to kind of trust you," he says. "Especially when you are saying, 'Look I don't know exactly what is going to look like — but we are going to do what matters most first.' "

Copyright 2021 NPR. To see more, visit https://www.npr.org.