iOS Freelancer Diaries #2 - Prospective Clients

Today marks three week since I started freelancing. It’s crazy how fast it’s gone by. These last three weeks have been all about one thing; sales!

If there’s one thing I’ve learnt, it’s to never stop selling. You might think a project is in the bag, but until the deposit has been paid it is not guaranteed (even then you never truly know). Already have a two month project? Then you should be aiming to book a project for after.


  • Number of deals: 15
  • Deals lost: 5
  • Proposals written: 4
  • Estimated value of all proposals: £71,500 - £91,500

Organising Deals

To help me keep track of all my deals I am using a website called Pipedrive. This is what my Pipedrive dashboard looks like:

Pipedrive uses a similar layout to a Kanban board. You can add, remove or change any of the columns to suit your needs and add or move cards (“deals”) around the board. It also has a load of other features like: bcc’n emails and “activities”, but I like to just keep it simple.

Contact Made

Once there has been two way communication between the prospective client and I, I will add a deal to the Contact Made column. During this time we would have spoken about the project so that I can get an understanding of the main concept. It is also very important to check that they are aware of costs, time and my payment terms. If app development is new to the client I usually highlight a small and large portfolio piece of mine and explain how long they roughly took to complete.

Proposal In Progress

I’ve uploaded my proposal template on Github for anyone to use. It’s pretty straight forward. I start off with describing the audience of the project. Working on Togethera taught me that building for your audience is crucial. Then I move onto an overview of the app; this is basically a user story of the main flow of the app.

Next it’s the technical overview. If I’m also building the web API I will layout some rough model designs. These are not final but it’s a very useful exercise to get an overview of how to organise the data. For the app I write a overview of all the potential screens. If there are already designs, then I put an image of each screen into the proposal and give an overview of it’s functionality. Throughout the proposal I also highlight any questions, recommendations or ideas that I have.

Depending on the size of the app there could be a couple of “main features”. These are the focus of the app. Is it a weather app? Then viewing the weather forecast is the “main feature”. For the main features, I just go into more depth.

If the screens haven’t been designed yet then I’ll use POP to put together a mockup. I write about doing this in a previous post.

The majority of projects will use third party services. Whether that’s S3 for file storage or Intercom for customer support, I write them all down. Sometimes they won’t have their own SDK’s so I might need to write a small (or maybe large!) library for the API.

Below this I highlight any unknowns that I have. Having too many unknowns makes it hard to give a semi-accurate estimate.

Last but not least, is the estimate. This will either be a single value or a range.

Proposal Made

Once the proposal has been sent, I’ll move the deal into the Proposal Made column. From here it will either go two ways: they reply and the deal is moved into Negotiations Started or I don’t hear anything back…

Don’t panic, it’s cool, they don’t hate you.

So far, pretty much every time the client has been refining or rethinking the idea, trimming down on some feature or just awaiting input from their colleagues. After about a week I usually send a follow up email to check if they had a chance to look at the proposal and if they have any questions.