I would have bought this right now if it existed for mac/iTunes. I'm a music student when I'm not an entrepreneur. Sounds like a good idea just poor market selection.
Sometimes Hardware is Expensive, and so is time though.
I think often times in a startup, especially one thats bootstrapped, its easy to get caught up in trying to optimize everything too early on to scale for a million users before you have your first thousand. Sometimes you have to optimize for your development time first and product development goals, and leave the optimization till you get a bit of runway.
> Sometimes you have to optimize for your development time first and product
> development goals, and leave the optimization till you get a bit of runway.
That's a typical way to postpone and fall into a trap. Not all optimizations take huge amounts of time. And certainly there are some architectural decisions you can take early on that can save you a lot of wasted time later. The most common is to prevent bottlenecks.
For example, it's not necessary to make a clustered DB from launch day but coding and managing the UI and middle-ware to be ready for a switch to clustered DB usually takes very little impact. If you don't do this and the site becomes successful, re-engineering your whole site to support a new DB is usually close to impossible or extremely expensive. The site ends up in the DB hardware feedback trap just like in the article.
Architectural decisions also limit what you can do later. Generally, the more focussed/optimized a system the less flexible. To the extent you KNOW exactly what the system should do, it should be optimized from the beginning; but, as PG points out repeatedly, most startups change direction at least once after launch.
"Had the app been as efficient three years ago as it is today, I'm estimating that about half of what was spent on hardware and related licensing and support costs would not have been necessary."
So first off the software costs where far higher than the HW costs. Second, possible savings of 750k would have come at the cost of features or development time both of which have costs. If anything this just points out how expensive using Microsoft solutions can be when you need to scale. But, even still I expect over 3 years the 750k "lost" is an insignificant cost vs the cost of development and roll out.
PS: Reading between the lines the HW costs where probably well under 150k. "up to 30% of 32 database cores all by themselves."
At the time, IBM, Unisys and Bull were about the only vendors with SQL 2000 capable servers with > 8 CPU's. (And Itanium, of course.)
The customer purchased IBM x460's, 16 CPU's, 64GB RAM = $225k each in 2005, right after they came out. Three required (active, passive in a cluster at the production site and one for the DR hot site). Upgrade them to dual core x3950's six months later = another 200K (or so, the upgrade was to 16 dual cores, 128BG RAM for each of the three database servers ). Plus all the odd's and ends, like 60 amp 3 phase power, 70,000 btu's of cooling, etc.
The software/licensing/support costs were because with > 8 sockets, you needed Microsoft Data Center Edition, and at that time, it came with an expensive support contract ($70k/yr).
Had the vendor been about 6 or 12 months ahead on their optimization, the 16 CPU x460's could have been 8 dual cores instead, and the 32 core upgrade probably wouldn't have been needed - or if it was, it could have been delayed until quad cores were available, the expensive OS support would not have been needed, half as many Microsoft SQL Enterprise CPU licenses would have been needed, and the 24x7 hardware maint contracts would have been half as much, etc.
It’s stunning how much people can overpay on just about anything.
However, even if every cent of that was "needed" we are still only talking about ((3 *225 + 200) /2 ) ~= 440k in HW which is ~1/3 of the stated number and probably a small percentage of the budget over those 3 years + dev time.
PS: I know they would have saved a lot of money by using 8 CPU machines, but that's part of my point. Scaling the DB system has little to do with the app code and it shows just another way the project was miss managed.
One thing regardless of your apps utility. The logo on the top has color profile information in it and thus does not display correctly on mac computers with safari meaning it does not match the background.
Speaking of the logo, that little bird looks a lot like the [Twitterrific icon][1]. Especially in [sm12.jpg][2]. Do you have permission to use that icon?
I think one of the best ways to break the barriers software developers/entrepreneurs face in understanding industries outside of the normal niches is to sit down with people in the industry and have a therapy session of sorts. Don't sell anything, but instead listen and learn carefully to what their concerns and problems are.
People in industrial fishing may not think that they have a need for new software, but there are undoubtedly needs and issues within the fishing industry that are completely opaque to those outside of it. And where there are pain points there are opportunities to innovate.
For me, in my limited experience in the area I would have to say that it is completely dependent on the quality of the people and the level of autonomy their job responsibilities can afford.
I feel there is a lot of value in a controlled launch, it takes a lot of effort and coordination (in most cases) to pull one off successfully. However, I think there is no good reason to keep your work completely in stealth, you want to be building up reputation and networking in your respective industry and you can't do that effectively with a tin foil hat on.
