Am I the right developer for your project? How can you tell?
As a contract developer, the first question a client asks me is “what is your rate?” If I am the only person available with the skills, my rate should be different than if I am competing for a job. It is like asking “how hungry are you?”
There is a problem with knowing the cost of everything and the value of nothing: how do you know in advance what something should cost? Oh, “The market set the price”, I hear you say. “The market is king!” Really? Do you want to motivate developers toward technical excellence?
A “rate” is not necessarily a “quality differentiator”. One technology could get the job done in one day, another may take a week. Which do you want to pay for? You simply want to buy experience.
Developers may have financial motivations, sure. But is that the primary motivation? Is technical progress not a more powerful motivation? Every developer I have worked with is motivated by technical advances and invention.
Invention. That is what we look for in a developer – have you invented anything? Remote Developers do not need a “rate” – they work to achieve your business goals, take pride in progress and charge a fair fee against a budget. Why? Because we are inventors, not employees. A budget is simply a scope. A scope will creep and efforts to stop clients changing their mind are simply futile.
If you want to create a Minimum Viable Product (MVP) to test your idea on the web, you will want us to work to your budget. You want us to be motivated to get results. To develop using the latest and greatest software methods.
Your budget gives us a scope to explore new technologies or to simply employ what we tried already. Innovation may cost more. Or it may result in a better product that works for you.
It comes down to communication.
You may need to review your budget when your MVP needs to be extended to create a working business proposition.
We believe it is best to mark progress and provide clients with technical proficiency. A budget simply provides predictability