For your next project you should realize that business people deal with what they can see. It's that visualization which drives the ultimate design of the backend. I've had far more success on projects where I put together the look and feel of a project before identifying the structure of even a single table. Honestly, this is where you will have the most collaboration with the business people and lots of changes will happen rather quickly.

Once they sign off on how it's going to look then you put together how it's actually going to work under the hood. Otherwise you are going to spend an inordinate amount of time rewriting stuff which will only serve to frustrate you.

If you are interested in continuing with this situation you need to mentally start over. Sit down with Steve and the business guy and have Steve put together the basic screens / flow. Your job would be to guide them based on technical feasibility - again - ignoring this backend that you've already built.

Once those screens are done, take a look and see if your existing design works with that. If not, change it. If it does, then start hooking it all up.

If you aren't interested in continuing then the best way would be to part ways as amicably as possible as soon as possible. That way they can find someone else to move forward.

Also, I've worked on many projects that required pulling people out of the technical dark ages. It's not an easy road as even if you were delivering the exact Holy Grail they asked for they will try to find some reason to keep doing things the old way. If you keep your functional (and visible) deliverables short (at least weekly) then you'll go a long ways towards being successful.

@Belle I'm pretty sure you're wrong about not needing access. I believe WordPress is typically installed directly on the server. It's shrink wrap software and isn't usually deployed automatically by commit. In fact, the pages you generate in it are stored in a database, not on the server's file system directly.

So there's no possibility of storing his pages in Git.

Also, I'm a little surprised that you chose PHP and have no front end yet. PHP is first and foremost designed to be a templating language for generating HTML pages. If you were planning to do a single page web app where the web page sends requests (via JS) back and forth to the server, other languages (Ruby, Python, C#) would probably fit your approach better, since they're designed to be full fledged programming languages first. Although, I question the wisdom of the single page app.

@Nelson I disagree with you here. While you're 100% correct that disrupting their workflow is an extremely risky business, I don't think just letting them continue to do all their work in Excel directly is a good idea, either. There's definitely a balance to be struck, and it depends on exactly what they're doing in and with the Excel file. But leaving them like this isn't a good way forward, either. ;)

Thanks everyone for all the help, it's really appreciated. I've nudged them towards Google Spreadsheets, but Excel-guy and Steve insist on using MS Excel and I think it's OneDrive for sharing, because 'Google Spreadsheets is unsafe and everyone can see it'. I am not very familiar with either, but it seems like an incorrect assumption.

I did a requirements analysis with them before starting any programming and we look at it about every month. I don't know if PHP is the best choice, but I had never made a website before and a backend developer I know told me I could use PHP for a backend.

The Excel is incredibly difficult to understand, Excel-guy and I talked over remaking it, but the structure would be so incredibly difficult we both decided a database was the only way. If we can get a database to work with the Excel, that would be a solution as well, but I lack the technical knowledge to even know how to start with that.