A recent discussion in one of my tech forums turned to a question of how to price yourself when you’ve been approached about freelance development gigs. Much good information was shared on topics including new developers getting their first paying gig, race and minority status in the job market, the temptations that lead to undervaluing your work, and how to research the going market rate of development time.
I wanted to add some perspective from the Scrum Agile world. I believe working in an Agile framework has a lot of advantages even for a single developer working at home on freelance gigs. Thinking like an Agilist can change the way you respond to requests for work, or bids.
Most discussions are going to start with one of the parties focused on “How long with it take to do X? What do you charge per hour Y? I can therefore expect it to be complete by date Z”
Consider pitching them an alternative business model. If someone is in the sandwich business, there’s no reason to assume they’ve ever heard of Agile. One of the beautiful things about the Scrum framework is setting development as an assumed continual cost (until the product is retired), and holding cost as a constant. The shift has been from “project focus”, where we assume something will be “complete”, to a Product focus, where we assume a new technology will have a continuous life cycle as long as it serves a purpose for the customer. One of the great benefits of broad Agile adoption is that almost anyone you talk to about a gig will be familiar with the “early and continuous delivery of value” model. They have all loaded a minimalist app on their iPhone, and they are used to receiving app updates every couple of weeks. Pitching them a business model like this may help them feel that you’re a more sophisticated professional.
Instead of saying “It will take X hours to complete this whole list, and I will charge Y per hour”, I would ask them a few questions:
A. “How will you maintain this product once the initial coding is finished?”
B. “How long do you see this (application) being useful to your mission?”
C. “Do you see it increasing in value if you add more features in the future? Do you expect your users will have ideas and requests for more features?”
D. “When do you plan to retire it?”
E. “Do you have a technical support and operations IT team on staff that I can hand-off my documentation and source to?”
F. “What will you do when you’re ready to add more features to this product?”
It’s likely a prospect for freelance work hasn’t thought that far ahead. One of the ways you may impress them is by consulting them on these aspects of modern development that other bidders are not likely to bring up. After asking those questions, I would pitch something like this: (an imaginary dialog)
“I find your project really interesting, and I look forward to helping you achieve your goals of XYZ. I think that will be exciting to see come to life. Let me tell you a little about modern trends in software development. Most companies have now shifted from a “Project” mode to a “Product” mindset.”
“What most development efforts do now is called ‘Agile’, and we assume the product will have long term maintenance, updates, and improvements; it will continue to become more valuable over time. You’ll want to have someone available to maintain and improve the product as long as it’s still creating value for you. The great thing about Agile is holding costs to a predictable, fixed budget. Let’s work out an amount that is within your monthly budget, and then we will work together to plan out the individual features that will make this product useful for you.”
“I will work on those in a priority order, and estimate how much I can complete within a fixed time every month. If you feel like the pace is too fast and cost to high, or the pace is too slow and you have room in your budget, we can adjust the amount of hours for a new fixed cost, and the pace of development. You’ll know exactly how much you’re going to spend every month”
“We’ll start by breaking the big idea into a ‘Minimum Viable Product’, the smallest feature that adds value to your users. I can have something simple for you to review sooner, instead of delivering one big thing at the end. Your users can start testing it out early, and we can make changes to the plan as we go. This prevents a big sunk cost down the wrong path. We’ll break down all the other feature ideas beyond the MVP, and we’ll estimate how long those take to develop, and see what the pace of releases looks like within your budget. By breaking things down to the smallest size possible and releasing and testing early and often, we’ll get you exactly what you need and no more, as early as possible. If you want to continue developing the product, we can, at a budget you feel comfortable with”.
“Once we’ve completed a few releases, I’ll be much more familiar with the codebase, and how to approach changes and improvements. I’ll be able to give increasingly better estimates on the pace and completion of items. The work should become easier, so you’re getting more value delivered for your fixed budget”.
I’d almost guarantee the client has likely not thought of this route, and if you’re bidding against 10 other people, it’s very unlikely any of them will suggest it. My suggestion is avoid over-promising and trying to minimize the “pain” of the price. Instead, set yourself up for a stream of income based on a set number of hours you can schedule in your calendar every week or month. And the benefits for them are (1) planned, consistent budgeting at whatever level they are comfortable with. (2) Seeing results early and often.
Top comments (0)