Hey, I'm one of the programmers working on this project. We actually have a feedback form ready to go, we just ran out of testing time before the launch today. We'll be pushing that change in the next couple of days.
He seems to argue that you can build a more robust application from the ground up. In my limited experience it's the hand rolled applications that are and out hand and unstable. A major advantage of a good framework is that it does force you to stick to it's conventions which typically follow best practices.
As for the barrier of entry I found that learning a framework is like learning a new programming language to a certain extent and to really take full advantage of the framework you need to know the underlying language as well. It seems the barrier of entry is actually raised by frameworks.
All of my current client projects are hourly. I typically give them an estimate so they have a ball park figure and then bill hourly and update them as the project progresses. This seems to work out really well.
The only downside that I see so far is that as you get better as what you do you tend to get quicker as well, which in an hourly arrangement means you make less. You can always raise your rates as your experience grows but for previous clients it can be hard to explain.
Sure it does, but if you're working hourly, you're still making the same total $, working the same hours, just over more projects.
For me, while I do love coding, my side projects truly are a means to an end ($$ to put in a home theater, or take a trip, or do whatever else I want to do).
Hidden in your question is the kernel of why fixed-bid is better when your skills (in terms of lower hours-expended for a finished-system) are better than your competition, and you can sell it.
Now, all that said, I'm wrapping up a fixed-bid (~$25K) side project where scope creep is killing me on my (effective) hourly rate. It's still fun; I'm learning a lot about things I don't do in my "day job" and I'm almost certainly going to get more work from this client if I want it, but I made the mistake of bidding fixed-price with some assumptions about the scope that were ludicrously off. (My fault, not the client's, and I'm eating it. If the work weren't fun, it would be an extremely bitter taste...)
I'm still in favor of the fixed-bid (as it makes the sales job much easier), but watch scope creep.
One last important point: if you are bidding fixed because you are a great coder and a poor salesman, your lack of sales/negotiation skills may be an issue when the client thinks something was in scope and you think it's out of scope. If this is a possibility, figure out your strategy ahead of time, or you'll end up doing the feature "for free".
It's crazy how many of this type of post are showing up everywhere. In the past couple weeks I've seen 4-5 posts on what founders did wrong or right with their companies.
It must be nice to be past all that and looking back on it to glean the lessons. Can't wait to get there.
Yes. Having "front lines" advice and anecdotes from actually building a startup are helpful even if they are only tidbits (i.e. cliff notes) of information.
It's probably the aftermath of the 05-07 startup boom and the weak economy. Startups are failing now, but since many of them didn't take VC, all we get are lots of postmortems. Also, solo entrepreneurs have fewer toes to step on and don't need to worry so much about airing their company's dirty laundry.
There was a similar boom in printed books after 2001 - anyone ever go to their library's business history section and read all the stories about dot-bomb flameouts? Now that just shows up on the web.
There have been a lot of posts about failed startups. This is about a successful startup and the problems it survived. Doing a diff between this and the other posts might prove useful.
One thing I notice is the failure stories always include problems with their toolset. This could-have-failed-but-didn't story does not. I think the "programming languages don't matter" crowd should pay attention.
This is probably selection bias. Everybody has problems with their tools, because all non-custom-made tools are compromises to fill the needs of multiple users. When you fail, there's always something where you can say "I wish we hadn't used this tool and had tried something better." While if you succeed, the tool headaches kinda fade into the background and just don't seem that important.
When I wrote up my postmortem (http://diffle-history.blogspot.com/), I wished I'd prototyped things out more. This was intended as a general statement about process and not an indictment of any particular toolset (though I still wouldn't use JSF for any Web2.0 site ;-)). I think tools matter, but doing your homework matters more, and the best tool usually depends on the job.
I noticed that a lot of this guy's points seemed to concern doing your homework up front and not feeling time-pressured to act immediately. That's something I noticed a lot in my startup: you always know far less than you think at the start, and it's worthwhile to validate your starting assumptions before you go off the deep end on them.
Yikes! "Work hard, play hard..", there has to be a company that can do better than that cliche. Other than that, it sounds like a cool company to work for, as far as start-ups go.
Yikes! "Work hard, play hard..", there has to be a company that can do better than that cliche.
I agree its got a lot of mileage but gets the point across and is a common catch phrase. Still significantly better than cliches such as "looking for rockstar..."
