I often find that constraints, real or artificial, can be a huge motivation and productivity boost when I find myself stalled on a project or piece of work. Forcing yourself to work within a specific limitation can cause you to find a creative solution in a direction you might otherwise never consider.
In my own work, I find time constraints the most useful. When I don’t know where to start developing or writing, I’ll often force myself to do something – no matter how small or tangential – to move the work along for thirty minutes or an hour. The artificial time limit frees my mind to attempt starting points I might not typically choose because I know that even in a worst case scenario, I’ll only lose an hour worth of work if my chosen path is unsuccessful. Similarly, when I find myself lacking motivation and energy to work, I’ll use the pomodoro technique. That gives me the kick in the pants I need to break the ice and get moving, which can often turn into real energy and sometimes even that magical “flow” state.
A few weeks ago on a Friday night I found myself burnt out from my day job. It had been weeks since I had done any recreational programming or development on my side projects. I desperately wanted to move them forward, but simply couldn’t find the energy.
So I tried an experiment.
I decided to give myself thirty minutes to brainstorm and come up with a product idea that I could then build to a shippable state within the next two hours. Further constraining myself, I decided to forgo my two 27″ monitors and do everything exclusively on my 11″ MacBook Air.
I knew the easiest way to come up with a new product idea was to examine my typical day and find a small pain point that I could solve with software. After mentally going through my usual day in my head, I began to focus on my calendar. I realized that I was often checking multiple times throughout the day to see how much time I had until my next appointment, which would influence which task I could take on before I have to be somewhere. (As many developers will know, a programming assignment that will take an hour, often takes longer as there’s a definite lead-up time before you really begin coding where you work to get yourself into the zone.)
I thought “Wouldn’t it be easier if I could just glance up and see how much time I had remaining?”
With that insight, I had my product idea.
Over the next ninety minutes I built a simple Mac menubar app that looks at your calendar and simply displays how long you have until your next appointment. I call it Up Next. I’ve been using it as part of my daily routine for the last few weeks and have found it works great. Without losing place in my current work, I can glance at my menu bar and see “Oh, I’ve got two hours until I need to be somewhere” or “Crap, I’ve only got twenty minutes to wrap this up”.
That little bit of awareness doesn’t distract me from getting in the flow, yet keeps me persistently time boxed and motivated.
If you find yourself similarly lacking motivation throughout the day, I encourage you to try placing a constraint on your work. And if you think Up Next might be useful to you, you can give the app a try.
I want to give a big thumbs up and a hug to everything in this fabulous post by Paul Kim. I missed it back in August when this discussion was initially happening but came across it on Gus’s blog this morning. Paul writes about his expectations starting out with Hazel and what he’s discovered looking back on his success. This portion specifically speaks to my (moderate) success and what I’ve learned:
But it wasn’t easy and it wasn’t overnight. A common sentiment I see among a lot of new devs is that if they aren’t living full-time off their app in the first year, it’s a failure. I know when starting out there is the hope that your app will be an immediate success. It’s fine to hope that; after all, its our dreams that drive us to succeed. But you shouldn’t expect it. I would say it took about three years before I could be comfortable living off of it full-time.
That’s exactly one of the points I was trying to make when I wrote about my own journey. My initial expectations for VirtualHostX were very tempered – I just wanted to earn enough money over the lifetime of the app to install hardwood floors in our tiny house. But, as the app and my audience grew, I would occasionally readjust my expectations – eventually to the point where I could financially sustain myself by my app revenue alone.
If you release your 1.0 with awareness that you may not succeed until 5.0, you’re in good shape.
Paul’s other point about luck is also worth keeping in mind:
One thing that I did learn is to have a healthy respect for randomness. Luck plays a huge role and you can’t always attribute one’s success or failure solely on their decisions and actions….That doesn’t mean you sit back and just let fate decide; you still need to work to improve your chances. Just realize that there’s a big chunk you can’t control and that on some level, you need to be ok with that.
While I’ve poured a lot of time, energy, and work into my apps, I’m very much aware that a lot of their success is just dumb luck. Case in point: I was extremely fortunate that of all the apps I could have built, I happened to pick a niche market without any serious competitors. Not only did that make me the only game in town, but it also allowed me time to breathe and let my app grow organically to meet my ever growing list feature requests from my customers. Sure, picking a niche in an underserved market is business school 101, but for the dumb twenty-four year-old that I was, that was a supremely lucky break.
In any case, if you have any interest in a successful indie journey, give Paul’s post a read.
Gus has a terrific post on his blog about what he calls “the wilderness” – a period of time between major software releases “where I’m pretty lost, and I don’t know what to do.” His working theory on the matter is that it’s basically a forced period of rest put upon you by an overworked brain. How do you get past it? The same way you walk out of any wilderness – “One foot in front of the other…You can walk for miles and maybe months in the wilderness. Just keep on going.”
I take comfort in knowing that I’m not the only one who experiences periods of low energy slogging through work like this. Unlike Gus, however, I don’t blame it on a stressed or over tired mind. For me, as someone who suffers from depression, I know that these periods aren’t just a symptom of working too hard, but that they’re actually just one part of a cycle between times of depression and times of whatever the opposite of depression happens to be.
I’ve been tracking my mental health through copious notes and journaling for three years as a way to better understand what triggers my depression, how long it lasts, and what I can do to work my way out of it. The biggest lesson I’ve learned is that these periods always have an end. They’ll pass. If you have faith that that’s true, then it becomes easier to listen to your mind and not try and force things when the timing and mood isn’t right. In the same way that I take advantage of my mentally high states and code like a crazy person, I know to divert my focus to other more doable tasks when I’m at a low point. Rather than coding, I’ll update my FAQ articles, record screencasts, or do a deep dive into my marketing analytics safe with the knowledge that I’ll come through to the other side and return to coding in a better state of mind.
Gus equates escaping these periods with putting one foot in front of the other and continuing to walk until you find your way out. For me, I see it more as riding waves on a boat. There’s going to be low points just as there are high ones. The key is to keep sailing.
For years I’ve used on-hold “waiting” contexts named after coworkers and family members to denote tasks that I’ve assigned to other people and am waiting on them to finish. But a few weeks ago I had a realization that there are two other types of relationships between tasks and people that I haven’t been tracking. And with a few quick modifications to how I title my tasks, it’s possible to track them in OmniFocus.
Let me explain.
There are three types of relationships between tasks and people:
A task can be assigned to another person by you.
A task can be assigned to both you and another person.
A task can be assigned to you by another person.
Number one, tasks assigned to another person, can be handled as mentioned above by giving the task a context corresponding to the name of the person it’s assigned to. So, if I’m waiting on Jeff to complete a design document, I’d give that task an on-hold context of “Jeff”. This lets me quickly filter tasks that Jeff owes me whenever I run into him. Great. I’ve been doing this for years.
But it would also be super useful to track tasks that are shared between you and someone else. How can you do this with OmniFocus?
The best solution I’ve found is to add the other person’s initials to the task title surrounded by parentheses. For example, a task that I’m working on with Mike Davis would be titled “Review design specs (MD)”. Then, much like focusing on a context assigned to a person, it’s easy to view all of the tasks you’re doing with someone else. Just perform a search for their initials inside the parentheses like “(MD)”. You can even perform a search and save it as a custom perspective for people you frequently need to review. And don’t forget the parentheses – they’re important. It prevents your search from finding task titles with words that contain the initials you typed.
Taking the initials trick a step further, I add initials inside square brackets for tasks that I owe someone else. For example, instead of creating a task titled “Complete TPS report for Jack Posey”, I title it “Complete TPS report [JP]”. Again, this lets me perform a search for anything I owe Jack.
You could go even further and use additional sentinel characters to define other relationships between tasks and people. For example, you could use curly braces { } or angle brackets < >. I don’t use those myself, but it’s nice knowing they’re available if there’s another relationship type you frequently need to assign.
I’ve always gone with portability and sleekness over outright power and versatility. I bought an 11″ MacBook Air the day they came out. I switched to an iPad Mini from the bulky third generation iPad. I walk around with a slim wallet. I keep my iPhone naked in my pocket – no case.
So I was hesitant but very curious about the iPhone 6 Plus. I’ve always scoffed at Android users with huge phones – mainly because I never saw the benefit. Very few Android apps adapt themselves to take advantage of the extra screen real estate. Most users spend all day with stretched and scaled up apps that could just as easily run on a smaller screen device. But with Apple’s recent advancements in AutoLayout, size classes, and their keynote demo, I love the idea of the additional UI elements a larger screen iPhone could provide.
That said, it goes against my very nature not to get the most portable device I can afford.
But after spending a day with a Samsung Note III in my pocket as a size comparison, I came to a realization I hope comes true.
The 6 Plus may be a huge phone, but it might just allow me to give up my iPad (which I don’t use very often) and consolidate down to only one iDevice.
In that sense, going with the Plus actually is the smaller option.
I’m probably not going to say anything new. But I wanted to put down on paper my system for staying on top of email since I so often see people with overflowing inboxes. And I’m not trying to specifically call out anyone I’ve worked with in the past with an unmanaged inbox. I’ve known plenty of very productive people who can’t stay on top of their email. This is just my solution for taming the crazy.
Every morning when I wake up, I typically have 20 – 30 new emails across my three inboxes. (Personal, Freelance, and Work.) Usually, while standing in the kitchen drinking coffee, I’ll open my iPhone email client of choice (Dispatch – it’s truly amazing) and switch to the combined “All Inboxes” view. Then…
I read the subject of every email. If I don’t know what the email is from the subject, I’ll tap and read the body.
Every email is read. Without fail. Nothing is skipped.
For every email, before I move on to the next one, I do one of four things with it:
Delete it
Send it to spam
Archive it
Leave it in my inbox in an unread state
Those first three actions should be mostly self-explanatory.
If it’s trash, I delete it.
If it’s unwanted, I mark it as spam. I know some people will just delete spam emails, but that does yourself a disservice. At least with Gmail, by marking a message as spam, Gmail will learn to mark future similar emails automatically as spam – leaving you with one less email to triage.
If it’s a legitimate email that does not require a reply, I archive it. Gmail has blessed us with practically infinite email storage. You never know when you might need to refer to an old email, not matter how mundane, and it’s absolutely no bother to archive an email just in case you may one day need it.
With those three options out of the way, that only leaves emails in your inbox that require a response or an action on your part. If an email requires an action, I send it to OmniFocus and then (you guessed it) archive the email.
If the message requires a reply, I leave it in my inbox until later in the day when I have time to reply. And immediately after reply, I archive it.
Throughout the day I’ll get new email. I feel no need to check it immediately. When the time is right, I repeat the above process on any new emails.
And during the day when I have time to reply to email, I know every message left in my inbox needs a reply without having to reassess them or make any decisions. Just open an email, reply, and archive.
I follow this routine ruthlessly. The result is a completely manageable and under-control email experience. No emails ever get lost in the shuffle or forgotten. Everyone who needs a reply from me, will get one. And any email that requires an action will be acknowledged.
When I started selling my first Mac app in 2007, there was no App Store. I don’t even think “app” was a word. And there certainly wasn’t any ready-made infrastructure for selling software online that you could simply plug into. That meant, like every other independent developer, I had to piece together my own solution for accepting payments, hosting downloads, activating license codes, and delivering app updates.
August 2014 was the seventh anniversary of my first product release, so I thought I’d take some time and describe what my current setup looks like and all the tools and services I’m using to keep my business humming along.
Shine – My Indie Control Panel
Shine still powers the core of my business. It’s the controller that connects all of my other web services together. You can read a more detailed description of the software here. But, in general, here’s a list of all the functions it handles…
Order processing
Validating upgrade eligibility
Manual order creation
Order history and lookup
Generating invoices and receipts
Generating coupons
Basic sales and business stats and charts
Generating serial numbers
Software activations
Collecting and storing user submitted feedback and support requests
Searching for, displaying, and archiving mentions of my company and products on social media
Coordinating new app version releases, which means accepting a zip file of the app, storing it in Amazon S3, and pushing the new update to users via Sparkle
Generating publicly viewable changelogs
Sending transactional emails
and many other little, but essential, tasks
I literally couldn’t run my business without Shine. Well, I couldn’t in 2007. Services like GumRoad, FastSpring, and Stripe could handle for me much of what Shine does. But I’m so invested in the software it’s hard to move on at this point. Also, I love the ability to control the code which means I can dictate features and business logic exactly as I see fit.
Payment Processing
I originally used PayPal to accept accept orders. Their IPN API would ping Shine whenever a new order came through, and Shine would generate a license code and email the customer. In 2009 I switched to FastSpring. You can read about my experience making the change from PayPal to FastSpring. tl;dr FastSpring is way better. They take over as the seller of record and handle all aspects of order processing. When an order comes through, FastSpring sends the order information to Shine for safe-keeping, and Shine returns a license code. FastSpring also handles emailing the customer a receipt and their license information. They’re also where I go whenever I need to process a refund. Twice monthly they deposit my sales into my bank account minus their commission.
For six months in 2013 I switched away from FastSpring and handled the entire order flow in-house on my website using Stripe. I really liked owning the entire solution – and especially liked Stripe’s much, much lower transaction fees. It also enabled me to use Stripe’s Objective-C API to build a store directly into my apps, so customers could enter their payment information without ever have to open a web page. Unfortunately, I saw a decrease in conversions. I also wasn’t able to calculate VAT and sales tax on my own, so I switched back to FastSpring.
For the last month I switched over to using Drip for sending out my VirtualHostX welcome emails, and they were great. But better analytics, better email template designs, and higher conversion rates led me back to MailChimp.
Sending Transactional Emails
MailChimp is great for sending email blasts, but for transactional emails I use Postmark. Their pricing is affordable and their API is super simple to work with. Whenever an order comes through to Shine, I use Postmark to send out the customer’s order receipt and license information. They do a very good job of managing their outbound email servers’ reputations, so I’ve never had any problems with the emails I send getting flagged as spam.
While I’m 100% satisfied so far with Postmark, I am looking into switching to RackSpace’s Mailgun service so I can send delayed emails. I’d like to automatically send a followup email to customers asking if they have any questions a week after purchase, but I’d prefer not to handle the queueing logic myself. Mailgun’s API has a simple, optional parameter when sending email that allows you to specify a future date when the email will be sent. That’s very appealing to me. I’ll post my results if and when I make the switch.
Web Hosting
All of my servers are hosted at Linode. That includes my primary web server, which hosts all of my domains and the Shine web app, plus the proxy servers which handle VirtualHostX‘s Lift Off service.
I originally started out on SliceHost, and then migrated to RackSpace when they acquired Slice. RackSpace was great, although very expensive compared to AWS. Still, they treated me wonderfully (including a dedicated account manager), so I stuck around. Eventually though, I had to move away after years of them never getting around to supporting two-factor authentication. I just had so much of my livelihood hosted on RackSpace, I couldn’t afford the danger of getting compromised, even using a strong password. (So, if you’re reading this RackSpace, 2FA is the primary reason I left – and, yes, I’m aware of your 2FA beta program, but that came too late.) I’m now on Linode and very happy. Their all SSD machines build my Jekyll site in two seconds, compared to the 14 it took RackSpace’s spinning disks.
Source Code Hosting
I was a very happy paying GitHub customer since 2008, but switched to GitLab in 2013. The short reason for the switch is my GitHub monthly cost ballooned to $50. So, I spun up a $20/month DigitalOcean box, installed GitLab, and now host all of the private repositories I want. You can read a detailed account of why and how I switched from GitHub to GitLab.
My Website
As I noted above, my website is hosted on a Linode instance. It used to run on WordPress, but I found it much simpler to maintain by switching to Jekyll. Another huge consideration was the speed of serving static HTML files with Jekyll versus database backed WordPress pages. Here’s a Pingdom chart showing my site’s average response time before and after switching to Jekyll.
Content Delivery Network
All of my static website files and app downloads are stored in Amazon S3. My website serves those files over MaxCDN‘s content delivery network using my S3 bucket as a pull zone. Their bandwidth runs me about $100 a year and it’s lightning fast. I could use Amazon’s CloudFront as my CDN, but I find MaxCDN’s control panel for occasionally purging the cache much simpler to use.
Phone Support
I use Grasshopper for my phone support. It costs about $20/month for my own, dedicated 1-800 number. In practice, I rarely do phone support and let most of the incoming calls go to voicemail, but I’ve heard nothing but positive comments from customers who appreciate that there really is a dedicated toll-free number they can call if needed. It makes them feel like there’s a reputable company behind my software. (There is!) Even if you never answer the phone, I highly recommend getting at least a voicemail box where customers can get in touch.
Crash Reporting
All of my Mac and iPhone apps use the HockeyApp SDK for crash reporting. I’ve found their crash symbolication service to be top-notch. Because I already have my own infrastructure setup with Shine, I don’t need a lot of their other services, but the $10/month I pay for crash reporting is completely worth it.
Email Hosting
I use Gmail for all of my company email. You can’t beat their price, search capabilities, and keyboard shortcuts. But, as a backup precaution, I’ve had all of my personal and company email forwarding into two FastMail accounts for the past few years so I can immediately switch providers if it should come to that.
Domain Names
I moved all of my domain names from GoDaddy to I Want My Name four years ago. I knew I wanted off GoDaddy, and at the time, IWMN was the only reputable registrar I could find offering .io domain names.
All of their features and support are great. My only complaint is their dashboard is sloooooow – on the order of 5-7 seconds between page reloads.
SMS Messages
My Mac app Minion has a need to send text messages to users. Twilio was my first choice and they’ve served me well. Their API was a little confusing at first, but now that I’ve got it up and running it’s been rock solid. Their pricing is on par with every other provider I’ve looked into.
Personal Assistants
I recently started using the FancyHands virtual assistant service to offload some of the more mundane tasks of running my business. I’ll have them do research, book and cancel hotels, and whatever other small tasks I don’t want to deal with myself. I’m still testing the waters, but I hope they can become an integrated part of my workflow.
So, that’s it. Off the top of my head, those are all the major services and tools I use to run my indie software business. As I’ve grown up as a business person these last seven years, I’ve learned to delegate and pay money for services that can do a job well instead of trying to handle everything in-house myself.
About six months ago I began collecting the email addresses of folks who downloaded my app, VirtualHostX. This was entirely opt-in. I simply placed a MailChimp signup form on my download page. I promised users who join a three email course introducing them to a few of the major VirtualHostX features and a 10% off coupon for when they purchased. My goal wasn’t to collect their email addresses and, later, market to them. I simply wanted a way to automatically communicate with users new to the software and make sure they got off on the right foot.
Setting this up in MailChimp was surprisingly simple. They’ve got a whole section on email automation. Kudos to them.
A couple weeks ago, however, I ran across a new marketing product called Drip. It’s founded by the author of a book I really enjoyed about solo entrepreneurship. Drip promises to handle email automation similar to MailChimp but with better goal tracking and higher conversion rates.
I was intrigued.
After going back and forth for a week, I ripped out my old MailChimp form and installed Drip’s pop-up box last night. MailChimp has served me great, but I’m ready to go beyond simply sending emails and towards measuring the actual effectiveness of them. I’m hoping Drip’s goals and conversion tracking will give me those insights.
All of this is influenced by a realization I had earlier this year. VirtualHostX has reached a mature, stable state. There are plenty of more features I can add – my todo list is overflowing – but I’m wondering if I’m starting to see diminishing returns with regards to how many more sales I make compared to how many new features I build. I’m wondering if I could see a bigger difference in sales simply by upping my marketing game. I hope to find out that answer, to a small degree, with Drip.
Anyway, I plan on writing a full review of Drip and what success it does or doesn’t bring me in a few months once I’ve had time to see its effects on my mailing list. But for now, I just wanted to offer my sincere amazement at what a well-executed service it is. As far as I know, Drip is one of the small players in the industry. And I honestly wasn’t expecting much fit and finish. But I’m seriously impressed so far. Their entire onboarding process was stellar. And the workflow that led me through setting up a campaign, building my email course, and getting their JavaScript and tracking installed on my website was phenomenal. They’ve done a really, really great job.
You would think it wouldn’t matter what sort of coffee cup you use, but after picking one up on a lark from a kitchen store and then ordering four more on Amazon, I can tell you that it absolutely does matter what you’re drinking from.
But, first, what’s wrong with a regular old coffee mug?
As it turns out, a lot of things. For starters, have you ever actually held a coffee cup after filling it with coffee? It’s almost guaranteed to burn your hand. That’s why they all have handles. But the handles are never ergonomic. At best, you can wrap two or three fingers around the handle and then you have to do that awkward balancing act where you counterbalance the weight of the coffee mug by placing your thumb on top of the handle. Making matters worse, after making coffee with my AeroPress, my hands are always wet from rinsing it out. That makes holding onto the mug a slippery proposition. And, if you lose your grip and drop the mug, it’s going to shatter.
Do any of those problems really matter on their own? No, probably not. But together they add up to me always being frustrated with my usual coffee cup.
After complaining about the problem one morning, my wife finally said “Why don’t you just get an insulated mug?” It seems like an obvious solution, but every insulated cup I’ve found was always too large – sixteen or twenty ounces. I wanted something the size of a standard coffee cup.
I finally found what I was looking for with a 12oz tumbler from Tervis. And why is it the best coffee cup I’ve ever owned?
It’s insulated. I heat the water for my coffee to boiling using a BonaVita electric kettle (another fantastic product). By the time the coffee is in my cup, it’s not quite boiling any longer, but it’s still scalding. The outside of the Tervis cup stays completely cool. I never worry about burning my hand. Also, even with wet hands, the mug is very easy to grip. There’s no silly handle. It’s just a nice, round shape that fits naturally in your hand. It’s also an appropriate size for coffee – twelve ounces. That means I can fill up with my usual ten and not worry about the coffee level being close to the lip and spilling over.
The material of the mug is extremely sturdy plastic. I’ve dropped it a couple times (once on purpose!) and it’s never shattered or chipped. Other insulated mugs I’ve tried came apart after going through the dishwasher a few times. The Tervis mug has seen four months of cleaning and has held up like a champ.
If you make your coffee with an AeroPress, you’ll be happy to know the press fits nicely on the top of the mug. Not too small, not too big. And as a bonus, the mug is clear so you can see your coffee being filtered as you press down. It’s a neat effect the first time you see it. You also always know how much coffee you’ve got left in your cup, which would have saved me a few times when I quickly picked up other coffee cups not realizing there was still liquid inside.
The only real downside is the price. I’ve never found them cheaper than $10 a mug. I think they’re completely worth it, but your mileage may vary.
So, there. Nearly six-hundred words about something as ridiculous as a coffee cup. But it really has made my morning coffee routine much better.
After publishing my Mac app financials last month, I received mostly positive comments. But a few people did share with me, over Twitter and email, their displeasure for what I wrote. They seemed to think that I was only writing to jump on Jared’s bandwagon, to grab some cheap, easy traffic, or to show off. One person even gave me the old Gruber fist-eggplant.
I completely understand why some people might think that. My post did generate a lot of traffic thanks to Hacker News – 30,000 unique visitors to be exact. And for folks who aren’t as profitable with their own apps, it may seem like showing off. (Although compared to some other indie developers I’ve spoken with, my revenue is far, far below theirs.)
So, I’d like to take this opportunity to explain why I wrote the post and what I was hoping to accomplish.
My first goal was to offer a realistic financial data point for what other developers might expect when selling their own software. Every minuscule financial detail of publicly traded companies is available online for inspection, but there’s very little data available for independent software vendors. For folks just beginning or considering starting a software business, it can be maddening not knowing what sort of success (if any) one could expect to achieve after six months, a year, or longer.
I realize my own situation may be unique. I’m primarily a Mac developer while most new businesses focus on iOS. I also have a head start as I’ve been doing this since 2007 – even before the App Store. But, as I wrote about in this post, for developers who are targeting a niche audience, I wanted to offer my situation up as a possible example of how things can play out. I wanted my story to serve as encouragement just as much as it is a warning.
Taking that rationale a step further, I’ve always felt that it would be beneficial to the indie developer community as a whole if we were more transparent about our business dealings. But first, a story.
Back in 2007, when I was first learning how to sell my software online, I created an open-source dashboard called Shine that essentially runs my business. It handles everything from orders, to Sparkle updates, to user demographics, to coupon codes, license activations, and everything in between. I made it open-source because I thought other developers could benefit from my work. The project gained a little traction. I heard from less than a hundred developers who were using it.
In 2010, as my time at Yahoo! was winding down, I came up with the great idea of building a more robust version of Shine and offering it as a software as a service – a product other developers could pay a monthly fee for and I would handle all of the hosting details. I successfully built the new-and-improved version, switched myself and a few other developers over to the new version, and even secured nine months of runway from two angel investors. I’m sad to say that they subsequently pulled out in fear when Apple launched the Mac App Store. My fledgling business venture died.
I don’t tell that story to get pity. It was a great idea. And I was said to see it fail. But I bring it up to say that one of my other end goals – after successfully signing up lots of independent software developers – was to produce and begin blogging aggregated, anonymous financial stats that only someone with access to everyone’s sales figures could know. There was no evil plan to sell this data. I truly wanted to use the data to infer what business strategies were working and then publish my findings so that the community as a whole could benefit from them.
There’s a misattributed quote to JFK that says “a rising tide lifts all boats.” I’ve always really felt that if we as a developer community pulled together and shared more openly our business strategies, the entire developer ecosystem could rise up, earn more money, and produce even more, high quality software.
We’ve already begun to do that to a limited extent. More and more developers are opening up and sharing their experiences on the App Store and their luck with up-front pricing, in-app purchases, freemium models, etc. Other developers are talking about how they’re encouraging users to write reviews – the lifeblood of any app.
All of these stories are great! They all add to our collective knowledge. By sharing my own story, I simply hope to add to what I see as yet another missing piece in determining the overall health and status of our little ecosystem. It’s why I’ve been consciously trying to write about “Indie Business” so much these last few weeks. Not only to add to the conversation, but, more importantly, to encourage others to do so as well.
