Yeah, you learn more in a half-day onsite than in weeks of e-mail exchanges.
Sometimes people keep a frustration because writing a proper e-mail with details is a lot of effort.
But I also notice a lot of “we didn’t want to bother you” for changes that take 30 seconds and are perceived as deep magic.
I don’t know how applicable this might be to your particular circumstance, but just wanted to comment on this more basic premise of providing useful functionality. (This is not necessarily to be critical of your particular case, but to highlight some aspects of the dynamics that arise in these types of scenarios.)
I’ve worked in VFX pipelines, and also helped scientists and others with domain expertise with their issues. In either case, there are lots of things that are not known ahead of time, and the work changes all the time too. The most important thing is to be sitting there next to the person doing the work, or even bettter, for it to be your job to do some part of what they’re doing, so that you experience the actual pain points of their work. It is very easy to misunderstand what someone is doing, even if they give you as detailed a description as they possibly can (which of course you should be grateful for, because you are now a burden, and taking time from them being able to do their work), and especially if the work is 1) not something completely standardized 2) has frequent changes 3) has actual complexity not because of the need to deal with some over-engineered system, but because real world scenarios have complexity. In all likelihood, they might not quite understand the friction points which influence behavior in this type of time-constrained work, which tend to be harder to verbalize than the “big stuff.” They’ll certainly tell you about the big obvious things, but the thing is, a lot of those big obvious things are not what count in day-to-day circumstances of carrying out the work.
The invisible small friction points that people think they can work around are what wind up bringing projects to their knees, where you wind up with complex, rule-oriented systems, some supposedly productivity-enhancing thing that “automates” the wrong thing, or adding in constraints that kill people’s ability to carry out basic work tasks.
Beyond VFX, some of these issues have become so ingrained in the systems that have resulted from the era of “online advertising-driven tool development,” that it’s even hard to see the issue at hand. A lot of systems are thinly disguised means of generating profits for cloud computing businesses, or data capture operations. So some of what are described as “best practices” are actually funneling people towards serving those ends. The “helpful functionality” aspect takes a back seat and is out-of-mind as a primary concern. But if you want to actually help people with what they need done, it’s hard to get around the fact that you need to actually experience the world from their point of view.
An ideal situation to be most effective at actually helping would be… to join the company and work as an employee, who can see and experience what they need. Barring that, just work on small bits of functionality that actually help them to do specific tasks rather than on “shipping an applicaton” that they might just set aside and never use, the moment it makes anything they actually need to do harder than it was before.
Before you build a whole system to address their problems, you should try to figure out if you can address just one thing that they face on a day-to-day basis. Or see if you yourself can carry out some action that is actually useful to their operation. That’ll build confidence and give insight into the issues that they actually need, rather than what they say they want, or what you project onto them as something that they need, or that you build into a system because it’s something that you are interested in, but has nothing to do with their problem. These are all things that can invisibly contort projects into things that serve a different end goal than providing actually helpful functionality.
I’ve been in this situation too, both as a sole developer and in very small teams - so I can feel your pain. By the sounds of things I’d say you’re doing very well considering the situation.
There’s already a lot of very good advice in this thread so I’ll just touch on a couple of things that worked well for me.
Have a prioritized list of work (a backlog or whatever) with highest priority items at the top. You may have to maintain this list but the client is responsible for setting the priority. Actually, only the top of the list is important (and these items should be well specified). But this can help to improve relations and remove stress because when the client asks for another new feature or to change something that has already been changed a few times already, you can just say “sure no problem let’s add it to the list”. And then at some point they get to prioritize it. Also you may have a lot of influence and be able to affect the ordering decisions so that things are in a more logical order - basically helping the client to help themselves - but they have the last word.
There should be one person (product owner) with overall responsibility on the client side - or at least one person that is overall responsible for communicating that vision to you. In the end you can’t accept different direction from different people at the same time. That doesn’t mean that you can’t work with other people on the client side but someone must have the final say so that you get clear direction. And it is this person that decides the priority of the list in point one.
This has already been mentioned, but I think it’s very important to have regular scheduled meetings/calls to discuss the work in the list and to show that progress that is being made or clarify any doubts about specifications etc. These could be separate meetings or all done at the same time - it depends on what works best for everyone involved.
Try to bring the client on this journey with you - explain about the list/backlog, product owner and scheduled calls and explain to them how this is going to help you all work better together - try to bear in mind that the people on the client side are probably doing their best too and all this is a bit alien to them 
Yes! It sounds very enticing to just slap on a few more weeks, before actually shipping a first version, to have some more time to add new features. But in reality risk just grows and grows. I’m very aware of the dangers of postponing go-live.
Thanks for noticing 
We’ll be transitioning into a second phase soon. I’ve already arranged to be working on-site some days of the week, which will be a very interesting experiment. I’ll try to tighten some feedback loops and take ownership of keeping more order in our backlog. Meanwhile we’ll invite them to take on the responsibility of prioritizing the most pressing features for the next development cycle.
Thanks everyone taking the time to add to this discussion 