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).
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.
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".