Founders, did you embark on projects with developers (freelancers, cofounder or dev companies) that have gone very well or very badly? Why did this outcome happen? I'd love if you could share your stories as I'm interested to see what the learnings from each scenario are. Thanks!
Well, I own this App Development Company called Agicent and following are some not-so-good stories, but its fine being part of business we are in:-
That much for now, and as I said these are just not-so-good stories, else its always a good time with customers, making them great apps, supporting in promotions, planning on next phase all this is just too much fun. :)
How much time do you have???? ;)
1. Mismatch of business model - $ for time on developer side doesn't always yield value on client side
2. Non-delivery - promise of meeting fixed price, no delivery, cost 2x as much to get someone else up to speed to fix the issue
3. New developer wanting to totally rewrite whatever was previously built
4. Promise of lower cost (offshore, nearshore, moon shore... just kidding on that one but it's coming), but no one mentions the longer delivery time or the cycle time
5. Oh you want code that works?
6. Oh you want instructions on how to compile it and load the source?
7. No ability to shift the model to match the company's model - revenue sharing and/or equity for significant contributions
and on and on she goes....
Great topic, I'm an app developer and would love to hear stories from other side. Here are a few from dev perspective in case you find them interesting (most of my projects are in 20-50K $ range):
1. Lack of clear specification is a huge problem. The client wants X feature, but doesn't have specifis figured out yet. Going back and forth is very costly.
2. Working on existing systems which are poorly written. When I need to work on a code, which is hard to read & understand, I need to put extra hours to make sure I don't break anything and introduce new bugs. Poorly written code often lacks support for all edge-case scenarios, so sometimes it's better to rewrite stuff from scratch - especially for crucial parts of the system.
3. Cutting corners & rushing work. When you want to quickly introduce something and push dev to deliver faster than he esitmates he needs to cut corners and code quality suffers. It might look ok, but in the end will cost you money - either trough bugs or extra work in the future. So rush carefully :)
1. Regular meetings/calls where you can sync on the work and address any problems that block the work or make it harder.
2. Make sure your team supports each other and works on their area of expertise. E.g. if I get proper assets from the designer, I can focus on my work. And when I get poor assets, misaligned, etc. then I need to spend extra time fixing them or communicating.
3. Understand that estimates are estimates, nothing more. We, devs often understimate the work, because we are superheroes and we also feel this pressure from above to deliver quickly. So make sure to add 30-50% to our estimates to be on a safe side. Also it's really hard to estimate the work when you don't have proper specification in place. 'I just need a login screen' is impossible to estimate correctly :)
4. Trust your devs are doing the best work and give them some space. If you start micro-managing then there are too many distractions for a good flow. On the other side some pressure is good as when devs get too comfortable, they have costly ideas of refactoring everything around them ;) So you need to have a good balance of freedom and control.
Hope this helps :)