Pricing is never easy. Estimating work is one of the most tedious activities for me when discussing a new project proposal – let alone a migration or something based on existing code base.
This was the reason for me to write Why Are Estimates Challenging For Custom Development Work? and engage in similar discussions every now and then.
The main problem is that there’s often a disconnect between a customer’s expectations or budget and the cost of building a solution. Most of the actual development goes into building various layers that don’t expose UI, integrating caching engines, dealing with security prevention mechanisms and the like.
A platform could be designed differently depending on the growth of the business, too. Everyone can set up a website with a DIY builder or a self-hosted solution running a few modules. But as the platform grows, more and more time has to go into maintenance, refactoring, ongoing development.
Which is why our entire business model revolves around monthly retainer agreements – since it’s easier to allocate resources and work continuously on improving all platforms we’ve built.
Here are several considerations regarding determining the cost of a project.
I’ve intentionally used 0 as this would make or break the rest of the estimation process.
A regular inquiry from a customer may include an RFP asking for a complete design of a university website with 25+ pages, a student portal, a complete management system embedded in the website, and then some.
Before proceeding further, let’s determine the responsibilities.
- First off, are you a designer or a developer? Could you do all the work yourself? It’s likely that you need to partner up with someone and determine their fee and costs for their part of the project.
- Also, who’s doing the design? How many iterations would you let your client review before agreeing on the layout? Are there any constraints in terms of flexibility (sliders, galleries, parallax)? Are there common page templates that you can unify for some pages – or everything would be completely unique? What about the tablet and mobile versions?
Then we move to the student portal bit.
- How would this one work? How many user flows would we need to define? What roles would the platform support (teachers, student, principals, admins)? What would be the capabilities for each role? What would the student portal entail and support?
- Same goes for the “complete management system”. Every time I read “complete”, I cringe.
Without defining the scope to the latest detail, you’ll have a hard time figuring out the amount of work to be done. You may very well end up spending 50–60 hours on the basic build and receiving a 40-page list of missing features, eating up another 1,000 hours outside of your initial budget.
1. Hourly Rate
While many are against hourly pricing, it’s still a viable way to determine whether a project would be a profitable gig to get involved with.
You don’t necessarily have to price hourly – but you need to do the math for yourself.
Here’s a sample calculator that you could use if you’re unsure of your expenses – Freelance Hourly Rate Calculator by Freelance Boost. That’s meant for full-time freelancers adding all of their expenses, vacations, taxes, equipment costs and the like.
It’s much better than dividing your salary by 12 and then by 160 hours monthly. There are too many variables on an annual basis.
Using the hourly rate, you have to estimate the complexity of the project based on the requirements. You will likely have to add some buffer for revisions, communication overhead, and everything else in-between.
2. Total Cost
The hourly rate would be the basis for coming up with the total cost of the project.
When you come up with the final number, consider how realistic it is. Think about a lightweight version with limited features or a Professional plan that goes above and beyond. Sending two to three different estimates with varying features may work out well for some clients.
You will need some form of a contract in order to define everything in details – including communication and payment iterations. Otherwise, you’ll likely end up waiting for feedback for weeks or asking for payment for several months in a row.
3. Technical Stack
Ideally, you’ll decide on the right starter framework or a platform that you could accomplish the goals with.
If you attempt to build everything from scratch, it may not be desirable in terms of the amount of time and budget. Sure, there are plenty of examples where this is the right way to go – but if a framework will cut 20% of your time or an existing platform solves 90% of the problems, that’s worth noting as well.
Many clients are using an existing technical stack and may have preferences to a certain technology. If the platform has to be deployed internally by the systems team, they may already run a web stack.
And it’s possible that they don’t want to set up a new web server, a database engine, or anything else for that platform in particular.
Or the management team may be familiar with Moodle, WordPress, some self-hosted LMS platform – and more willing to utilize it if possible.
Since the technical stack would affect the budget, discuss that upfront with your client.
The key thing we’re always trying to determine early on is the estimated Return on Investment for a new build. The ROI is never clearly defined but you can speculate.
A good starter basis is figuring out how much time and money will the platform save or earn your client over the course of a year or two.
- What is the current process for dealing with students?
- How many people are involved with this process?
- What would be the main benefits of going with the platform as compared to the existing workaround?
- How much time would be saved by the business when the platform is live?
Essentially, if a business has 10 people half-time dealing with applications and unhappy students losing emails due to the lack of a better option, you may effectively save the time for 5 full-time employees and their corresponding pay checks and then some.
Roughly speaking, if the new platform can use 2 half-time people managing everything and more students are likely to apply thanks to the new process, we’re talking 4 salaries $XX,XXX/year each plus increased revenue due to more applicants and better brand awareness.
Charging a percentage of that would be absolutely reasonable when working with the right client.
After all, it’s about solving a business problem. The better you solve it and the more time saved/money gained, the more sense it would make for your client to pay a percentage for building this magical platform.
Most clients talk to different agencies or freelancers – plus friends. They have some number in mind – more or less – and use it as a basis when discussing the bids.
- If your client is more eager to talk to larger agencies, you may want to provide a cost-effective solution and a type of service that goes through fewer hoops in order to get something done.
- If they’re talking to each and every freelancer, it’s likely that they would be tempted by the low price. Focusing on quality, results, and outstanding service is absolutely mandatory.
As a final note, we always try to talk price early on. It doesn’t have to be a fixed budget but we still push for some expectations early on.
Since You Were Expecting a Quote…
There’s no way you can get one given a limited set of requirements.
But here’s a hypothetical process you can follow – very roughly – in order to come up with some ballpark.
- Use the Freelance calculator linked above and come up with your hourly rate. Say, $80/hour
- Gauge your skills based on your experience and the market expectations. You may need to start low or don’t bill part of your R&D since you’re still learning.
- Conduct a set of extensive discovery sessions with the client. The more details you can gather, the better.
- Figure out what are the main activities you need to be involved with yourself.
- Decide on whether you need help for certain tasks (design, server management, etc).
- Find freelancers or agencies you need to cooperate with and try to assess their expenses.
- Consider the available applications or frameworks that you can utilize.
- Build a detailed scope/specification/proposal included each and every step of the process in-depth.
- Include a clause covering the areas you won’t work on – along with certain constraints.
- Cover project management and communication overhead.
- Add a buffer for unexpected surprises or additional fixes (during the QA phase and so forth)
- Get a sign-off and make it happen.
If that university platform could leverage WordPress with LearnDash or Moodle integrated with WordPress, or any other off-the-shelf platform, you can save a couple hundred hours of custom development and invest 30-80 of them on optimization, custom features, bridges, proxies – whatever. That doesn’t exclude the custom features.
Your list may go as follows:
- Project management, planning, communication: 20 hours
- Integrating platforms X, Y, Z – 10 hours
- Building 5 extensions for A, B, C, D, E – 60 hours
- Design: 50 hours
- Front-end development for 8 different page templates: 30 hours
- QA: 20 hours
- Server setup and management: 20 hours
- Training: 10 hours
Those numbers are definitely pulled out of thin air since they depend a ton on everything else to be discussed during the discovery session.
In that scenario, we’re at 220 hours at $80/hour or $17,600. Quoting $20K with some buffer for enhancements or regressions may be reasonable (if not lower).
Since we’ve discussed ROI, doing the rough math early on would help. If that’s a new client that’s just bootstrapping, they may rather go for something much simpler and less powerful at first (thus cutting costs) before investing in that. if it’s a large university group, a $50K quote could make more sense as the number of stakeholders and the system requirements may be much more complicated (in terms of scalability, security, ADA compliance and tons of other areas that need attention).
In reality, we may be projecting a spaceship when the customer needs a baby stroller. If we are willing to build a stroller and this won’t conflict the business plans, we’d adjust accordingly. Otherwise, our first step would be explaining all of the problems with “going cheap and fast”.