"Eventually we came to the conclusion that we should stick with what we’re good at: web apps. We know the technologies well, we have a great development environment and workflow, we can control the release cycle, and everyone at 37signals can do the work. It’s what we already do, just on a smaller screen. We all loved our smaller screens so we were eager to dive in. Plus, since WebKit-based browsers were making their way to the webOS and Blackberry platforms too, our single web-app would eventually run on just about every popular smartphone platform.", Jason Fried, <a href="http://37signals.com/svn/posts/2761-launch-basecamp-mobile" rel="nofollow">http://37signals.com/svn/posts/2761-launch-basecamp-mobile</a><p>So, should we expect 37signals to ditch "bootstrapping" over VC-funded startups soon?<p>Let me be clear, I'm not out to troll 37signals. But here's the thing, if you claim a superior ideology, sell that ideology on paperback and then go against your own methodology, you're going to get some feedback. You can't claim that everyone is a troll, or a "cesspool" whenever people confront these ideas - especially when you're selling them for $.
Looks good. Shame there is no mention of Android at all.<p>The biggest thing I took away from this blog post was this.<p>"NOTE: Basecamp for iPhone requires an account on the new Basecamp (released March 2012). Basecamp Classic is not supported."<p>I wonder what % of users haven't switched over even after a year. I think this is a good lesson for anyone thinking about effectively launching a new product to replace one they already have.<p>The company I work for did a similar thing about 15 months ago. We still have about 10% of clients on the old system. We offered free upgrades to get everyone over but some didn't want it. New platform has now diverged sufficiently away from the old one that there is no direct upgrade path any more. This has effectively left 10% of clients stranded.<p>Looking back I think any replacement product needs to be 100% compatible and after x months clients are forced over. It causes some short term hassle and support costs but in the medium term really simplifies development work if old products are completely retired.
Seems a bit funny since just last September they blogged their mobile version and "no app required."<p><a href="https://basecamp.com/1679267/announcements/10" rel="nofollow">https://basecamp.com/1679267/announcements/10</a><p>One of the reasons I recall this is that I saved this particular e-mail newsletter at the time. I thought it of particular interest they dedicated resources on making a mobile browser performant version and had eschewed a mobile application approach. So what has changed or did they feel a deficiency in that version?
Interesting that it's launched within seven days of <a href="http://getcampapp.com/.." rel="nofollow">http://getcampapp.com/..</a>. There was even an item about it this 'morning' on HN.
I wish they just put more effort into making their web interfaces more responsive. Trying to use Campfire from the browser on my Galaxy Nexus is nearly impossible.
I downloaded the iPhone app and tried it out. I'm actually quite impressed. The interactions are quite speedy and the app has a "native" feel to it. It also helps that the design of the app is quite nicely done.<p>I've been a big proponent of full native apps on mobile when possible. But this has got me thinking that the hybrid approach can be a smart move when done right.
From a friend I saw logging in, it seemed like the oauth webview screen (that 3rd party apps use to interact with the API) has been ditched for something native as well. Something 3rd party apps can never re-create.
So if they're using Rubymotion for their iOS hybrid app, I wonder if they'll use <a href="http://ruboto.org" rel="nofollow">http://ruboto.org</a> for their Android hybrid app?