Vlad Sabev | Preparing a Freelance Offer: From 0 to 100%

ℹ️ This post has been translated from a talk I gave in Bulgarian in October 2017: https://dev.bg/event/it-freelance-izgotvyane-na-oferta-ot-0-do-100/

Hi! For those who don’t know me — I’m Vladimir. I’ve been working as a freelancer for the past four years, mostly using the approaches most freelancers are familiar with — first by the hour, later on a monthly salary.

At a previous dev.bg event, I shared my impressions of those approaches, along with an alternative I’ve been striving toward — a fixed price per project. But to work that way, I first had to learn how to prepare a proper offer.

Before I continue, I want to clarify: I’ve already graduated, I don’t have children, a car, a mortgage, or any other loans. My point is that the way I work doesn’t necessarily apply to every person and every situation. So please — keep your own life circumstances in mind before taking professional risks.

But in the end, I believe that without taking risks, there’s no growth! That’s why six months ago I stopped working with my clients, to have the time and freedom to experiment. During this time, I’ve been studying — and I’m still studying — various technologies and approaches to work.

Most of the ideas I want to present today aren’t new, and they’re not even my own. I’ve come across them from various sources and in different forms over the years. Recently, for example, I had a series of conversations with a friend of mine who is a design engineer in the construction industry.

It turns out that despite the differences, there are also many similarities between the software and construction industries — they also go through the process of researching and preparing an offer for their clients before starting work on a project.

The Process

The steps we’ll walk through:

Conversations with the client
Independent research
Defining and estimating features
Pricing packages
Formatting and presenting the offer

To keep things from being entirely theoretical, I want us to reproduce the entire process together.

Some of you might think you “don’t have time for research and estimation,” or that this is “some kind of waterfall process” not worth doing — I certainly used to think that way. Now I believe preparing an offer is important precisely because it forces us to do our homework.

Why Research?

During the research phase, we figure out:

Whether we’re the right person for this project
Whether we need help from other professionals
Whether the client’s budget will be sufficient
What the specific parts of the project are that could trip us up

Defining and estimating feature modules, in turn, helps us notice commonalities across the diverse projects we work on over the years — and accordingly develop ready-made solutions for recurring problems.

And it helps our clients by providing more transparency, concrete timelines, and choices.

Since we have limited time for this presentation, I’ve prepared the necessary materials in advance.

Meet Yoana (The Client)

To start, let’s imagine that Yoana — our fictional client — has reached out to me.

Together with several co-founders, Yoana has raised funds to realize their great business idea, and they’re looking for a developer to help them. Their goal is to test the idea and then seek additional funding to further develop it.

HealthBase

The idea is a platform called HealthBase — a digital health record accessible to patients, doctors, and medical laboratories.

Lab results — Patients have easy access to their lab results, visualized graphically to make them more understandable
Daily metrics — They can also enter their health indicators daily, such as blood pressure
Graphical visualization — Doctors set reference values or the “norm” for their patients’ health indicators and monitor their condition
Personal reference values — Laboratories conduct medical tests and enter patient results into the platform

The idea sounds amazing — I’ve dreamed my whole life of working on something like this! In fact, I want this project so much that I’ll do everything I can to win it!

But what does “everything I can” mean? Is it enough to tell my client Yoana a number, say X BGN per hour, and then hope she picks me because of my great reputation and polished portfolio?

Of course, reputation and portfolio are important, and I’ll talk about that later. But in my opinion, it’s just as important to show how exactly we’ll apply our skills to the specific project, and why we’re the right person for it.

Researching the Client’s Needs

During the research process, the client forms an impression of us as professionals and whether we’ll be a good fit. We also have the opportunity to better understand the idea and build trust between us.

To do a quick research session for Yoana’s health platform, it’s best to have a face-to-face conversation with her.

Key Questions

Every project is different, but there are a few key questions I always ask:

What’s the problem? — What problem do they want to solve, and why?
How do they envision the solution?
How will the business be funded?
What are the biggest challenges?
What do they expect from us?

Let’s see how Yoana would answer these.

What’s the Problem?

The information in lab results isn’t clear
Different systems, reference values, and units of measurement
Patients don’t have access to previous test results

Yoana thinks that for most patients, current health test results are just a pile of letters and numbers — the information isn’t clear. Plus, different labs use different systems, reference values, and measurement units, and the results aren’t easily accessible to doctors or patients’ relatives.

She tells me how she created a Google Sheets table to record her mother’s data, who has high blood pressure.

How Do You Envision the Solution?

Data visualized in an intuitive way
Information structured and standardized
Patients have access to all previous tests and can compare results
Accessible through different devices

According to her, a better solution would be a platform where:

Data is visualized intuitively, not just as dry numbers — more graphs and colors
Information is structured and unifies results from different labs
She wants access to all previous tests and the ability to track how certain indicators have changed over time
The system should be accessible from mobile phones and desktop computers

How Will the Business Be Funded?

Yoana isn’t sure whether patients, doctors, or labs would pay for such a product, and under what terms — so that’s one of the main challenges.

What Are the Biggest Challenges?

Funding — The business model is unclear
Integrating labs with the platform — Different lab systems
Minimal costs — At least initially

Research Questions

I also have my own questions. Yoana can answer some, but others I need to research myself — and that’s what the research phase is all about:

Are there specific legal requirements we need to meet? After all, this is a healthcare product
What’s the team like? Is there a medical professional among them?
Do they have a designer? (Since I’m not one)
Have they done any market research? Have they discussed the idea with friends and family?

Documenting the Conversations

There may be more than one meeting — it’s good to have notes from each conversation and then send a follow-up email.

“To confirm what we discussed — first, second, third, we agreed to do fourth” — so we have everything in writing and avoid misunderstandings on both sides.

Research Results

Let’s come back to Yoana and her idea. After the meeting, I spend a few hours researching the questions and find the following:

There are specific requirements from the National Health Insurance Fund — meaning if we want labs to officially use and pay for the system, that complicates this part of the task and might not be suitable for a minimum viable product
However, there is a possibility for integration with at least one lab that I found
Regarding minimizing costs — we can develop a web application that’s accessible from mobile devices, instead of separate apps for web, Android, iOS, Windows Phone, and so on

What If the Client Doesn’t Choose Us?

What if after all the research, the client doesn’t pick us and walks away?

There’s also the option to agree upfront that the client will pay for the research, after which they can do whatever they want with the information — that’s exactly what consulting is.

But even if we do the research pro bono, our work hasn’t been entirely in vain — we’ve actually gained valuable information about what the market is looking for and what problems people are trying to solve.

Defining Feature Modules

Once we’ve gathered the information we need during research, it’s time to analyze what we’ve learned and briefly describe the system.

I want to emphasize: this is NOT waterfall! We’re spending a few hours putting together a list of notes, not several months writing detailed documentation describing every possible case!

For HealthBase, I’ll divide the features into three packages right now, based on how important they are to the system.

One reason to create packages is to give the client an appropriate price for each package, instead of dozens of individual prices for each feature. The goal here is to avoid the so-called paradox of choice. It turns out that too much choice actually makes it harder to make a decision.

The takeaway is: it’s good to have choices, but not too many, because it becomes harder for the client to decide — especially when it comes to something more important than a pair of jeans.

The Three Packages

I’ve already entered everything into this document since the platform details are very specific and not the main topic of this presentation.

Basic — We usually start with the types of users in the system and figure out the most important things they need
Plus — At the next level, we can add features that aren’t critical to the system’s operation
Premium — In the Premium package, we can apply our special skills. For me, that includes:
- Internationalization, so any part of the platform can easily be translated into another language if they decide to enter markets outside Bulgaria
- The web page can be installed on mobile devices as an app
- Push notifications when the user hasn’t opened the app on their phone

What If We Forget Something?

If clients later ask for something we haven’t discussed, we go through the research and estimation process again — just for that feature — for an additional fee.

Estimating Feature Modules

Since I want to give a price and a deadline for the project, I personally find it important to estimate each feature by two main indicators: time and unpredictability.

Time — The number of hours I expect the feature will take to develop
Unpredictability — The degree to which I might exceed that time. For a relatively standard feature like registration or login, this indicator is low. For something like integrating with lab systems, it’s high

By increasing the Time by the percentage of Unpredictability, we get a rough estimate of the maximum time the feature might take. This helps us determine both the deadline and the price.

All of this is very subjective, just like with Agile methodologies — if we estimate the same table twice, we might get two different values. Over time, we learn to be more accurate.

Let’s estimate a few of these features now. We won’t have enough time to go through the entire estimation process since I usually spend a few hours on it, so I’ve pre-filled the entire table.

What If We Don’t Estimate Correctly?

What happens if we don’t estimate correctly?

We can offer up to 3 revisions for a given feature, with subsequent revisions being paid additionally. This way, the client takes on some of the responsibility for defining their requirements clearly and precisely. How many of you have heard: “I don’t know how I want it, but I’ll know when I see it”?

Otherwise, if we’re within the 3 revisions but it’s just taking much longer than planned — well, we’re behind on our calculations and we take responsibility. But other things will go faster and easier than expected. If we never make mistakes, we can never learn!

Finally, if it turns out a task is impossible to complete — that’s something we should have caught during research. If it truly is impossible, then we’re left with convincing the client that it would take too much time or is too complex, and we should look for another solution to the problem.

Assembling the Packages

Package	Price	Timeline
Basic	€3,800	5 weeks
Plus	€5,700	7 weeks
Premium	€6,700	8 weeks

When I first used this method to prepare an offer together with a desk colleague — a designer — we sent the clients an extremely detailed quote with a price list for every feature. Login — €100, Registration — €100, and so on.

We’ve already seen what the paradox of choice is about, so this time we divided the features into several packages from the start. Another reason is that some modules are closely interconnected — for example, you can’t have registration without a login, or vice versa — so grouping them into packages is necessary.

We already have estimates for each feature, and we can see the total for each package in the table:

Basic includes only the most basic functionality the project needs. Total: €3,800, deadline: 5 weeks
Plus is a fully functioning system, as the client requested, with all the details. Total: €5,700, deadline: 7 weeks
Premium includes our specific unique skills. Total: €6,700, deadline: 8 weeks

There’s a subtle point about package pricing, though. Consciously or not, we might structure them to steer the client toward a particular choice.

If my HealthBase packages ended up looking like this, it wasn’t intentional — after all, Yoana doesn’t exist! But from now on, when someone offers us several options and one is obviously a bad choice, we might wonder whether they’re trying to steer us toward the more expensive option.

For me personally, the most important thing is that I’m giving the client clear prices, firm deadlines, and the right to choose.

Formatting the Document

There are many ways to format the actual document — as a presentation, PDF, Google Docs, and so on.

Now I’ll show you the first offer I prepared with my desk colleague Boyan Kostov, who is a web designer. And here’s what Boyan’s newer offers look like — over time, his approach became much more visual, adding his own branding and design.

Both offers are 6 pages, but one is mostly text, while the other has colors, images, and larger text.

For HealthBase, I’ve prepared a sample offer that’s somewhere between the two variants I showed you — 3 pages, not too much text, you can read it in a few minutes: https://goo.gl/EyHxyY

Presenting the Offer

In person — This is the best option
Video call — If meeting in person isn’t possible, a video call with screen sharing is ideal, so we can answer questions as they come up
As a last resort — If we can’t connect with the clients at a convenient time for everyone, we record a short video presenting the offer

Sending just an email with an attachment makes it much harder to leave a good impression, even if the document is carefully formatted.

I’ve also read recommendations not to surprise the client with the price — meaning we should give them a rough idea of what budget they might need to set aside, in advance.

What We’ve Done So Far

Let’s summarize how we prepared the offer:

First, we had a series of conversations with the client, asking clarifying questions and taking notes
Then we did deeper research to investigate the specific parts of the project
We defined the main features in the system that we’ll be developing
We estimated them by deadline, unpredictability, priority, and assigned our own price to each feature
Finally, we formatted the offer and presented it to the client

The Lesson Hidden in Every Offer

By following this process, with each new offer we learn something more about what works and what doesn’t. For example:

More graphics, less text — In one of the offers I showed, there was too much text, too many variants and choices, making it much harder for the client to make a decision
Document the process — If I had documented my work process by writing one blog post per month, I’d have 12 posts a year as a result. Now I wish I had started 5 years ago!
Commonalities across projects — When I started breaking projects into features and estimating them, I began noticing certain tasks that come up in every project. Registration, login, some basic styles, notifications, and so on
Build a portfolio — All of this helps us grow our portfolio, attract more and more interesting projects, and develop our own solutions to common problems. I’m not just talking about programmers — many designers develop their own design systems, icon packs, stickers, and fonts

Real Examples

Boris (design and animation) — https://noxious.one

Boris noticed that some of the companies he works with already have a logo, but need it to be more dynamic — for example, for a video intro or as a loading indicator on their website. He specialized in bringing static logos to life by animating them.

Svilen (illustrator) — https://sm-artists.com

Svilen is an illustrator. He’s had many clients who wanted a caricature drawn from a photo — suitable for social media avatars, gifts, or the “About Me” section of their website. The service has clear steps and a fixed price.

By the way, here’s how he drew me in a hurry.

In conclusion, regardless of exactly what direction we’ve specialized in, if we work as freelancers, it’s entirely possible to create our own products and services that generate additional income.

The Rising Tide Lifts All Boats

Let’s circle back to offers and why we should bother preparing them.

If say, only 10% of freelancers do research and prepare offers, then we stand out from all the rest who just give a single hourly rate. By preparing an offer, we have a competitive advantage.

But what happens if 100% of freelancers start doing research and preparing offers? Won’t we lose our competitive advantage?

Well, yes — probably. But then the entire industry would be at a higher level. And the best among us will come up with new competitive practices that will gradually be adopted, until they too become mainstream.

The rising tide lifts all boats.