Sure thing. Keep in mind, though, that this is from the perspective of a small development shop, and design is not our forte.
Whether it's for myself or a client, the first thing I always do is a requirements document. They're not always (read: almost never) complete, but a simply-formatted list of features, grouped according to relevance and what goes where, is a great place to start and often helps to bring up potential issues or required but glossed-over features that might not otherwise have come up until the project had already started (this is particularly important for clients as it helps avoid incomplete estimates).
After that, ideally, we take the requirements to a front-end and/or (again, very ideally) UX designer, if available. They throw our requirements into a large black cauldron, stir in Eye of Newt and perhaps an Honest Politician or two, and later we get back templates that might resemble parts of the final product.
In the case that budget or time doesn't allow an actual design phase, we tend to just build a simple base template (lately on Bootstrap) and jump into code. I'm not advocating this; it's far from ideal. It generally works out if you have a very solid understanding of the project and the relevant design considerations, but leaves you very much open to coding yourself into any of many corners.
From there, most projects are just a long series of build, show 'n' tell, iterate on feedback, feature creep, rinse and repeat.