I'm a big fan of Meteor. As a front-end dev that got his start in JavaScript with jQuery, it's been really easy to settle into. I did a pre-release of a Meteor app into production today (https://properapp.com) and it's running pretty well.
I'm surprised that you're using Meteor for what would seem to be a single-user use-case. Meteor's strength seems to be multi-user real-time apps, but this looks more like a job for Angular/Ember plus an API backend.
I was looking toward Meteor for a similar project because of its handy client-server syncing capability, but decided not to use it because it didn't seem to suit the more traditional webpage model and the click-to-save-changes paradigm. But your site is making me reconsider this. I've been learning and implementing my site in Angular/Restangular, which involves me writing code to POST to/GET from my Rails backend. I'm aiming to let users add and remove nodes in a plan/document and rearrange their ordering - would that be easier to do in Meteor? I'd love to make use of Meteor's object syncing and other features. What's your experience been like? Did you try Angular or other JS MV* frameworks?
By the way, I love your site's design and iconography. If you built the whole service alone, I'd be very impressed.
Re: the choice for Meteor, this was somewhat of a fluke. I'm not a traditional developer, and only dabbled with Rails and the like on an anecdotal basis. My past experience with things like jQuery made it easy to pick up Meteor and its basic concepts, so I just started building the app above (it's something I really wanted/needed and I didn't want to waste a lot of time inner-bickering about what tech to build it with).
I guess for your idea I'd have to see a sketch, but on the surface, yes, I'd say something like that would be pretty easy. The cool thing about Meteor is that it takes a lot of the thinking/logic out of the loop. So for example, you would have the nodes as a Mongo collection and for each plan/doc, just store their position info. Meteor/Mongo update automatically, so if say you used something like jQuery UI drag/drop, you would just have it update the given object in Mongo when you pick it up or put it down. Make sense?
My overall experience has been that I haven't gotten frustrated with Meteor like I did with other frameworks. It's not as rigid, sure, but if you take the time to develop a good design practice, it can be really efficient. Plus, having both front and backend code in JS is a serious time saver.
Thanks for the complements on design. Save for the octopus, logo, and animated gifs outlining the process (oh, and the nice header on the blog), this was a 100% solo effort.
It's cool how it does the multi-user realtime stuff, but if you think about it, that's solving problems that almost every networked application deals with (latency, consistency, etc) but in more subtle ways. I'd say really its strength is just how amazingly simple and easy it is to get something going.
It's been a year since I played with it, but at least at the time the weak side seemed to be integrating with any existing systems you may have, whether front or back or middle or sideways. In those cases the magic doesn't work for you and you've got to figure out how to plumb it. (Again this may have improved in the past year.)
I would sign up, but I really want to see a service before giving over my information. Screenshots, video, really anything. I dug around a bit hoping that you might have some screenshots in the KB or blog, but no luck.
Working on this. I released the app to my mailing list a bit ahead of the public (just wanted to get it out the door). Going to add in a tour of the service and some demo videos this week. Email me your info (email address/twitter) and I'll shoot you an update when there's more available: ryan@properapp.com.
Actually, I take it back. I do have something you can look at.
Here's a video I sent out last week going over the signature process: http://vimeo.com/75510644 (a bit out of date, though, as it's missing the audit trail and permanent agreement features).
Off topic, but if you're in pre-release, how do you have enough metrics to say "most developers" pick the Coffee Shop plan or is it just marketing fluff?
I really like the color scheme and if I wasn't in a "boring" contract I'd be looking directly into your services.
Combination of marketing fluff and early feedback. It's by no means scientific. Just anecdotal "yeah, I'd pick the middle plan," or "the mid-level price seems right." Something I plan to update as I get more data, but felt like a good starting point (also the plan I have myself on).
Thanks for the response! I was kind of wondering if you'd had a lot of pre-release devs or not, I'm always curious at what point people release.
I'm on what I'll call a floater business operations contract. It's an ongoing thing at 40 hours a week (at a great company) working on several different projects and providing assistance where needed. As far as stack, it's mainly a Microsoft establishment with other things sprinkled in (and getting more so with newer projects).
The latest dev shop outlines what's in store for the 1.0 release (http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devsh...) and based on where they're at now, it's exciting to think of what will be possible.
Definitely not a toy, though, and something that should be evaluated carefully.