2010, 2011 & a $4K/month Challenge

A few months back with what seemed like two months of work left to do, I publicly committed myself to launching jMockups in four weeks. The number of things I wanted to get done prior to launching was daunting, but I desperately needed to get the product out there and in the hands of actual users to start collecting feedback.

How’d it go? I didn’t launch it in four weeks; I launched in less than three.

Public accountability is a powerful thing. Sebastian Marshal writes about his own experience:

If I hadn’t set this goal and been accountable publicly, to my friend and to everyone who reads here, I wouldn’t have done it in two weeks. Honestly – I’m pretty internally motivated, but I’ve had a lot of stuff going on the last two weeks, it wouldn’t have happened. But it did happen, largely because I was publicly accountable.

This productivity hack that works especially well for me. I’m an INTJ on the Meyers Briggs type indicator and one of our defining characteristics is the value we place on competence. By publicly committing myself to launch, I put my own competence on the line so I did what it took to meet the goal. Practically this meant postponing a lot of the things on my todo list until after the launch, working some long nights and weekends, and taking a week off of work.

Publicly committing myself worked well for me once, so I’m trying it again.

The Scene

I spent most of 2010 building. I launched Preceden in late January and continued working on it through May. In June I started working on jMockups and launched it in late October. My focus in 2010 (and largely 2009 and 2008) was on learning and building. I knew I eventually wanted to make money off of the apps, but money wasn’t my primary goal.

I’ll be with my current job until October 2012 so I can’t pursue this full time just yet. Because I have a day job I’ve never had to rely on my web app income to survive. It’s always been like Oh, I had another sign up. That’s nice. That’s got to change.

October 2010–a mere 21 months away–will approach fast. In order for web app development/entrepreneurship to be viable long term, I have to start making more money. My true passion lies in building things–not money–but without money I can’t spend my time building things.

The Goal

I don’t have exact numbers (which is part of the problem), but Preceden currently makes about $500/month and costs $70 to operate. jMockups makes $24/month (whohoo!) and costs about $200/month to operate (doh!). Taken together, I’m making about $250/month.

It’s not entirely fair to value the apps in terms of their current profits, but that’s obviously a big part of it. Preceden targets a small niche and has a small goal: be the best timeline tool. jMockups targets a large niche and has an ambitious goal: improve the way people design websites. Long term, jMockups has the potential to be a home run; Preceden doesn’t.

With that in mind:

My goal is to make $4,000 per month from Preceden and jMockups by the end of 2011.

That’s about 16x what they make now. If a public commitment isn’t scary, it’s probably not ambitious enough. And since this is terrifying, I figure it’s a good number to shoot for.

I’ll make monthly progress updates starting at the end of January.

The Plan

Preceden has a marketing problem. It’s is a quality tool that has a lot of happy users, but not enough people know about it. I need to get more people to the site and need more of them to convert to paying customers. My plan with Preceden is to start marketing it heavily (via things like AdWords), perform lots of A/B testing, and optimize the hell out of it by way of extensive analysis. If I can get Preceden to a point where outbound marketing has a measurable positive ROI, I’ll be in really good shape.

jMockups has a product problem. The tool is good, but not great. Trying to change the way people design websites is hard (I probably should have picked a more narrow niche to start with, but that’s another story). I’ve been adding two or three new features a week since it launched in October, but I haven’t spent much time on the other things it takes to create a successful web product. For example, there’s currently way too much friction from when a user arrives at the site and to when they create a mockup that they’re happy with. And it shows in the usage metrics (75% of new users create 1 mockup and never come back). In 2011, I’ll continue working on the product but I’ll place a stronger emphasis on usability, education, and building a community. The revenue should follow from doing these things well.

I have a sole founder problem. But not really. I like the independence of working alone, but having someone else to build with and bounce ideas off of would be great. I’m not going to spend a lot of time actively searching for a cofounder, but if the opportunity presents itself I’d definitely give it a shot. (Interested? Drop me a note: matthew.h.mazur@gmail.com)

###

So here’s to 2011. I don’t know how things are going to turn out, but hopefully with this public commitment they’ll turn out a little bit better than they otherwise would have.

jMockups Launch

Yesterday I launched jMockups! You should check it out: http://www.jmockups.com

It was thrilling. I was talking to Chris and Mike on Skype yesterday evening and my wife came over and wrote on my notebook, “You are HYPER“. That describes how I was the entire day. Launching is a drug.

Some links:

You should follow me on Twitter here.

A Public Commitment to Launch jMockups

I’m taking Sebastian Marshal’s advice and making a public commitment right now to launch jMockups, the web-based high fidelity mockup tool I’ve been working on since June, by November 3rd.

The jMockups editor – the part of the app where you actually create the mockups – works pretty well. There are a few bugs, but they’re relatively minor and should be easy to resolve. That’s not to say that I am done with its development – far, far from it – but I don’t plan on making any major changes to the editor between now and the launch. It’s a decent minimum viable product.

So why not launch? Two words: billing integration.

After talking with a bunch of folks, I decided to charge for jMockups from the start. I’ve went back and forth on this, but ultimately I think it does go a long way towards defining the product and it eliminates the need for a transition down the road, which was a major headache when I did it for Preceden.

When I first started integrating billing I came up with a multi-tired pricing model that went something like this:

  • Free: Up to 5 mockups
  • Basic: $19.95/mo for up to 50 mockups
  • Standard: $49.96/mo for up to 150 mockups
  • Pro: $149.95/mo for unlimited mockups

The problem is that I have no data to base either the prices or the limits on. It’s all just guessing on my part. I don’t know how heavily people are going to use it or how much they are willing pay for that ability.  Hell, I don’t even know IF people will use it.

I could change the limits and the prices down the road, but then I could be in a situation where some customers are paying different prices than other customers for the same product.  There are ways around this, but they’re all complicated and I’d rather just wait and see what happens.

And who knows, maybe there’s some other way to structure the premium plan other than by the number of mockups a person can create. Maybe, for example, the tiers are based on customized shared pages or the ability to collaborate. If I start with a model based on the number of mockups and then decide I want to change it completely, I’m going to be in a tough spot.

My current plan is to let customers create up to five mockups for free and unlimited mockups for $19.95/month after that (a freemium model). By limiting it to two plans right now, I’ll be able to expand it to four or five down the road once I have more data.

Additionally, anyone who signs up for the $19.95/mo plan, which I’m calling jMockups Pro, will automatically be upgraded to whatever the highest plan is down the road without incurring additional charges. So if I do eventually introduce a $149.95/mo plan with a killer feature set, anyone who signs up for the jMockups Pro plan will get those same features for the same $19.95/mo. This helps keep it simple right now and it rewards the early adopters who take risk by signing up for a new, unproven product.

Anyway, recurring billing integration is new to me so it’s taking a while to set it all up correctly. More on this in another post.

Meanwhile, I’m currently waiting for the paperwork to go through for jMockups LLC so I can set up a business checking account which I can tie to a merchant account to use with Authorize.net, the payment gateway. If I don’t launch by November 3rd its going to be because one of these steps is taking longer than I anticipated.

And with that, it’s off to work.

Recurring Billing Fun

These three threads, one on Recurly’s support forum and two on HackerNews, accurately portray what I’ve been working recently:

On refunds after upgrades:

Ive run into a bit of a snag while integrating Recurly into my app and I’m not sure if its a bug or whether I’m doing something wrong.

For purposes of this discussion, I have a user and two subscriptions: Basic and Pro.

If I try to issue the user a refund after they’ve created a subscription for the Basic plan, there’s no problem. However, if the user creates a subscription with the Basic plan, then upgrades to Pro, I’m unable to issue them a refund.

When I try to do it via the Test Site, I get the following error message:
“The refund could not be processed because the original transaction could not be found.”

When I do it via the Recurly gem, I get the following error:
ActiveResource::ResourceInvalid: Failed with 422 Unprocessable Entity
recurly (0.1.4) [v] lib/recurly/subscription.rb:20:in `refund’

In my test app, the Basic Plan is $15/mo and the Pro plan is $100/mo. It makes sense that if the user upgrades from Basic to Pro immediately and then wants a full refund, I should not issue them a $100 refund (because the $85 difference hasn’t been charged yet), but I’d still expect them to be issued a $15 refund, no?

If you need step by step instructions for how to reproduce this on my Test Site, I’d be happy to provide them.

On how and when to charge:

I’ve been building a web-based mockup tool called jMockups for the last several months and I’d like to get your thoughts on when and how to charge for it.

I’ve asked several experienced members of this community whether I should charge from the start or wait and charge down the road and I’ve had mixed feedback. Those that say charge now say that I should establish from the get go that this is a high quality product worth paying for and that transitioning from free to paid is a pain (which from my own experience with previous sites is true).

Those that say charge down the road say that I want to get as much feedback as possible right now to make it a better product, that I’ll get more inlinks and buzz because more people will try it, and that I’m in this for the long term so its not a big loss if I don’t charge for the first few weeks.

The second issue: how much? Balsamiq is the clear leader in this space and their main product sells for $79. We don’t have identical products — theirs focuses on low fidelity whereas mine currently focuses on high fidelity mockups — but there is a lot of overlap. I plan to charge per month and offer a free option for folks to try it. I find myself basing my pricing off of this $79 number ($7/mo = $84/year) and while I think thats something that a lot of folks would pay, some of the feedback I’ve gotten is that I’d be better off charging much higher… $20/mo on the low end.

I don’t have enough experience to decide with certainty on either issue which is why I’ve been asking for feedback and I’d like to get yours too: charge now or wait and how much?

On prorating refunds for canceled accounts:

I’m integrating a recurring billing service into my web app and am at a point where I have to make some decisions on how I want to handle some situations. I don’t have much experience with this and am hoping to get your feedback on these questions and monthly billing in general:

1) If a customer cancels their account should you offer a prorated refund for the unused time? Or do you establish a policy that your monthly payment will not be refunded at all when you cancel your subscription?

2) Should you let customers cancel their subscription to your service without deleting their account? In other words, should there be a “standby” state that locks down their account so they have the ability to resubscribe in the future and keep their data, or do you make canceling their subscription and deleting their account/data a single, inseparable action?

And for those of you who have been faced with similar decisions, can you remember other important decisions that you had to make? Appreciate it.

Integrating a service like Recurly into your web app is not that hard, but handling the edge cases and making policy decisions complicate things a lot. Plus, billing is something you want to do right the first time. There is no minimum viable product for your billing system. You get it wrong and it could take a long time before you dig yourself out of the hole you create, especially if your users are vocal.

What fun would it be if it was easy?