It's not easy being a backend developer. Not only do you have to code massive websites, you also end up being responsible for maintaining things like build scripts and database migrations, and being called on every five minutes to fix the dev system of the front end developer working on your project, who probably caused their problem in the first place. On top of that, you often have to wait for that same front end developer to get on and give you some front end before you can properly check that your website is working correctly.
As a front end developer, I genuinely sympathise, so here's my thoughts on the best way to work on front end when the front end isn't ready yet.
Much of this guide is written based on the assumption that the work is carried out in a particular way, i.e. that once briefed, both sets of developers get to work independently on their side of the site and at some point the front end developer is given access to the templates to start inserting markup. If you have a wildly different approach to that then some of these points may be less relevant to you, but there should still be some points of value in here.
Talk at the start
Just wrap stuff in divs
This is hopefully self explanatory. There's no point in wasting effort writing markup that's going to be completely changed anyway - if you want to see things clearly on a page just wrap them in separate DIV elements.
Don't add any classes
Don't use inline styles
This isn't a problem at the start of a project but more later on once some front end is present. Inline styles break class inheritance and fragment the CSS. If you really need to change how something looks quickly, go ahead and use inline styles, but notify front end when you do it so they can move those styles into the right place.
Only use an ID once
Don't put markup in code
It's also good to expose markup where possible, or provide training or guidance to front end as to how this can be accomplished. The classic example of this is forms in django templates. Outputting a checkout form as form.as_table might be fine, until the design calls for one of those form elements to have credit card icons alongside them.
Stick to what was agreed
Often a site will need some kind of plugin to accomplish a task and that plugin will be needed early in development - for example, to display a graph. Even if this is needed urgently, consult with front end first. They may or may not be happy with your choice of plugin or library, but they'll need to be the ones to decide - it'll end up being their job to support/maintain/develop it.
If in doubt, ask
I can't speak for every front end developer, but I'm more than happy to provide front end advice to a backend developer. Communication is brilliant.
Failing that, any half decent front end dev should have provided a styleguide for the site that should help you to find the right markup and classes that you need.
Advice to front end
Most of this article has been directed at backend developers, but this part is for the front end devs. Build a styleguide. Not just a simple page showing some of the elements in place. Not just a list of classes that can be used in some circumstances. A complete, clearly laid out, simply explained, detail of the whole of the front end.
Think about your styleguide as a toolbox, one that can be used by other developers to quickly and easily assemble new pages based on existing styles. Does a form need building? The 'forms' section of the styleguide should contain everything anyone could ever need to know about putting together forms on this site. A good styleguide isn't just a useful asset, it's an essential part of building front end.