So, you decided to work with an agency / freelancer (dev, design, doesn't matter).

How can you:

• Prevent nasty surprises at the end?
• Ensure adherence to the budget?
• Become aware of any issues in practically real-time?
• Get frequent updates, overviews and demos, without having to chase for them?
• Hold them to account?

I'm going to offer a series of posts on this subject, looking at each of these challenges separately.

Let's start with the main one-

Part 1: Preventing nasty surprises when working with an agency / freelancer

One of the worst things that can happen - is the agency surprising you with a malfunctioning, broken, buggy build, after months and months of work. Even worse, you discover that key functionality is completely missing, and now they're asking for tends of thousands of £ more to deliver it.

If you're in this situation today - I'm genuinely sorry, as there isn't much left to do at this stage, apart from some tough negotiating and contract enforcement.

The best thing you can do - is to prevent this from happening in the first place.

So, without further ado, here's the best way to prevent it when considering agency collaboration or engagement;

‍

1. Create a detailed SoW (statement of work).

What is a Statement of Work (SOW)?

‍

A Statement of Work (SoW) is a document that outlines the details of a project agreed upon between a business and an agency. It serves as a roadmap, and can (and should!) be incorporated into your contract, thus ensuring all parties have a clear understanding of the project's scope, deliverables, timeline, and responsibilities. A well-defined SoW minimises misunderstandings and prevents surprises.

‍

Key Components of a Good SoW

1. Project Overview: Begin with a concise summary of the project, its purpose, and the desired outcomes. This sets the stage for more detailed sections and provides context.
2. Scope of Work: Clearly define the boundaries of the project. Specify what's included and, importantly, what isn't. This prevents scope creep and ensures all parties have aligned expectations.
3. Deliverables and Milestones: List all deliverables, along with the deadlines for each. Milestones act as checkpoints, helping to track progress and ensure that the project stays on schedule.
4. Timeline and Schedule: Include a detailed project timeline, including start and end dates. A well-structured schedule ensures that resources are allocated appropriately and project phases are completed on time.
5. Payment Terms: Outline the payment structure, including rates, billing cycles, and payment milestones. Transparent financial terms eliminate potential disputes over compensation.‍
6. Acceptance Criteria: Establish criteria for how deliverables will be evaluated and approved. Does the price include a dedicated QA engineer, or is the agency assuming you will test things yourself?
7. Assumptions and Risks: Document any assumptions made during the planning of the project, as well as potential risks and mitigation strategies. This prepares both parties for challenges that may arise.

‍

The most important element in a SoW is the definition of the features that must be included. Missing a small feature or a minor detail - could derail the whole project timeline, roadmap and cost. Hence, it is crucial to define all the features properly.

‍

Here's an example of a good SoW features outline document (download link):

‍

‍

Obviously, sometimes the project is too big to be fully estimated and priced from the very beginning. Imagine you're building the next DuoLingo or Instagram; it would be impossible to estimate the effort required in delivering such a complex and feature-rich app. In such cases, you want to ensure that the agency / contractors scope and estimates at least the MVP version of it, as well as create a rough plan and guide for the next steps.

‍

‍

Ensure that the SoW is estimated and scoped before the contract is signed:

‍

Obviously, sometimes the project is too big to be fully estimated and priced from the very beginning. Imagine you're building the next DuoLingo or Instagram; it would be impossible to estimate the effort required in delivering such a complex and feature-rich app. In such cases, you want to ensure that the agency / contractors scope and estimates at least the MVP version of it, as well as create a rough plan and guide for the next steps.

‍

2. Insist on daily, weekly, and monthly updates

Here's how a good daily update should look like:

This should be sent to you in Slack or Teams (whichever you prefer), on a daily basis, at the end of the day.

In addition, you should get a weekly report summarising all the work done in that week, along with a relevant demo link / prototype / design draft / whatever deliverable can be demonstrated, even if it's not completed yet.

Insist on seeing work in progress, so that you don't get surprises at the end.

Then, on a monthly basis, you should get a timesheet report - which will show you how every day was spent. You should be able to correlate that to the daily and weekly reports, and they should match each other.

If you ask for any of these things, and the agency or freelancer tells you that "It's going to be too technical" or "too much faff and admin" or "we don't like to be micromanaged" - then know that they don't want to be transparent, and that should instantly raise a red flag. It should always be possible to explain what billable time was spent on, and so you should insist on getting these explanations and updates regularly.

This is not micromanagement, this is accountability.

We'll discuss the communication style and process in detail in a future post.

‍

3. Ask for preview links / demo builds regularly, from week 1

It's perfectly reasonable to request seeing demo builds, preview links, preview versions of your app, etc - before they are ready.

It is expected, and you shouldn't feel uncomfortable asking for them.

Obviously, you shouldn't criticise work that is still in progress, however, you should be able to spot if the freelancer is completely off-track. If you see them adding one-off payments to a product that only has subscriptions - that's a red flag. If you see that the app, which should allow you to resell fashion items, doesn't have a gallery of items - that's a red flag.

Getting preview builds should be easy, as long as you're requiting that from the beginning, and as long as the agency / freelancer chooses the right tech stack.

For example, using Vercel - will give you this functionality for free, out of the box, and with 0 additional effort.