How I handle proposals 🧐

This post outlines how I handle proposals as an independent web developer, almost the whole pre-project arc including gathering info, writing and sending the proposal, and what happens after it’s sent.

I love chatting about potential projects with anyone who will entertain me, but I can’t stand writing proposals. My goal is to make the process streamlined enough that I hate it a bit less and am able to get proposals out the door much faster.

This is an important topic and something I’m continuously trying to improve. A good proposal lays solid foundations for a project and sets the tone of a working relationship. Sometimes it even helps weed out the people I’d prefer *not* to work with.

Some of this has evolved over years of freelancing, but a lot of it is brand new or newly refined. Moving from the UK to the US has given me the opportunity to reconsider my procedures and improve the commissioning process both for myself and for my clients.

I’m pretty happy with my approach, but I’m sure it could be improved. Also, what works for me may be totally unworkable for someone else. So take this as one person’s perspective, and please share with me if you have other ideas.

Pre-proposal: gathering info 🌱

Before sending a proposal, there is always some correspondence to get a feel for things. Sometimes this conversation happens directly with the client, other times I’m speaking mostly with the designer. I receive formal or semi-formal briefs for maybe 15–25% of my inquiries, the rest of the time it’s usually a short email asking if we could discuss a particular project.

I try to get enough information to inform the scope of work without turning it in to a multi-day ordeal. When I discuss what the client is after, I’ll usually touch on the most major details (timeframe, general look-and-feel, any pre-existing platforms or tech I should be aware of, budget, etc.) and avoid veering too far in to jargon. Most of my clients and collaborators come to me because they prefer *not* to talk tech; they trust me to fill in those gaps as appropriate.

Non-Disclosure Agreements (NDAs) 🙊

NDAs have never come up in my work with EU-based clients, even with larger institutions. With US-based clients on the other hand, I’ve encountered a few NDAs.

Some developers have a blanket “no NDAs” rule but that seems pretty hasty, I can understand the need or desire for an NDA. That said, I do read them carefully to be sure they’re not too restrictive before agreeing, and I have turned down projects in the past due to an overly-restrictive NDA. Generally, I’m more open to a mutual NDA that protects both parties than a unilateral NDA that protects just the client.

There are a few red-flag clauses that I look out for in an NDA. This Hongkiat article about understanding NDAs offers a good run-down of those points.

Perhaps the biggest potential red flag is a clause preventing me from including the work in my portfolio or having my name be associated with the project. I’ll always decline an NDA with this clause unless I’m incredibly excited about the project. If I do decide to proceed, I’ll price *much* higher than I otherwise would. As an independent web developer my future work relies entirely on my portfolio, so not being able to share my work has a direct impact on my future work prospects. That impact should be valued accordingly.

Another red flag is the timing of the NDA. If the client won’t speak about any aspect of the project before an NDA signed, it’s usually something I’ll decline. Again this is not to say that an NDA is unjustified, it just often indicates that there might be a lot more project management than I want to take on if the work were to go ahead.

Establishing the budget 💸

Budget is a touchy subject. Sometimes the client genuinely has no idea how much the work should cost. Other times they’re hoping that if they don’t disclose a budget, you’ll somehow come in lower with your proposal and they’ll get a better deal.

I understand both perspectives but for my part, having at least *some* idea of budget allows me to write a much better proposal. It also reduces the amount of back-and-forth time required to determine whether or not this relationship is going to work out. If I know a client’s budget is around £3k, I won’t suggest an all-singing all-dancing platform that will cost them £10k. Likewise, if a client’s budget is £10k, I’ll be sure to add the appropriate bells and whistles that I wouldn’t be able to consider on a £3k site.

If I’m going to be working on a website build, I also try to find out about the client’s post-project budget. Even the slimmest of JAMstack sites involves ongoing costs, and some sites require a lot of maintenance and fees from SAAS platforms. If I know what the client’s ongoing budget is, I can avoid saddling them with something they may have to abandon in the future due to running costs. This is particularly critical with clients in the cultural sector whose yearly budgets are often subject to the whims of fickle funding bodies.

Even if a client is being stubborn about their budget, usually I can get some idea asking along the lines of, “Are we talking £2-5k? Or £5-10k? Or £10-20k?” If they still won’t budge, I’ll just try to write a proposal that is as close as possible to the scope we’ve discussed thus far.

Proposals vs. unpaid work ⚠️

If it’s impossible to get enough information to write a proposal without significant research or digging in to a client’s existing setup (I’m talking over an hour or two), I’ll usually propose some pre-project consultation time instead so that I get paid for my additional work. The client can then take the results of my consultation to either write a more informed brief for their project, or we can use it to continue our work together.

There are of course exceptions to this guideline, but I generally proceed with serious caution when a potential client asks for a significant amount of unpaid proposal work. In my experience, the relationships that form from this sort of beginning don’t last.

Writing and sending a proposal ✍️

Writing proposals is my least favorite part of working for myself, and I feel confident in saying that’s probably a feeling shared by a lot of other independent devs.

To reduce the amount of time I spend writing a proposal, I identify the most similar work that I’ve done in the past and then use the corresponding proposal as a template for the new proposal.

There are a lot of slick platforms that automate the estimating and proposal writing process. So far, I haven’t found one that I feel is worth the ongoing cost and gives me the necessary control over the design of my proposals. On the more lo-fi side, I considered using LaTeX for all of my estimates since it would give me total control over the design and would allow me to keep my proposals in version control (bonus!). But then I’d have to manually add up the fees, risking human error.

In the end, I just use Apple Pages because of ease of use, reasonable design control, and the ability to embed a table that does its own math.

Each proposal includes a summary, estimated fees, scope of work, timeframe, billing schedule, sometimes a relevant work section, and fine print including a link to my service agreement. This sounds like a lot (and it is!), but remember that the bulk of it can be recycled from previous agreements for similar projects. I’ll go in to each of these sections below.

Summary 🤲

Each proposal begins with a short summary including opening remarks to establish my intent and why I am looking forward to the work. It also includes references to the pre-proposal conversations that we’ve had with PDF names or email thread dates where appropriate.

Estimated fees and third-party costs 💰

The summary is followed by the estimated fees, both mine and anticipated third-party costs such as the content management system (CMS) license, webfont licenses, and hosting. I usually present my costs in a table that breaks my work down in to its constituent parts (i.e. project management, prototyping, build, testing, consultation on third-party services, etc.). If the third-party costs are extensive I’ll present them in a table as well, otherwise this is usually a short paragraph.

Scope of Work (a.k.a. Statement of Work or SOW) 📦

After the fees comes the scope of work. This section outlines what I’m going to do, how I’ll do it, and the expected outcomes or deliverables.

The SOW is probably the trickiest part of a proposal. You have to go in to enough detail to properly define the edges of the work, but you don’t want to put the reader to sleep. My SOW for a website build usually includes the following:

• My process including how my work will be demonstrated (usually a staging environment)
• How I expect to receive visuals and collaborate with the designers
• An outline of expected front-end behavior
• The anticipated structure of the content including major top-level pages (e.g. About, Contact) and channels (e.g. Posts, Events)
• The anticipated media filetypes
• Which third-party platforms I’m expecting to work with or provide assistance on
• The anticipated code languages or frameworks
• How web hosting and domain administration will be handled
• Whether or not a CMS will be used, how much CMS training they will receive, and how content addition or migration will be handled
• Whether or not e-commerce functionality is included
• Browser support
• How I will assist with privacy and cookie policies
• How I will approach Search Engine Optimization (SEO)
• How e-newsletter signup or forms may be integrated
• How I will approach accessibility
• How I will integrate SSL certificates
• How maintenance and ongoing support is handled

If I don’t have enough information from the client to be sure about each of these points, I’ll usually default to what has been appropriate in most of my past work.

Timeframe ⏳

After the SOW is the proposed timeframe. When outlining a timeframe, I take in to account any important events and general phases such as prototyping, the main build, and final testing. Important events might include things like a book launch or website announcement, but it might also include things like stakeholders’ holiday dates (especially my own!) if they fall within the proposed timeframe.

If the project involves a CMS, I include the client’s content addition as a project phase alongside testing and debugging. This is important because if content editing takes a lot longer than anticipated, I have to cover the additional overhead to keep their project active within my systems and developer software. It also always requires more work for me to sustain a build over a greater-than-expected timeframe since inevitably the tech stack becomes out-of-date in the intervening time. Including the content addition time in the proposed timeframe will not prevent a client’s content editing from taking longer than expected, but it does put me in a better position to discuss the additional work required if the situation arises.

I tend to suggest a timeframe (days, weeks, months) instead of a date-specific schedule since the start date is almost always different than what I propose, throwing off any schedule that was initially put together. I also do not usually prescribe specific deadlines since in my experience, the end result of a web project usually benefits from fluidity. If a client requires a hard deadline, I increase the amount of project management time outlined in my fees. This lets me account for the additional work required to manage strict deadlines.

Billing schedule 📆

The billing schedule outlines when the client should expect to receive and pay invoices, and it depends on my pricing structure for the work. For time-based work (hourly or daily, usually ad hoc maintenance or consultancy), I tend to invoice every two weeks.

For fixed-fee projects (the majority of my work) or value-based pricing, I outline milestones. A lot of developers insist on 50% up-front, but usually I do 40% up-front as a commencement payment, 40% mid-project, and 20% at the end of the project. This 40/40/20 split has been appropriate in the vast majority of my past work, but occasionally I spread the cost further. Sometimes it’s for the benefit of the client, it may be easier for them to pay in more, smaller instalments. Sometimes it’s from my own benefit. If I’m earning a large total fee for a project or it’s spanning a greater period of time, it might make sense for me to spread the payments further so that there aren’t as many peaks and troughs and my cashflow is more steady.

In the past 10 years or so, I’ve had a handful prospective clients balk at the idea of a commencement deposit. Usually it has been individuals that are using their personal budget on a personal project and have never commissioned a web developer before. They’re understandably wary of me just walking away with their money. After I explain that the commencement deposit is actually what prevents me from walking away and confirms our commitment to one another, there has almost never been a problem.

I can count on one hand the number of times there has been a problem, the number of potential clients that fully declined any up-front commencement payment. Every single one of those individuals and organizations raised other red flags throughout the commissioning process and were not worth pursuing.

Relevant work 🔮

The “Relevant work” section is something I’ve started adding only recently, and generally only for new contacts that I haven’t worked with before.

If a contact is less familiar with my work, I want to make sure they are aware of the types of projects I’ve taken on in the past that might be relevant to their brief. This is a chance for me to reinforce our shared understanding of what I do and add a little bit of visual interest to the document. As a developer I always keep any images in this section quite small, thumbnails to indicate what the site will look like if the reader clicks the link. A visual designer would probably make this section more extensive.

Fine print and sending the proposal 💨

Besides the major sections outlined above, I include fine print on each page of my proposals along these lines:

Please see my terms of service (<link to terms of service>) for further details including our responsibilities to one another, termination, credits, and copyright. The estimated fees are based on our complete, shared understanding of the project scope as outlined in this document. Any additional services will be billed at my day rate. Expenses are approximate and subject to change. All invoices will be issued and payable in USD, and the client is responsible for all currency conversion fees and other fees related to payment transfer. This proposal is valid for 30 days.

The proposal validity timeframe is important. Very often, I’ve had a potential client go silent for months and then get back in touch saying they want to get started as proposed within the week. In the intervening time my schedule has usually changed, my rates may have changed, my terms of service may have changed. The validity timeframe makes it clear why I might not be able to stick to the terms of an old proposal.

When I’m ready with my proposal, I export it as a PDF and put the date in the filename like so: ph_client-initials_YYYYMMDD.pdf. I send the client the PDF via email and let them know that I’d be happy to discuss it and adjust it if anything is unclear or not as expected.

Post-proposal: the follow through 🥅

The post-proposal time is critical.

The recipient might go silent. It’s not a great sign; it’s not nice to be left hanging, and it can indicate that communication might be hit-and-miss if the project were to go ahead. But I try not to hold it against the recipient, life can get busy and this might not be a high priority. I’m guilty of similar behaviour sometimes! When this happens, I’ll follow up once to ask if the proposal was off the mark or if they have any questions. After that I’ll usually let it lie and move on.

Sometimes they’ll get back with comments or adjustments to the scope. I accommodate these where possible, but if it increases the scope, there’s always a corresponding increase in the fee.

Sometimes they’ll reply saying the total is too high. In that case it is sometimes possible to reduce the amount of time I expect the project to take, but that has to come with a reduction in the scope. Another option is a discount. I don’t do this often, but I will occasionally offer it if I am personally invested in the project’s ethos or people and I’m not currently working on other discounted projects.

Very rarely, I’ve had someone reply saying that my rates are too high when compared to other developers. I usually walk away from these projects since there’s no satisfying conclusion to that conversation for either party. My rates will always be higher than some other developers’ rates. Likewise, there will always be some other developer that’s more expensive than me! My rates are not arbitrary, they’re the result of carefully evaluating my living and working costs, my areas of expertise, and my level of experience. If a client wants to get the cheapest possible rate for a particular scope, no amount of explaining is going make them happy and I am not willing to undermine the careful work I’ve done to determine my value. In this case, they’re best served working with another developer with the rates they’re after.

When things do work out, the next step is to issue the contract and the commencement invoice. If all of my correspondence has been with a designer, regardless of whether or not they want me to invoice the client directly, I always make sure that the designer has sent the client my scope and terms and that the client is happy to agree to it.

Some further thoughts

This has become a decent process for me, but definitely still not perfect. I’ll add further research here as I come across it.

I just came across Sanctuary Computer’s method for quoting technology work which involves meticulously outlining the feature set against a burndown rate (see their “Supreme for Dogs” e-commerce build). Also from their site, I can see that they have a minimum engagement fee. Makes a ton of sense.

I’m now working with Matchstick to finalise my service agreements, it has been a great process so far. I’ve never really gone down the retainer route for pricing (more on that in the pricing post), but am seriously considering it in the near future for website maintenance. Their blog post on retainers looks like a really good resource for what you should put in to a proposal for retainer work.

This is one of a few posts on processes, the day-to-day practicalities that let me finish the boring stuff quickly so that I can spend more time on the fun part of work. Proposals, pricing, contracts, etc. See the Processes category for more.