I'm coming to (near?) the end of what can only charitably be called a "difficult" project. Unfortunately, I don't think I will be working with any of the parties involved in the future. For future readers and my present sanity, this feels like a good time to define what I don't do for a living; sometimes that negative space tells more about a thing than the thing itself.
I don't work without specifications (requirements). Real specs, not three pages of bullet points in Microsoft Word. You don't have to know it all when we start and it's part of my job to get those requirements right, but it is a bad idea to put hands to keyboard before I know exactly what I'm doing. Every development project changes in definition from when it starts. That's the beauty and pain of requirements. You sit down thinking it's stupid to have to tell me what to do and then we start talking about what to do and the conversation chases dozens of tangents. Ratholes appear. Better to find them up front and deal with them (or pour concrete down them) than find out "Later".
I don't put together the requirements without talking to you. I don't know your business, you do. Even if you just got hired last week and this is your first assignment, you still know better. You know who to ask (and who the office gossip says to avoid), you know where to go for answers outside your company and you know how to ask relevant questions that get helpful answers (compare and contrast with my: "So how do you guys ship stuff to people?").
I don't build the system for you. I build it for your customers, your users. It's rare that you're going to be a perfect example of your customer and even then, no. You can't serve two masters (the application vs. career success). This doesn't mean every project has to involve one-way glass, video cameras, white lab coats and a testing facility, but it does mean putting together some kind of test, even if it's just simple hand drawings of screens to show to random folks in the hallway to make sure we haven't missed something glaringly obvious. Oh, and about those paper protoypes: I don't work without some kind of screen mockup. It doesn't need to be the Sistine Chapel. It doesn't even need to look like the final screen. We just need some kind of reference so when I hand in my work, there's an agreed-upon set of things that should be there. This also saves me bugging you in the middle of the night, so invest in your sleep up front.
I don't know anyone that handles scope creep well, but let me define that in my terms: changes or additions to the requirements after they've been fully thrashed out and after work has begun. Even as an hourly contractor, I get skittish. "Hey, it's just more work for you." Sure. But if it affects things that have been finished and vetted, it's A Bad Idea. However, things come up and needs change. My rule of thumb is that if the change would alter how data is stored, then let's suck it up and do it now. Otherwise that means the work has to get done later and data migration will have to be done. Better to do one difficult thing now than one difficult thing and one risky thing later. If it doesn't change the data, we should talk about creating a "Things for the next version" list.
I don't work without a QA person or team. This doesn't have to be anyone with a degree and 100 years of experience in Quality Assurance. It just needs to be someone other than me who can run through the system as a user, spot things that don't match the requirements and tell me about them in a meaningful way, e.g., "Here's what I did, here's what should have happened, here's the big explosion I got instead" as opposed to "COMPUTER BAD!" I've never met a developer who could qa their own work, myself included. After spending weeks or months or years designing the flow of things, we have a bad habit of "testing" the system by using it in the exact fashion it was designed ("Click on this button, then give it a value between 1 and 10 but never a decimal and then wait five minutes") instead of beating on the thing until it can withstand all challenges.
After all that, surprisingly, there are some things I do do*. Email me at email@example.com if you want me to do them for you.
I know it comes out like "doo-doo" and I know that was a poor way to phrase the fact I know it, which was even more fun.