Always Be Closing
How to Write an Email to a prospective client
9-min read
I’ve built websites for over seven years, and over the course of that time, I’ve learned what not to say during an engagement. Below is some advice on how to handle clients and manage expectations (without overpromising and underdelivering) — via email.
This my magnum opus. My closing emails. They address all the concerns a potential client might have and answer their questions after you’ve sent over the contract.
I’d like to address a few disclaimers before we get to the body of the email:
This email works only when you’re already in the door and the client is experiencing some form of apprehensiveness. One might expect this after you’ve sent over the RFP, or have met the prospective for a coffee chat and are moving towards drawing up the PRD. Please don’t send this before you’ve at least had a conversation.
In this particular case, my client had sent a 14-pointer list of questions. I thought it would be best to walk her through my vision. Most of the time, shorter is better, but when you’re at the finish line I prefer to hit the nail on the head.
Judge the importance of your email based on the value of the project: I don’t write 1100+ word emails for smaller contracts.
You should also probably take my advice with a grain of salt. Most of my clients are word-of-mouth which gives me a great amount of leverage during negotiations.
Now the email:
Hello!Always casual.
I understand this is your first technical project, and as I mentioned before I’d like to be completely transparent so we’re both on the same page regarding expectations and deliverables.Assuage concerns and assure them this Agreement is mutually beneficial. This is especially important with non-technical clients — there isn’t any point in explaining the specifics — they rather prefer a simple yes or no. Technicals can be defined in the contract which for the most part will be skimmed over and is boilerplate anyway. The last sentence is the most important — I never overpromise even when you’re looking to close. There is no point in the biting hand that feeds, and the easiest way you can achieve this is by acting like something is accomplishable in the defined timeframe. Rushing to receive remittance always looks cheap.
I can be pretty flexible in regards to changes, provided they occur within the timeframe and are reasonably within the scope of the contract.The client’s main concern was scope creep and how the project might evolve over time. I’ve worked on both sides of the tracks, and this is an inevitability in software development contracts. The Developer has to understand that some stuff sticks and some don’t, but on the other hand, the Client needs to understand limitations. I prefer to keep it flexible to appease clients, but still draw hard lines on new features.
The reason I recommended a per-project contractual agreement in this scenario was that all the materials and assets haven’t been completely fleshed out yet and I know there might be a lot of back and forth from both sides.
If you prefer to switch to an hourly rate, I can provide you a breakdown of the number of hours this project might take. To be completely honest I haven’t looked into this yet, I merely went off the deadline you provided and how long each feature might take to develop (in terms of days). I’m estimating around 200-300 hours of work. The hours required for development will not include the administrative work, sprints reviews, back and forth open communication channels that I’ve set up and most importantly the revisions and scope creep which might occur. If we go down the hourly rate I have a number of tools at my disposal that can log my hours and track productivity!Hourly or Project-Based? The age-old question. There are positives and negatives to both sides to the argument, some developers love the idea of getting paid hourly but detest being logged and tracked. Project-based Agreements allow for some sort of financial security (based on the milestones set). I know many projects which fell through after committing 60 hours when the contract stated a minimum of 200.
To see the benefits of a client, swap the roles. Hourly rates include administrative work, weekly sprints, calls, which bump up the bottom line. If you’re sure about the project and know exactly what you want, hourly might work better. Otherwise, try and stick with the latter.
As a person engaging a client, one should be flexible and let the client choose.
From our previous conversations, to reiterate (and to answer your questions in chronological order):
1. I’ve replaced the company with your name and attached the revised contract below.Versioning with contracts. Email attachments suffice but I have a folder of every client I’ve ever engaged with, whether completed, in progress, or failed, with files named as
[CLIENT_CODE_NAME or FILE_CONTENT]_[DATE]_[INCR_VERSION_NUMBER]Something like this —
Contract_v1_Oct_19.pdfI keep the editable copies for easier revisioning. Fortunately, I have a script that accepts client name, date, project cost and spits out a template filled with the relevant details so I don’t have to go around ⌘+F and replacing everything. Also, DocuSign.
2. You might re-engage me for more work, but the Support Period shall refer to any bugs or issues relating to the featured defined in the PRD and does not include any new feature development. Any updates, changes, and new features not defined in the contract will be charged on a USD$50/ hour basis. We can also look into drawing up a new contract at the end of this agreement.My contract is ironclad. The most recent iteration is actually more in favor of Client than Developer. Again, I prefer it this way to see I’m not looking to make a quick buck but instead guide them to the promised land of sexy application development :)
But also I don’t mess around with freebies. It protects me and my contractors from being unfairly utilized even after the project is complete. The shining light of overpromising here might appeal to some, but it’s better to set expectations.
3. Answered above. Everything is included in the per-project contract and is all-inclusive up till the end of the agreement, there is no overcharge fee. If we switch to the hourly rate I’ve also provided the hourly rates above, but there still won’t be any extra fees you’ll need to worry about, only up to the hours logged and tracked.Self-explanatory. I don’t charge extra (no overcharge fees). I actually wouldn’t even know how that would work if we have an end date for the contract.
4. It might not have been spelled out in the contract but I work keeping Agile methodology in mind. There will be continuous testing throughout the project and I’ll provide you with weekly updates along with progress over call, all while being fully transparent. If you’d like me to create weekly breakdown documentation on the progress I’d prefer to switch to an hourly contract.Communication is key. But also display how all of this extra work (read: non-development hassle) can be detrimental to the progress of the project and will be subject to fees if you end up going the hourly route.
5. I’ll be testing on a physical device from the start — I actually prefer it compared to an emulator or virtual device. As for when you can test a working build on your own phone that should be after a month or so — you’ll be clued in on the progress.Clients love instant gratification. They’d like to see the project as soon as possible, even if there’s barely any architecture set up. This sets them up for disappointment. Be colloquial when addressing their concern to always be clued in but also provide a date so they’re not left in the dark.
6. I created the skeleton PRD after our conversations and looking through our previous emails. I’ve made notes on features you mentioned that aren’t required at this current MVP stage:
[REDACTED] - If I remember correctly, we agreed on this being a clickable tile which opened a pop-up that intimated to users that a [REDACTED] feature would be coming soon. From our previous email correspondence on [REDACTED]:4. Dashboard: If I recall correctly the lookbook was not part of the MVP? I recommend not having a flow to review at a later time since it will add unnecessary complications. This means user settings and displaying information to the user and making it editable which would make this a fully-fleshed out application. If this is important we can expand the scope.
I always take notes during calls no matter how insignificant. But I rarely do this when meeting in person — I prefer to be completely engaged and let the person know I’m focused. Notes help me form the basic structure of the contract and in turn a point in time which I can revisit (for negotiations).
If this is something which is essential, I can jump on a call with you today to really flesh this out completely so I know what you want. Still slightly unclear on [REDACTED].Clearly draw a line. Redraw the contract and expand the scope if new features are added while also bumping project costs. This sort of professionalism garners respect (if at least not from a Client’s side some sort of self-respect). Phone calls are great, they provide a much-needed break from electronic mail and the feedback loop shortens.
[REDACTED] - Users will definitely be able to see [REDACTED] — otherwise, the feature wouldn’t work! I apologize — I should have been clearer. I can add [REDACTED] that provide feedback on whether the user [REDACTED] but we’re bordering on full [REDACTED] functionality now. We should try and stick to PRD.As a Developer, one might forget that some technical specifications need to be spelled out. Apologize often, it really doesn’t take much. And if the Client is asking to flesh out a feature point to the product requirements document to cover your bases.
Regarding the PRD — once we have defined the goals and milestones — if I cross the deadline without completing the entire application to your satisfaction the additional time it’ll take to complete the project will be at no cost to you. This is usually how I work and I like to see a project through till the end.Self-explanatory. I prefer to end contracts on a good note.
7. I have many recommendations, we can sit down/ jump on a call and discuss how it might look on your end. I’ve built [REDACTED] before so this is trivial, the [REDACTED] connection is the only cumbersome aspect.The Client was unsure of a particular section of the application and didn’t have the mockups. I find it easier to provide examples from websites or screenshots of live applications and letting them point at features they would like to implement. At the end of the day they’re Users too, and they might know what OnboardingSection entails.
8. Answered above. Any reasonable changes can be included in the project requirements but overarching changes to the structures If you think the project might evolve more during developed (even more than the defined PRD) we can switch to an hourly contract.Bridging the gap once again.
9. You will have complete access, you own the entire codebase from the start! Yes, to all the above — the code will be maintained professionally and fully commented on.Self-explanatory.
10. Any major iOS version changes during the contract period will be fully supported. I can also support 2 major versions down for compatibility — but I do recommend sticking to the latest for security.So iOS versions rarely change over a three-month period and occur once a year. But also there is no point in me explaining this to the Client so I instead go the path less traveled and confirm her hypothesis.
11. Yes, that is correct.A simple yes or no always works. No explanation warranted, and if needed can be addressed over a phone call instead.
12. The project end date will be 3 months from the date of signing the contract.Clarity.
13. I understand your apprehensiveness but this is usually how I work. I’m willing to work out a payment plan for the remaining milestones but the first remittance is 50%.I always work on a 50% upfront payment — it guarantees commitment from both sides and helps me commit completely to a project. It might be on the higher side for some developers but I’ve never once had a problem with this proposal.
14. If we want to hit the [REDACTED] deadline I recommend we wrap up the administrative work by the end of this week. A project of this complexity requires 3 months at the very minimum. Fortunately, it’ll take two weeks to set up the scaffolding and basic structure of the application and your input will be minimal. I’ll still update you on progress but I’ll really only need some assistance and hand-holding when we get to the content stage. Your UI designs provide a good starting point and we don’t have to iterate on the vision which saves a lot of time. Once I receive the first payment I’ll be locked in with you for the next three months and will be able to guide you better.The Client wanted a few weeks to prepare the assets for the project. I explained why that wasn’t necessary and in fact detrimental to the project timeline itself.
As always, if you have any questions please feel free to shoot an email or a message over on WhatsApp — I reply much quicker!
Thank you,
Viren MohindraI prefer to keep open communication channels with all clients.