3 ms·
I’d like to extend your point about the first meeting being free. I have a long standing principle I borrowed from lawyers. The first consultation is free. I tr
by techdragon 8y ago
I’d like to extend your point about the first meeting being free. I have a long standing principle I borrowed from lawyers. The first consultation is free. I try to keep it to an hour, but I don’t hold clients to that time limit, if it takes half a day to wrap my head round a project, that’s what it takes and it’s still just one consultation and it’s free. I’m not about to charge you to find out that I’m the wrong guy for you, or that you’re the wrong place for me.
It’s always worked well. So well in fact that I’m pretty sure I’ve beaten out less expensive people by virtue of being first through the door, signing paperwork and seeing source code... because I’m “free”.
It might not work for everyone. But it’s working for me.
- ahmadss 8y agoJust chiming in that this is how the bigger software dev agencies do it as well. I worked at Viget (www.viget.com) and now at Pivotal (pivotal.io) on the biz dev / sales side and spending time on pre-sales analysis is key to making a software project successful and thus winning the deal / securing the contract.
- dopeboy 8y agoThis is pretty fascinating to me, thanks for sharing. The analysis you're referring to - how long does it take for the big clients you deal with? Is it mostly meetings?
- ahmadss 8y agoHappy to talk in more detail directly (email address is my HN username at gmail) but in terms of the analysis done for software projects, the timing is generally a combination of 2-3 meetings over a period of a week or two. Each meeting can be an hour or three, but the goal is to get a sense of a) how mission critical the app is b) what are the primary challenges the client is trying to solve w the app in question c) who are the users of the app d) what does the client know about the users and their needs / pain points e) what are we going to prioritize when building f) who are stakeholders involved to get buy in g) what does the codebase look like and can we build atop it or is this gonna be a net new effort. When I'm trying to closing six, seven, or eight figure software dev deals, this process definitely involves a "sales" type of person as well as two - three devs and architects. The outcome is a proposal that sometimes is just a powerpoint deck with a summary of our understanding of the problem and the process / cost / timeline we'll take to solve it. Once I deliver the proposal, then it's all about getting to agreement on cost, timeline, and then getting signed contracts. Rule number 1 is that a deal is never ever a deal until the contract is signed and executed.