Acquired!
As those of you who know me (and probably a fair few that don't) will already know, PythonAnywhere was acquired by Anaconda, Inc back in June of this year. We're still the same team, and I'm still leading it, but now we're part of a larger company.
It's been quite a ride. Due diligence and negotiation in the months up to the close was just as tough as I'd always been told it would be (and that's despite the fact that according to our lawyers it was a pretty smooth one as these things go). And now I have to get used to having a boss again, which is weird... but is helped by the fact that said boss is a great guy, and is aligned with us (you can tell from the lingo that I work for a larger company now, right?) on keeping the platform up and running as it was, while investing into it so that it can get better and grow faster.
So, all good news :-)
I've been vaguely considering putting together a few blog posts outlining what happens during an acquisition -- just a general discussion of the steps and what they involve. I wouldn't be putting anything in about this particular deal, of course -- there are strict non-disclosures about the terms and so on -- but just a description of what happens might be useful for other people in the position I was in earlier on this year. I had to learn a lot of stuff very quickly, and while our lawyers were awesome and explained things brilliantly, it would have been useful to have some kind of layman's background information.
What do you think -- worth posting?
A somewhat indirect way of reporting stolen cards to the bank
One of the interesting things about having a business that accepts cards on the Internet is seeing what odd things people do when trying to use your site. A case in point is someone we've noticed over the last few months, who appears to be using our site as a rather indirect way to report stolen cards.
The behaviour that we see is that they run some kind of script that signs up for a bunch of accounts, with randomly-generated usernames, and then try to upgrade them all using stolen card numbers.
Naturally, our fraud-prevention systems pick that up pretty much immediately, and we run our own script that identifies every account that they've created, finds the card details used for them, and reports every transaction and attempted transaction as fraudulent. This means that our payment processor, Stripe, can flag the card numbers as stolen, so that they can't be used elsewhere without triggering fraud alerts to the other merchants. And, if a charge actually goes through (most of the cards tend to be pre-paid with no money on them, so most charges fail), then we refund it as fraudulent, which not only notifies Stripe, but I believe notifies the bank that the card number is circulating amongst card fraudsters.
Now, the fact that we do this should be obvious to them. Every time they run their scripts, it causes a minor inconvenience to us (the scripts that we have to handle the problem are getting ever-simpler to use), and it means that every card that they tried on our site is now significantly less valuable as an asset to them. They're essentially paying money for lists of stolen card numbers, and then burning it up.
Given that we're doing this, and they must know that we're doing it, the only explanation I can think of is that they're actually running some kind of strange public service where they buy lists of stolen card details and then get them blocked. It does seem a very roundabout way to do it, though. Surely it would be easier to just tell the banks directly?
But perhaps there's something I'm missing.
Or perhaps they really are dim enough to be using us to check stolen cards for validity, and haven't yet noticed that doing so against a site that reports every fraudulent transaction to the card processor is not a terribly good idea...
Does #EUVAT make accepting bitcoins impossible for EU-based digital services businesses?
Earlier on today I blogged a description of what we had to do at PythonAnywhere to handle the upcoming EU VAT (~= sales tax) changes for digital services . It's a long post (though I tried to keep it as light as possible), but the short form is "it was hard, and at least in part unnecessarily so".
In a comment, Hristo suggested a workaround: "Enter Bitcoin".
It's possible they meant "and ignore the tax authorities entirely", but let's consider the impact on businesses that want to play by the rules. I think Bitcoin could be worse than credit card billing. In fact, if I'm reading the regulations right (and I might not be, I was up at 5am for a deployment today), the EU VAT changes might make accepting bitcoins pretty much impossible for law-abiding online EU businesses selling digital services like hosting, music downloads, and ebooks.
Here's why:
Under the new rules, we need two pieces of non-conflicting evidence as to a customer's location. The IP address can be one of them, and for our credit card/PayPal customers we can use their billing address as another.
But for Bitcoin, there is no billing address -- it's essentially digital cash. And regarding the other kinds of acceptable evidence:
- "location of the bank" -- not applicable using Bitcoin.
- "the country code of SIM card used by the customer" -- not available for an ordinary Internet business.
- "the location of the customer's fixed land line through which the service is supplied to him" -- not available for an ordinary Internet business.
- "other commercially relevant information (for example, product coding information which electronically links the sale to a particular jurisdiction)" -- not applicable for a standardised product. Possibly usable if you're selling SaaS tax-filing or something else that's entirely country-specific.
Now, perhaps that list is non-exhaustive. It's hard to tell whether it is
because it says we must "obtain and to keep in your records 2 pieces of
non-contradictory evidence from the following list", which implies that it's an
exhaustive list, but then says "Examples include", which implies that it's not.
[UPDATE: they've updated the guidance, it's definitely non-exhaustive] But even
if it is non-exhaustive, and, say, you can use a scan of someone's utility bill
or other stuff like the proof of address stuff you need to provide when you
start a bank account, I can't think of anything that anyone would be likely to
be willing to provide for digital services like web hosting, music, or ebooks.
All of this means that, at least from my reading of the rules, we cannot now accept bitcoins as a means of payment. I've asked our accountants their professional opinion. But I'm not holding out much hope.
What do you think? Am I missing something -- perhaps some kind of other proof of location that an online business accepting Bitcoin could easily gather?
Or is Bitcoin now effectively sunk as a means of payment for digital goods sold by businesses in the EU?
IT headhunters considered harmful
I got an interesting call from a headhunter today; he knew that we were likely to start hiring software developers at Resolver Systems soon (keep an eye on our jobs page or drop me a line if you're interested) because he had helped someone who'd chosen to leave us to find their new job.
As I said, it was interesting. I admire his honesty if not his morals; while most such people will merely hint about things, this chap came straight out with it: "we're actively trying to poach people who work for you, and we'll stop doing it if you stop trying to recruit people on the open market and use us instead".
Talk at London Geek Night
Last Thursday I did a talk at the London Geek Night about the business side of founding Resolver Systems; 10 minutes or so of prepared talk and then 20 minutes of Q&A, which was the structure suggested by the night's organiser, Robert Rees. Skills Matter recorded the whole thing, and the video's online now (albeit inexplicably categorised under Erlang). Be warned that I was talking particularly quickly that evening, even by my normal standards of gabble, so you'll have to listen carefully :-)
Other talks that evening were from my colleague Jonathan Hartley, who talked about the tech side of Resolver Systems, and Martin Dittus of Last.fm, who talked about some of the heavy-duty tech infrastructure they use.
How much we decided to charge for our software
A couple of weeks ago I asked how much we should charge for our software. There were some really good responses in the comments, in particular Andy Brice's link to the Joel on Software forums (which I'm now devotedly following). My takeaway was:
- You can probably charge more than you think.
- You should ask your existing customers.
The post also included a poll, which came in with an almost perfectly linear relationship between price and the number of votes; the lower the price, the more people voted for it.
Since that post, I've emailed our existing customers and crunched the numbers. The results were pretty convincing -- our price point was too high. When we released version 1.3 of our software, we'd bundled in our webserver option and pushed the price up from $199 to $399. Almost every customer we asked felt that that had been a mistake. For many of them, the webserver wasn't of interest, so bundling it in wasn't useful. And the new price took us out of their impulse-buy range. So we're going back to the old model - $199 for the core product, $199 for the webserver.
We announced this on Tuesday, and sales have already ticked up.
How much should I charge for my software?
Deciding how much you should charge for a piece of computer software is really really difficult. Even testing a given answer is hard. You can vary the price and watch your sales, but that can only tell you so much -- how do you control for other factors? You can look at your competitors, but who's to say they've made the right decision (if all the other software companies jumped off a cliff, would you jump too)? You can look at economic models, but in general they're great for pricing goods made of atoms but terrible for goods made of information.
All you can do is get as much data as you can, churn the numbers, and try to work o ut an answer. You fiddle with the price and do discounts, and see what happens. You talk to your existing customers and ask them how much people who haven't bought yet should pay. Or you ask the hundreds of brilliant people who read your blog :-)
So: what do you think? How much should we charge for Resolver One? Let me know in the poll below. I've not given "zero" as a response, but if you can think of a viable free software business model for us then you can post it in the comments. (Raising VC and then selling at an inflated price to Sun doesn't count :-)
[UPDATE] poll has expired
[UPDATE] Hello to visitors from reddit; I've added a link to the product information above so that you can see what software I'm talking about.
[UPDATE] An excellent link in the comments from Andy Brice (whose blog looks well worth reading). My takeaway: Don't try to compete on price alone. You can charge more than you think, and the best way to find out how much is to ask people, in particular your existing customers.
It was also great fun rereading this Joel Spolsky gem.
Product management with Google AdWords
You can't rely on people's response to your advertising to manage your product -- but as one of many inputs, perhaps it could be valuable. Can part of the product management role be taken over by aggregating data from carefully-targeted Google AdWords campaigns?
Do one thing and do it well
It's all change at Resolver Systems.