Mentorship Series Edition 1: Client Project Valuation, Accepting Shares for Work, Being a Technical Founder

December 17, 2021

Welcome to the Mentorship Series on Muya’s Blog.

Here, we explore and answer questions that I’ve received from folks who are starting out on their Software Development journeys, and some further into it.

We’ll be sharing my responses to the questions from mentees; as such, the views expressed here are personal, and are not meant to be canonical advice; take what you like, leave what you don’t.

All the questions have been shared with consent from the mentees, and edited for privacy and clarity.

I hope you learn something! Karibu 🙌🏽

Edition 1

In the first edition, we explore possible approaches to providing estimation for a client project, how to evaluate if you should accept payment in shares, and possible approaches to being a Technical Founder.

Question 1: How do you give a client valuation for a software project?

Valuation can be approached in several ways (not exhaustive):

  1. How much time you might end up spending on it (including maintenance after it goes live)
  2. How much value it can return to the client (you’ll have to prove that it will return a certain value)
  3. How much worth it can return to you (e.g help build your portfolio)

Option 1: How much time you might end up spending on it

For this, you’ll first have to know what your rate is (e.g. how much do you charge hourly)

Based on that, you can estimate how much time working on the project will take, then you can do a calculation based on that.

For example, let’s say your hourly rate is $20, and the project is estimated to take 40 hours (this time should be based on how much time you actually have, e.g. considering school, other clients, etc).

So base amount becomes: 40 * $20 = $1600

Then you can consider how you want to approach maintenance of the project after it’s completed. For example:

  • Provide a 3 month cost-free maintenance window, then bill for any additional work or requests based on your rate
  • Have the client retain you on a retainer basis, where you agree on a monthly fee, and you’re available for support (this should be separate from “new requests”)

As you can see with all this, it’s very important to have a contract with your client.

The contract can say something like:

  • These are the features we’ve agreed on
  • This is how long it will take
  • This is how much it will cost
  • This is what we’ll do if there are modifications to be made, or features to be added

For Software as a Service (Saas) projects, it’s also important to factor in costs that the client will have to cover after the project goes live, e.g. servers, hosting, etc

Option 2: how much value it will return to the client

In this scenario, you end up doing research and showing the value that the product you’re building will bring to the client.

For example, consider this high level scenario:

Let’s say that the client currently has an e-commerce website, and they want you to update it so that they can get more clients. Let’s say that for every 100 people that visit the website per day, 10 buy something, and the client earns a profit of $50 per customer.

So currently, their profit comes to: $50 * 10 = $500 per day.

If you improve the website, and now 20 people out of a hundred end up buying something (i.e you’ve increased conversion), then it means you’ve increased the client’s profits by 100% (they’re now getting a profit of $1000 per day).

So in this case, you can tell the client: Based on this work, we’re able to increase your returns by 100% This can be a starting point for a negotiation for how much the project would cost. You could agree that after the improvements are made, you get to keep 20% of the profit made (so you keep earning as long as the project runs); OR You could project to your client the value of getting 100% increase in profit over 1 / 2 / 5 / 10 years, and propose that the client pays a fraction of that, once off.

In this case, you’re showing the value you’re providing, so you have a stronger negotiating base.

This option, however, requires that you do quite a bit of research so that you can demonstrate this value to the client. So it means that it’s useful to have some context into the client’s business.

Option 3: How much worth it can return to you (e.g help build your portfolio)

In this scenario, you’re looking to increase your exposure, so maybe the financial returns you get are not a huge priority.

You might end up taking the overall approach of option 1 (i.e have a billing rate), and then you can use this project as part of your portfolio.

As is the case with option 1, a contract is important, and it’s useful that you agree on the terms and scope of work.

Project Pre-Work

In all these approaches, there is “pre-work” that you may end up doing so that you can present a case to the client.

For example, you may spend time preparing a presentation with all the research and a proposal for the work to be done.

Remember, at this point, you are actually working, so it makes sense to bill for this. Your approach to billing here may be that you offer a slightly lower rate, or you agree with the client that the time spent in the proposal will be included in the overall project cost – either way, you need to get paid for that as well.

This aspect of billing for the proposal also allows you to weed out the jokers vs. people who are serious about a project.

@tom_hirst wrote an excellent thread on this topic on Twitter, I highly recommend checking that out.

He’s also written an excellent book on Pricing Freelance Projects, I recommend you check it out:

Question 2: For clients that want to pay in shares, how do you evaluate if that’s a worthy commitment that will pay off in future

This is the thing, you can’t really know, because you can’t tell the future.

This approach is usually taken in startups where money is tight – but it’s always a gamble.

Most times, unless it’s a very unique idea, it’s probably not worth it.

That said, this could be an opportunity for you to execute Option 3 above: building your portfolio.

So you can choose to charge a reduced rate + the shares.

Again, a contract is very very important here. It’s better to have it all written down!

Question 3: Suppose you were to form a company as a technical person / founder, with the other person being the “business” side of things. How do you justify that the technical expertise is worth a part of the company, when the business person is the one doing the actual funding?

I think that justification comes from showing that value that will come from your technical contributions (similar to Option 2 above)

For example, when discussing this, you can ask them to either:

  1. Pay you for each transaction/sale that comes from whatever tech you build
  2. Give you a share of the business upfront
  3. Pay you just for building all the tech (and then you hand over afterwards)

So you can present these options, and then you can agree on which approach to take in your partnership.

For example, if they don’t have the money to pay you for upfront building the tech, then giving you a share of the business is the “debt” they incur to get your services.

When you phrase it this way (i.e. as “debt”), the negotiation becomes whether or not they think it’s good debt to take on.

Conclusion

This wraps it up for this edition of the Mentorship Series! I hope you learned something.

If you agree / disagree with any of the points, I’m happy to engage in meaningful debate.

Until next time, stay safe, and happy coding!