The finer points of approaching a developer are one of the many actionable things over 1,200 registered attendees are learning at the first annual Columbus Startup Week. Dan Rockwell of Big Kitty Labs dished on the do’s and don’ts of working with a developer, and gave anyone with an app idea some advice about where a business should be before even thinking dev.
In a world where “I just want to go and get stuff done” is not a feasible answer, the more prepared a client can be before approaching a developer, the better. While that seems like a no-brainer, “prepared” goes beyond just having an idea.
Rockwell provides some insights on a developer’s mindset when approached with a project. They want to get the job, do good work, be paid for their expertise and make their clients successful. But most of all, “If you’re going to approach a developer, they really want to know what they are going to do,” he says. Many clients want to just go straight to the prototype, but there’s a lot of back-end work to get there. And, when a client doesn’t know, things tend to get really expensive.
“When you know more, you protect your cash,” Rockwell says.
Speaking of cash, the wrong question to ask is, “How much will this cost?”
“We should be talking about how many experiences are you making,” Rockwell says. “When I think about experiences from the dev perspective, I’m thinking about how many actual instances where a user is doing something.”
This means thinks like the back-end, the splash page to show off the product, a log-in page, an iOS platform, connections to social networks, etc.
“Each one of those landing points is between $10,000 – $15,000,” Rockwell says. “And that’s with me knowing that you know what you want.”
That also fires off a whole other list of things the developer is thinking about. Where’s the data coming from? Is it user-generated? Do you even have users yet?
“Making data is hard,” Rockwell reminds clients.
What about designs?
“Start drawing what you see in your head,” Rockwell says. While that might see like the antithesis of building something online, even old fashioned pen and paper sketches go a long way toward being prepared and knowing what you want. Also, Rockwell says to not be afraid to reference other designs as a starting point.
Other questions include what’s the goal? What about user flow? Timeline? Criticals? No, everything is not critical.
Finally, there is what are you not telling me and what are we not discussing? That means things like branding and validation.
“The developer, we don’t’ think about validation,” Rockwell says. “That’s your job. That’s your startup. My job is to enable you.” The developer delivers the minimum viable product so a startup can get their idea out there. Rockwell recommends making the rawest thing possible and validating it before making it really, really sexy.
Pretty much nothing on earth goes exactly as planned. There’s going to be changes along the way. What a client just sees as a design change, a developer calls creep. And creep kills.
Rockwell provides an analogy of what creep looks like. A client says I want a boat. The boat is made. They see the boat and say…meh, it’s more like a catamaran. Ta-da, catamaran. Well, maybe not. It’s more like a wakeboard. Now you’re six months in with three different products. Avoid, avoid, avoid.
While creep is inevitable, the client can help keep the scope under control. Developers plead for transparency. It helps them sniff out factors that may lead to creep. A client can help by knowing what they want, respecting the relationship that’s in play, and thinking simple. (Remember, not everything is critical, you want your MVP.)
App development has a lot of nuances and a lot of layers, but Rockwell wraps up with some general do’s and don’ts that will make the whole client-developer relationship a little easier.
Do
- – Your homework on developers
- – A fault analysis on your own idea
- – Ask a developer what can make this project rock
- – Ask a developer what can make this project suck
Don’t
- – Don’t ask the developer if your idea is any good (remember, that’s not their job)
- – Don’t ask the developer to take equity in lieu of cash (you’re putting them in a founder position and that makes everything more complicated)
- – Don’t build beyond your gut assumptions
A developer wants you to be successful, and they are there to build the vehicle to help you get there.
