My pricing is simple: I charge one hourly rate for everything I do. My billing is for time and materials, and my rate is the same regardless of complexity or duration.
My hourly rate is based on the value of my service and my time. Usually the main resistance to an hourly rate is trust (and ethics), and I expect this to take time to achieve… so I’m happy to start off with a conversation, and one or two small tasks so we can make sure it’s a good working relationship. It’s also OK if you’d like to move on – perhaps you’ve outgrown my services (you need fulltime coders), you’ve found someone locally, or we’re not a good match.
I charge an hourly rate (time + materials), and never fixed bids.
Why not Fixed Bid pricing?
A fixed bid project incentives coders to cut corners, and it also provides a setup for confrontation when scope of a project changes, features weren’t properly understood, or additions are needed. Fixed bids are usually faulted to begin with, because a premium needs to be charged to account for the “unknown” obstacles which will be encountered (and there’s almost always challenges that you can’t foresee).
The old adage of “you get what you pay for” applies here, and I’ve worked on MANY projects which were started by a low cost development agency that outsources/offshores the work to low quality developers. If you’re looking for the cheapest option, then I’m not interested in working with you because you view a coder as a low-level worker, not as a partner. If cost is the major concern, I’d encourage you to seek an low-cost (low-quality) development agency, but be prepared for the amount of work you’ll need to do to manage the project, check their work for errors, and expect delays and challenges along the way.
Many of my clients have come to me with code from such agencies, with the impression that it’s “90% done”.
Here’s where I’m different from other coders: Most developers will look at a really bad codebase (spaghetti code) and scoff, suggesting a rebuild from scratch using the newest technologies. I’m much more pragmatic: depending on your short and long term goals, budget, timeframe, we can collaborate on a good solution. Sometimes the right decision was to work with the bad code currently in place, warts and all. In other projects, I’ve made a plan with the owners to slowly update legacy code over time, implementing things like OOP, database abstraction, autoloaders, etc. slowly, so that there isn’t a delay in getting the site live, but also so it’ll be more easy to extend and maintain going forward. And yes, a couple of times the decision was triage of the current code, followed by a complete restart from scratch.
My point in talking about all this is to try and convey the value that I strive to bring your company.
Interested in knowing more? Send me a note and let’s get the conversation started!