8 ms·
Source: I've run an iOS contracting company for the last three years. Here are some big problems: * Lead qualification. This is an enormous problem. Lots o
by drewcrawford 15y ago
Source: I've run an iOS contracting company for the last three years. Here are some big problems:
* Lead qualification. This is an enormous problem. Lots of people want revenue sharing deals, etc., and it takes too long to work out whether they're serious about the project and whether I'm the right fit. What do they do for a living? Is this a corporate or personal project? etc.
* Client acquisition cost. Most of the options out there for advertising, etc., don't have a good ROI. It's super difficult to measure advertising effectiveness because you only have a handful of "conversions" (new clients) and thus your results are never statistically significant. It's all black magic and voodoo.
* Pricing. We do 99% fixed quote so hourly rate isn't really the issue. In my market, you adjust the scope to fit the budget, not adjust the budget to fit the scope. The problem is that clients play very close to the vest on what they want to spend, meaning I have to guess what they want to spend. If I guess right, I get the project, if I guess wrong, I will never hear from them again. The whole market is a game of chance, not a game of skill.
* Slow clients. It doesn't matter if the feature takes 1 hour or 5 hours if the client takes 4 weeks to get back to you. Tightening up our business process has improved this considerably from what it used to be, but I imagine a number of contractors experience this schedule unpredictability.
* Client education. Milestones, scope, test builds, etc., are just not in the vocabulary for non-software-background clients. Why the Estonian firm quoting $2000 for a $20k project is lying. How to collect crash reports. How to describe issues so that we can reproduce them. etc.
These problems are WAY bigger than anything you've listed. But about those:
* Project length - Rarely have I thought about this apart from the "Slow client" issue. There are no projects too short, or too long, for me to do, particularly if it's well-paying work.
* Good requirements - we usually write them. Being in the fixed quote business, we're pretty good at it.
* Scope creep - this is a minor problem for us, but we've tightened up the business process and are close to completely eliminating it as a problem.
* On-time payment - Another minor problem, recent changes to the business process are close to eliminating it.
* Negotiating the rate - we rarely do hourly work, so our version of this problem is the "Pricing" problem above.
If you are working on a startup in this space, please sign me up to give you feedback, as I could go on for hours :-)
- rpwilcox 15y agoAmen about the lead qualification. I just had this happen today: I spent a few hours on an email for a potential client whose project sounds like 3-6 man-months of work. Now, does he really have that kind of dough laying around (ie: angel funding), or will I never here from the client again because he was hoping to get it done for $200? (Or worse: profit sharing / equity arrangements. Equity doesn't pay my rent.)
- famousactress 15y agoThis is interesting to me. Budget isn't something the conversation leads with?
- rbranson 15y agoMoney should be talked about in the first 30 minutes of discussion about any client project. Rates, budgets, ability of client to pay, etc.
- rpwilcox 15y agoI've been thinking about revising my tactics some, to try to get a potential client to spill what kind of budget they have to work with before I even start thinking about anything else. It certainly helps sometimes in picking out project infrastructure ("I have to do this cheaply, so let's get inventive")
- kls 15y agoIf they don't give me a budget I give them an hourly rate until I know what budget they are working with. That said, I prefer to work on an hourly arrangement if at all possible.
- rpwilcox 15y agoI think starting with an hourly rate is uninformative. For example, if a client's budget is low I might grab a RAD tool to get the job done (while letting the client know that this decision might hinder flexibility in the future.). "You want a database on the web, that you can customize yourself, for $600? Great, let's grab a copy of FileMaker Pro, or sign up for Quickbase.com and get going" Yes, those solutions may limit potential of the app down the line, but they might actually be the right fit. I'm another hourly-rate-all-the-way guy, but if I can extract the budget out of the client, then I can decide (essentially), "Given the client's other requirements, will a RAD/off-the-shelf/OSS-package-with-a-custom-theme work for this project... or do I just politely tell the potential client to get bent?"