This is a ridiculous statement. The report is about one month's statistics of a single ad network, from which you can reliable extrapolate, well, nothing.
Besides, the stat in question concerns network ad revenue only, not app sales revenue.
Spreedly Core is a simple API-based product for processing payments and is PCI compliant via transparent redirects (like Braintree). If all you're doing is processing one-time charges, it might be a good option to consider.
Basically, your payment form posts to SpreedlyCore, which posts back to your server with a token. Your app can then perform the basic payment actions, including validation of the user's posted payment data (minus the sensitive info, of course).
The service supports several gateways, and you never see the customer's payment details. The API simplifies dealing with responses. The biggest pain is that it's XML-based.
Regardless, I got it up and working in about a day, and I am slow. :)
It's very easy to use, and though new, the team is very responsive, and the API follows most conventions of their Spreedly subscription service, which is more mature.
The only thing you need to bring is an SSL cert, but you were gonna do that anyway. :)
Wow, crazy to see these pics. My dad worked at the SSC, managing the magnet manufacturing facility. I remember touring some of these buildings, and seeing some of the magnets. I still have a SSC mug at home. :)
In the end, I think it may just have been too much of an oxymoron to pair the words "Waxahachie, TX" and "world-class research facility", it's just not something most of America was ready to embrace.
It's too bad though, we really lost a great opportunity to build something great in the middle of Texas. It would have changed everything there, that's for sure.
I can't recommend Compass/Sass highly enough. A CSS pre-processor will completely free you to organize your CSS however you want, and more importantly, it lets you build up a library of common components (forms, buttons, etc.) that you can easily reuse and adapt for new projects.
Generally, these library files will simply contain mixins (reusable chunks of code), so they don't output anything directly into your CSS, but allow you to include the mixins in certain styles. Very useful for adding effects, rounded corners, etc. on different elements.
Keep in mind however, that mixins can be overused, adding bloat to your code. CSS does cascade, after all. You should always look to see if you can separate reusable css rules to include in markup (commonly seen with grid systems). How you balance out the convenience of keeping your css flexible vs. not littering your markup with lots of styles really depends on the project, but it's something to think about.
I have developed one very useful trick while using Sass for managing colors. Instead of assigning colors directly to an element (very hard to track down later if a change is necessary), I create color variables named after the element and attribute in question. Then in my colors.scss file, I build up my color palette, and after, list all the color variables I created in my stylesheets, setting their values to the appropriate color from the palette (with tweaks, if necessary).
// in colors.scss ---
// color palette
$red: #ff0000;
// assign colors to elements
$body-background-color: $red;
// in layout.css, for example ---
body {
background-color: $body-background-color;
}
Since Sass lends itself to lots of files, keeping all my colors and the elements they are assigned to together in one file makes them much easier to manage down the road.
I do this, but with a slight tweak: instead of naming the colors things like $red, I try to give them semantic names like $shadow, $highlight, etc. in case I end up having to pick a completely different color scheme.
Do both. If you pick a completely different color scheme, it's easier to change $highlight = $red to $highlight = $blue than to remember the hex values.
I agree with acrum, a niche would probably serve you best. You have a lot of features, but the benefits aren't crystal clear. Solve a real problem, which I'm sure you have insight into, and you'll be on your way.
Having more features is actually a big problem, since it dilutes your core value, and creates customer confusion, as most will have differing ideas about what's "core".
As a parent, I think this is a great idea. I have trouble sharing photos with family members, not all who are on Facebook (my default sharing method). Plus Facebook's privacy settings are confusing, and their business model runs against keeping my photos private, which is somewhat unsettling.
FYI, Ash Maurya built CloudFire to solve this problem, but since he's moved on to being a "lean startup" guy, the product seems to have been abandoned. There are probably valuable lessons in the history of that product.
Finally, I have to admit I'm getting tired of the landing page gambit. Maybe it's just early-adopter-itis, but if I'm interested in your product, I want to touch it, play with it, right now.
A landing page doesn't solve my problem. And there are so many "landing page" products in existence now, that I question whether the strategy is beginning to turn people off.
Having to wait for a product that on average never actually ships is annoying. Don't bother me until you have something to show. YMMV. :)
We built Receivd to solve the exact problem you are describing.
The landing page allows us to gather numbers on how many folks are actually interested. We're planning to send out builds early next week to the first round of early-access users :)
Getting paid up front is key for dealing with micro-businesses, so that's good. But I have a hard time believing that "crafty" and "high volume" mesh on any level.
Crafty businesses are homespun, bespoke businesses that rely on charm and a personal touch. Group buying single-handedly destroys that. Crafters are also very protective of their personal brands and would be very averse to doing anything that might lead to angry/disappointed customers.
So, I don't see this taking off. Have you talked to any crafters about this? Can you allay these types of concerns? And what types of handmade products lend themselves to being made in short timelines and high volumes?
Help me understand your definition of "high volume". Based on the conversations we've had with crafters (admittedly, few and people we know at this point) we're talking volume on the scale of 10-20 items. Not 100's or even 1000's.
We will be talking with more crafters before solidifying the model.
Further backing this is the ability that Etsy and other craft selling sites give to their users for indicating a quantity.
As for products, it absolutely depends on the crafter. Items made with a pattern will work great. Knitted items, quilted items, wooden crafts, metal crafts, etc are all good. Even photography. It ultimately boils down to the crafter being able to reproduce an item with consistent quality.
I love Haml/Sass/Compass for HTML and CSS. It is tightly integrated with Rails and saves much time. (I never want to write HTML tags again!)
I disagree on the use of presentational/semantic styles, however. These are not that useful once your design is stable, but the beauty of Sass is that you can use them early, then move your grids into specific selectors later for cleaner, better organized code. You can do both!
Compass is awesome for color palettes, too. It includes several cool functions for adjusting colors.
JavaScript is a completely different story. You should really dig into books, etc., and build a solid understanding of how JS works before adopting any library like jQuery. It will save you a lot of hassle building and maintaining your code. D. Crockford's JavaScript: The Good Parts is a common recommendation. jQuery Fundamentals is a free HTML book that provides a good start if your going the jQuery direction.
Awesome, I hope Linkedin's rise creates the opportunity for a nextgen upstart to emerge. There's a lot to improve on Linkedin's model (admittedly a very good one). Get to work!
I'm not who you were asking, but snappier performance.
And reward people for good use of the site. Share your contact list with your contacts? You get some free InMail credits. Complete profile? Some more. etc.
Mission statements are usually all corporate-speak and written in passive voice. They are generally pretty useless.
Expressing the mission you're on is more expressive and active. It's also easier for customers to get behind, and for the company to internalize.