Unfortunately the pay scale for state software developers never (I almost never say never) has a proper differential over other employees with the same level of experience, meaning they are often below 10th percentile of market rate, and thus the employees that end up in those jobs tend to be among the least skilled and motivated people I've ever dealt with. Even though contractors mess up, you can fire them. What's probably better is to keep a contractor available on an hourly rate for maintenance like this, rather than pay per change order.

I also find the government "requirements" process tends to create situations like this. Rather than build flexible software that puts some degree of trust in the person using it, they tend to overspecify the current bureaucratic process. In many cases, the person pushing for the software is looking to use software to enforce bureaucratic control that they have been unable to otherwise exercise, with the effect of the people the project initiator wants to use the software simply working around it. They then institute all sorts of punishments and controls to insure it must be used. This then results in the kind of insane situation we have here, where you can't do something perfectly legal because "computer says no".

> the employees that end up in those jobs tend to be among the least skilled and motivated

This. The job itself is terrible and as you mention the pay is terrible too. With conditions like that, I'm not surprised the product is buggy, over-budget, and difficult to improve.

If you're planning on breaking out of a certain contract-type or the other will be even more ridiculous, then consider putting out a separate RFP or having some special setup that allows you to just bypass or do the RFP at a higher rate. I'd recommend putting out an RFP for every project that needs it, even though it's a small number of the projects you're doing, and use that for the next project so the future RFPs won't get wasted. Otherwise you'll always run into these problems of a small number of big companies needing to get approvals because they're the one entity.

It gets complicated but there are some simple rules to follow. If you are running a non-competitive RFP then that might be okay because you are running a competitive RFP and so you get these opportunities to leverage your competitors, use one of the other competitive RFP rules for other projects, to use your competitor's RFP, etc. but you need to make sure the RFP you are running only does what the competition isn't allowed to do.

Having worked with a lot of contracted firms that do custom software development and platform customization, let’s not put them too high on a pedestal. What money you save on FTE programmers needs to be funneled right back into management talent to make sure they deliver a quality product (high utility, supportable by next contractor, quality docs, etc). Good management talent is hard to find and not something any government is known for. Consequently, next contractor probably has mondo ramp-up time deciphering what hacked pos the last guys put in with their c-team developers (cuz margins).

Isn't this what USDS and 18F are for?

I thought they were pitched as a service opportunity. Regardless, it's a small team that only operates at the federal level, state and local budgets are much more limited.

"Salaries at USDS vary, but don’t exceed $170,800, determined by your experience and skills." So, they do have a relatively low top salary, but it is very difficult to do any salary for the government based on skills versus age (disguised as years of experience). At best you might find adjustments for degrees earned, which don't translate well to actual value.

Sorry but this is just a question of balance.

Sure, it sounds like a public-sector employee gives better value but if you want to produce commercial quality then you still need management, consultancy and high quality HR with competitive salaries, otherwise you usually get mediocre developers with mediocre results.

Sometimes it really is better to pay a premium on the "day rate" to get something more quickly and to a higher standard. You also often have access to better support and maintenance.

You pays your money and takes your choice.

>than some state employed software developer.

Are you willing to pay market rates to retain that developer? Or deal with the constant churn as people stay long enough to pad their resume before moving along to the next job?