Matt Mazur

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?

The following chart compares three recurring payment options I am considering for jMockups:

1) Paypal Website Payments Pro with Recurly or Spreedly

2) Authorize.net with a merchant account with Chargify

The calculations assume a recurring $8/mo payment from customers:

You can download the Excel sheet here.

Recurly & Paypal Website Payments Pro Calculations:

• Paypal is $30/month plus $0.30 + 2.9%/transaction for sales of $0 to $3,000; $0.30 + 2.5% for sales of $3,000 to $10,000; and $0.30 + $2.2% for sales of $10,000+ (source). For example, if I have 100 customers who are paying $8/mo, my monthly Paypal expenses are $30 + ($0.30 + 0.029 * $8) * 100 = $83.20.
• Recurly is $29/month plus $0.20/transaction for up to 200 transactions/mo; $69 + $0.10/transaction for up to 500 transactions; and $199 + $0.09/transaction for up to 2,250 transactions/mo (source). (Note that if you’re not billing monthly, it becomes a bit more complicated because they also look at how many users you have in addition to the number of transactions — see their pricing page for more info.) So for 100 customers–assuming 1 transaction/mo/customer–Recurly expenses are $29 + $0.20 * 100 = $49.
• Total monthly expenses for Paypal Pro + Recurly = $132.20. Total monthly revenue for 100 customers at $8/customer = $800. Total profit = $800 – $132.20 = $667.80. In this example, 16.5% of the revenue would go towards payment processing.

Spreedly & Paypal Website Payments Pro:

• Speedly is a flat $19/mo + $0.20/transaction. For 100 customer, that works out to be $39/mo.
• For Paypal Website Payments Pro and Spreedly the total is $83.20 + $39, or $122.20, or 15.2% of the revenue.

Chargify with Authorize.net and a Merchant Account Calculations:

These numbers will vary a bit based on the rates you get on your merchant account. These calculations assume a $0.25/transaction fee, a $9.95/mo monthly statement fee, a 2.19% Vista/Mastercard discount rate, and a $25 monthly minimum.

• Authorize.net is $20 + $0.10/transaction (source). For 100 customers, the monthly cost would be $20 + $0.10 * 100 = $30.
• For the merchant account, the fees would total $9.95 + $0.25 * 100 + 2.19% * $8 * 100 = $52.47.
• Chargify is free for up to 50 customers; $49/mo for up to 500 customers, $249 for up to 5,000 customers and upward from there (source). For 100 customers, it would cost $49/mo.
• Total monthly expenses for Chargify, Authorize.net, and this merchant account is $49 + $30 + $52.47 = $131.47, or 16.43% of the revenue. About the same as Paypal + Recurly or Paypal + Spreedly.

Final Thoughts

For an $8/mo subscription, you’re going to be paying 20% or more of your revenue to the payment processors until you reach 50-70 customers. That’s amazing to me.

For this comparison, Chargify wins hands down when you don’t have many customers because their service is free up to 50 customers. The more customers you have, the closer the options become. Also, remember that you don’t have to use Recurly or Spreedly with just Paypal Website Payments Pro — that’s just what I’m looking it; do you own calculations before making a decision.

It’s also important to note that the difference isn’t that much when you work it out. For 2,000 customers, the difference is less than $150/mo, but when you consider that you’re making $16K/mo at that point, things like customer service, how easy their API is to use, and what features they offer become a lot more important than the price difference.

Finally, if you notice any errors in these calculations, please let me know.

Lean Designs, the HTML5 mockup tool I’ve been working on, is now jMockups due to trademark issues with “Lean Designs”. It’s coming along incredibly well and I expect to launch the alpha version in two to three weeks.

If you’re interested in helping test it when its ready, add your email to the mailing list on the jMockups.com homepage.

###

Here’s my daily AccountableTo report:

What did you work on today?

* Improved the code that displays the toolbar when you select an element
– Only show common groups of attributes when multiple elements are selected. For example, a text box might have font and border attributes. A picture wouldn’t have font attributes, but it would have a border. When you select both, the toolbar now only shows the common attributes (border in this example).
– Also, if the element shares common values for a specific attribute (both border widths are 3px), the toolbar defaults to that value. If they are different, it doesn’t display a value for that attribute.
– Changed the default toolbar positioning for selected objects. This has been a bit tricky. For example, you can say by default to show the toolbar to the left of a selected element, but what if that causes it to extend beyond the right border of the screen? You say, OK, then show it to the left of the element. OK, but what if the element spans the width of the screen? You get the idea–the new algorithm works fairly well, but will likely change as I get feedback from actual users.
– You can now reposition the toolbar by dragging it around the screen. jMockups will also remember where you dropped it so when you select that element again, the toolbar will reappear in the same position. The position is also saved when you save the mockup so when you reload the page it remembers where it should appear.

Preceden is coming along well. After several different pricing and freemium model variations, I settled on a $19 premium account which lets you surpass the 5-event limit for a free account. That seems to have worked pretty well and the site is bringing it a few hundred dollars a month with little work on my part.

For the last six weeks I’ve been working on a new web app called Lean Designs. It started off as a tool for making decision trees, evolved into a web-based diagramming tool, and is now slated to become a pixel-perfect mockup tool.  It’s similar to Balsamiq, except it’s completely web-based and high fidelity, meaning it doesn’t looked sketched. The editor is built on top of HTML5′s canvas element, which makes it incredibly powerful in terms of what it can render. My short term goal is to build a tool that can quickly create website mockups that are indistinguishable from the actual sites. It’s not there yet, but it’s close.

(Lean Designs, unfortunately, is a temporary name and will not be what the final product is called. I found out this weekend that the name LEANdesign is trademarked by a company that produces related software with the same name. New name is TBD.)

Also of note is that for the past two months I’ve been using a site called AccountableTo, which is currently in private beta. The site, which is being built by a Philadelphia based web developer named Mike Nicholaides, helps you stay focused by encouraging you to write a daily log of what you’ve done that day, which other members of your group can comment on (Mike and Chris Conley in my case). AccountableTo asks two simple questions: What did you do today? and What’s the next step?. It’s that second question which is the most valuable because it forces you to think about what you’re going and what you need to do to get there. I’ve found it incredibly useful in helping me stay productive day after day.

Here’s one of my updates from three weeks ago:

What did you do today?

Background work:
* Arbitrary HTML color input
* Drop down color palette (thanks Yahoo)
* Select from previously used colors
* Set background color to none
* Ability to change the canvas background color

What’s the next step?

Need to spend a few hours cleaning up the code, which has gotten a bit unwieldy.

Also, I’m considering focusing on creating high-fidelity website mockups (ie, forget about diagramming). It’s tricky because on one hand, adding the diagramming tools would not be very hard, but, it’s easier to market as a “high fidelity mockup tool” than as a “web based diagramming tool that can also do mockups”–thoughts? A natural step once I had this in place would be for it to generate quality HTML/CSS from the mockups (but that would probably be a few months down the road).

That second part — algorithmically exporting to HTML — is going to be fun, though it’s something a lot of developers want and will pay for if done well. Think of it as a web-based Dreamweaver that doesn’t suck. Imagine rendering all the PSD 2 HTML sites obsolete. That’s the long term goal.

I’m also preparing to move to Boston in a few weeks, so my progress of late has been slower than normal. I’m going to wait until I get settled there to launch the mockup tool, so it’ll probably be sometime around October.

Slowly by surely…