dbates · HackerTrans

vor 15 Jahrendiscuss

I wrote this post to give people a different perspective on answering the freelancer vs. dev shop question. We've had a number of entrepreneurs lately asking about the difference between the two and it seemed like a useful way to explain the difference. The value proposition for working with Terralien is very different. We're all about long term relationships with entrepreneurs and helping them build their business rather than just an app. Thanks for the comment and opportunity to clarify that.

dbates

vor 15 Jahrendiscuss

This is a great point that too many entrepreneurs miss - hoping you didn't personally get burned on this! Unless you're in a partnership where you explicitly want to share IP, it's "works for hire". Good advice to avoid work with any developer (freelancer or otherwise) that doesn't fully and contractually recognize your rights to the IP.

dbates

vor 16 Jahrendiscuss

In my new project, I keep hearing about all the people who did it before and stopped. Some pretty big players that are household names. I'm keeping an eye on what they've done and why they had to stop while not getting drawn into the "well, if they did it and failed..." quicksand. There are key new developments that weren't present when the big guys killed their projects so that's what keeps me moving forward.

I've also been worrying about the whole "what if I find out someone else has figured this out" thing. I think your post is a swift kick that says to keep an eye out but to spend time building instead of worrying and to keep going if the market supports the innovation. Thanks for the post!

dbates

vor 16 Jahrendiscuss

I checked out your post and you’ve got some great thoughts there.

I’ve been given some of those BDUF software projects in the past and they’re definitely painful - if not impossible to deliver. The only reasons they were successful were that the clients were enormous and ultimately paid for us to keep modifying spec documents as we went along.

We planned for that going in and the fixed price agreement was loaded up with all kinds of contingency (read, lots of extra cost to the client). In the end, it cost them more and delivered less. Sure, they got a great “as-built” plan showing exactly where things were different from the original blueprint - but having a great looking plan wasn’t the real goal. The sad part was that we could have done so much more feature development with that extra money.

Early stage entrepreneurs (which is who the post is about) are different. They don’t have the time or the money for that kind of inefficiency. They need an app that works. Now.

We do some up front work with them to lay out the flow of the major features. Then the client prioritizes them and we start with the most important thing first. We push new code very regularly and they tell us when they think it is working well enough for us to go to the next feature. Not sure that would be realistic in a fixed price model.

I like your final point in the BDUF post - that the development of the software is organic and ultimately determined by the process. Sounds like a great rationale for T&M vs. fixed price!

dbates

vor 16 Jahrendiscuss

This is exactly what I was going for in the post - that T&M gives the client and the developer a chance to team up in the most flexible way without lots of renegotiation.

In an early stage project that's often budget constrained, and where the entrepreneur often isn't 100% sure what needs to be built, a fixed price agreement would waste a bunch of their money - either by forcing them to finish something that wasn't right for their market or by spending precious time and cash to renegotiate.

comments