Here is what, in my opinion, you'll want to do:
Document everything.
If you're not familiar with putting together design documents, consider this a great time to add that skill to your resume. I've worked at jobs like this and what you absolutely need to do, before you do anything else, is put together a design document which explains in exhaustive detail as many use case scenarios as you can think of, talks about all the end-user bells and whistles that your client wants you to add, and even (if you can manage it) provides a general timeframe of when you will be providing which deliverables.
It's my experience that this is by far the most important part of this process. I realize that non-techie types will not always enjoy getting together with you to decide in advance what buttons should be on a page or whatever ("that's YOUR job!") but if nothing else, the fact that you've put this document together means that later on, when your client tells you that they want to add features X, Y, and Z, you can say to them "okay, sure, I can do that, but it will cause this product to take [amount of time] longer to develop.
Oh yeah, and when these features are added? Put them in the design document and get the client to sign off on the changes.
I realize that as a developer this feels like a lot of extra time doing something which is not actually programming and therefore does not feel either productive or fun, but look at it this way: your design document will serve as something similar to the outline of the book you're going to write. Nobody's going to "read" the book in the classic sense of the term but they are going to use it and it's important to know exactly what that book's going to be about before you start to write it.
Provide deliverables as soon as you can.
What I mean here is not that you should stay on schedule, because of course you want to do that (and from the sounds of it, that may not be any easy thing to do anyway). What I mean is, try and get something out to your client that they can look over and approve/request changes to as quickly as you can. If you're designing a web page or a WPF application, for example, get them a wireframe as soon as you possibly can. As you wire it up and add features, present these to your client as soon as you get them done so that they can test them out (caveat: some folks just won't test stuff out until it goes live or is about to, so don't rely on this; however, you can use this as an opportunity to say "I presented Feature X to you 3 weeks ago. I can change the way it operates for sure but this will take X amount of extra time."
Treat development, testing, and design as interrelated parts of the larger process, not stages you get to clear.
It kind of amazes me when devs do this, and I'm not saying you will, but it needs to be said: the time for refactoring code is whenever you get a chance, the time for a redesign is whenever the client requests something that you can't provide in the current design, and the time for testing is whenever you're programming. I realize that this method can create spaghetti code, but that's why you refactor.
Additionally, if you're the lone developer at your company, your co-workers/clients are not going to know what the "development process" is. They'll have requirements that they want you to meet. Sometimes they'll realize halfway through a job that a requirement they gave you needs to be more robust, or that a way you solved an issue creates non-functional problems they didn't express at first.
Never say "I can't.
Well, I guess if they want you to design a new version of Call of Duty all by yourself in 2 weeks, you can say that you can't do that in that amount of time. But what I mean is: if your clients/co-workers give you a feature, don't tell them that it can't be done. If it's going to be hard to implement into your existing design, advise them that you'll need to refactor a bit and that it will take longer (try to provide an exact time - if you over- or under-shoot, you can always adjust that later). If you literally don't know how to do something, advise that you'll need to research the solution and that you'll give them an estimate of the added time within a day or two. If there's a physical limitation preventing you from doing what they want, or if what they want would violate some other principle ("hey, can you make it so that people can see their passwords?") then provide other solutions in lieu of "I can't".
Constantly communicate.
If you can manage it, a brief 10-15 minute daily "scrum" style meeting wherein you briefly discuss what you're working on and maybe get some minor bits of clarification is good even with non-devs. I know that sometimes you can get into that "meeting hell" wherein you're spending more time talking with people about what they want then actually providing it for them, but generally I think programmers tend to err on the side of putting their heads down and just getting stuff done, so it's not a bad idea to maybe push yourself towards constant verification with your stakeholders.
If nothing else, a weekly or twice-a-week meeting where you present what you've done so far and discuss the challenges that lay ahead ought to accomplish a few things:
It'll help you cultivate your own communications skills (not to say you're not already a good communicator, but this is something all devs can and should work on).
It will give your client/co-workers confidence that a. you know what you're doing and b. you understand their needs.
If you do get behind on something, or if there's a major change which is suddenly necessary, you and your client/co-workers won't feel blindsided by this.
Anyway, that's what I've got. Look at this as a challenge and an opportunity, not as something which shall necessarily cause you to pull your hair out. Working with non-techy people can be a curse (sometimes they ask you to do things which are all but impossible and don't understand why you can't just get it done) but also a blessing (sometimes the smallest little addition that took you all of 5 minutes to code can make you feel and look like a total hero).
