What I found does move the needle are: 1) Changing how much I charge, including adding upsells, and 2) Getting new sources of traffic.
241 karma · joined December 31, 2011
What I found does move the needle are: 1) Changing how much I charge, including adding upsells, and 2) Getting new sources of traffic.
Namely, it's always way more work than you expect, especially when you have legacy customers with prior expectations.
And results hardly ever budge.
My hypothesis is A/B testing can move the needle for light engagement, like "try a free trial". But pulling out a credit card requires a lot of motivation, and the 0.1% of your visitors that have this motivation are relatively unaffected by your design.
I would pay > $4 per year if it meant I controlled my Facebook data (i.e., I was the customer, not the product).
If you sell something for money, there's a single moment where your interests diverge from your customers -- when you accept payment. But the rest of you customer interactions are all about adding value.
Anyone interested in helping out, please message me (josh at tristara dot com).
In other words, AT&T redistributes a portion of their subscription revenue to app makers based on the bandwidth they get people to use.
Then, app makers would have a direct financial incentive to drive usage, without all the hassles of explicit billing.
In other words (unless I ask for and maintain separate user tables), all the login credentials stay with Facebook. And if they ever decide to stop supporting my site, I lose all my users.
I'd be willing to pay for a FB Connect like service if I trusted it (which would probably mean the ability to download login info on anyone who connected, so I could roll my own user management whenever I wanted).
I wish there were an open source project that unified best practices (in various tech stacks).
You may be able to use the Google Hangout API.
It's crossing the uncanny valley of human facial expressions, so they look natural rather than creepy.
Flash just works for much better. There are no cross-browser issues (except those that don't support it at all -- thanks, Apple). And ActionScript is a better language for building complex apps than JavaScript.
The concept that the "non programmers" could never understand was the abstraction of functions. Like:
foo(a) { // stuff }
foo(b);
would confuse them because they'd get hung up on foo's parameter declared as 'a', but called with 'b'.
As an "army of one" you can be almost as fast as a small team, and you can execute with much higher conceptual coherence. I.e., you can aim better.
It is important to filter out ideas you're not interested in running, even if they could make money.
And once you start getting traction, it's important to focus hard on exploiting it.
Making $1000 per month is harder than scaling that to $100,000 per month (if the market size is large enough).
How you approach a 1000 line project is different from a 100,000 line project.
The best practices for a good solo developer are different from a team developer.
And most importantly, the internal elegance of your code is independent from how useful / cool your product is.
I think what killed me was the micro instance only has ~617 megs of ram. The medium instance is holding up fine.
Lesson learned: don't send HN to an EC2 micro instance. I upgraded to a medium instance, let's see how it works...
What worked for me is I just hacked on fun personal projects. Like "hmm, that's a new API, let's try it out". I did it for fun, not to achieve a larger goal.
And gradually ideas would pop up, like "now that works, I wonder what if I also combined it with this..." and after a few months larger ideas started coalescing.
Given that you've had some success, you probably should look for something that resonates more strongly as "you're passionate about it" vs. "it can make money".
And once you have an idea that could develop into a real product, all your experience starting a company becomes highly valuable. Don't just be a code monkey for someone else :)