Push aside the user stories, contracts, and legalities. When push comes to shove, the developer delivers the goods. In my mind, there is huge risk to a project with the role of a developer.


Let's be clear though. Every project has risks. Every project has some complexity behind it. What this means is that there is a dark art to the design decisions made by the developer. I've never seen a client accurately define what content types or modules need to be installed. Again, if they were that educated about what needed to be done, they wouldn't be paying you to do it. The developer must learn about client needs and be capable of making informed assumptions that lead their choices.


Some developers I have seen have tunnel vision. Given a specific task, they work in a bubble and only make choices mindful of the task at hand. A big picture decision would define the best choice for the project, not just for one part of it. This often leads to a good deal of refactoring when someone identifies this later in the project. This mentality must be avoided and can likely be solved through discussions and collaboration with others.


Regardless of the project complexities or decisions made, developers must show no weakness to the client. A developer has to demonstrate more than technical competence: they must maintain unwavering swagger. Risks may come up and they need articulated in no uncertain terms that the client can understand. The developer must be the beacon of hope, the problem solver, the rational voice.


Developers should strive to make the best design decisions with the information provided but not be afraid to make mistakes. This is the dark art: learning how to fail but still deliver and be confident throughout. Poor design decisions provide the needed learning opportunities to grow. Contractually, try to afford some additional time to limit stress. Developers should fail quickly, be prepared to readily change, and consistently present the swagger to reassure the client. That's your role, jump in and own it.