A profitable, growing, useful, legal, well-loved... failure
Since before graduating from university and up until taking my current job
(which is its own story I'll tell some other time), I've initiated several
things that could be called startups. That is, we incorporated companies,
we had a small number of people that got paid wages, we collected Canada
SR&ED tax credits. Every one of these startups turned a profit. More
than one had outside financing. One of them we sold to IBM.
I'm telling you this not to show off, but as a setup for the rest of this
story. What I want to explain is that I fail strangely. Or at
least, it feels like I do. Maybe it's not so strange; maybe you should just
go read Paul Graham's How Not
to Die article, where he advises us that "Startups rarely die in mid
keystroke. So keep typing!"
Because that's really the moral of this story; or maybe it isn't. Maybe
this story is about how that advice hasn't actually worked for me, because
inside each of those successes is a story of failure. It's interesting,
because for any of the companies I've started, by leaving out some details I
can honestly make them sound like resounding successes or resounding messes.
If I include all the details, then, well they're just confusing. So you'll
usually hear just one side or the other, depending what point I'm trying to
make.
Today I'll tell you both sides though, for just one of those companies. I'm
not going to name the company here but it's still alive, it's still making
money, my co-founder is still working his butt off to keep it from falling
over. Given the details I'm about to share, it's trivially easy to find the
company name with a little Googling, and I encourage you to do so. I just
don't want to name it here because I really don't want this article to be
the first one that comes up when you Google it. (This diary has way more
Google Juice than the company does... though the company has a much more
profitable sales funnel.)
So anyway, here's what happened. We started the company back in 2008. We
wanted to do something in the world of databases, because we figured
databases were ripe for disruption, what with SQL being SO VERY SUCKY in so
many ways. We wanted to create a new variant of SQL based on the analogy
that (our new thing) is to SQL as C is to assembly language. That is, C is
little more than a portable assembly language. So we need a portable
version of SQL. (If you've used more than one SQL variant, you know the
analogy is apt.) Oh, and maybe we'll throw in functions and variable
assignment and loop control structures while we're there. Yeah, I know,
crazy. But if you've written stored procedures in MS SQL, those are the
things you know you need.
Why did we want the C of database query languages, instead of something
modern, like the python of database query languages? We thought this was
the clever part of the analogy: it's because people already *tried* the
high-level query languages. They're called ORMs (object relational
mappings), and sure enough, they're just like high-level languages were in
1975: slow, bloated, wasteful, unreliable, non-portable, and nobody can
agree which one is best. C changed all that. Sure, there were non-portable
features in C (there still are), but dammit, + was just always +, and for
loops were for loops, and the world made one big step forward. People still
use C today. High level languages are much better now, but they're almost
all still built on top of C. How much better could the world be if we could
do that for SQL?
Anyway, that seemed really hard, and we were just two guys who wanted to get
a minimal product launched in, say, 4 months. So we decided to trim down
the idea. What's the minimal idea that will get us in that direction, but
with a product in 4 months? Well, first of all, to invent C you don't need
multiple assembly language variants; you just need one to start with. Let's
pick one. Why not the simplest one we can find? A bit of searching around
revealed the obvious candidate: Microsoft Access. It's even dumber than
MySQL.
Okay then, what will we build on top of Access? Well, we want to make a
portable, slightly-higher-level query language. What will be its initial
use case? Forgetting about other databases for now, what do Access
developers need most? ... Ah, to publish their data on the web, of
course. Access totally sucks for web development. (Even now it does. They
keep claiming to have finally added web support; Access 2002 had web
support. But it's nearly useless every single time. Still is.)
So we would write code to let you easily query Access tables using web
tools, like AJAX or json or whatever. Excellent, that justifies writing our
query parser, but it doesn't have to be feature-complete on day 1. We can
add more database engine plugins later. We can get a few customers, launch,
and iterate. Perfect!
Just one little problem. You have to actually get that data to the web
server. The reason Access sucks for web apps is Access databases are a
single .mdb file on your desktop machine. Multi-user access means multiple
clients accessing the .mdb file using a samba file share. (People do this
with dozens of users at a time. It works.) But how do you get the
data onto the web?
Well, the .mdb file format is undocumented. Reverse-engineering it will
take forever. So we'll write a plugin for Access, that reads through your
data, exports it to text, and uploads it to our server. That turned out to
be a fair bit of work, of course, but whatever, I do love replicating data,
and we figured the ability to replicate SQL databases could be a big deal,
so it's certainly not a waste of time. (Trivia: Access has also supposedly
had database replication features since, I think, Access 2000. Too bad it
doesn't work ON THE INTERNET.)
Once we were well under way writing the replication system, we thought about
it some more and realized that the minimal product for our 4-month launch
target didn't have to include a query language at all; just replicating the
databases was surely enough to please some user somewhere, as long as it
would sync in two directions. Ta da, Internet-enabled Access replication!
So we stopped after writing only the barest minimum query parser. (To this
day you can still export your tables and search them using json queries;
it's pretty cool, but we haven't done any more work on the query engine.)
We got the basic Access web replication engine working (which was a huge
amount of work, don't get me wrong, and the code is singularly awesome, but
I'm going to skip over it here). We gave it a convincing-sounding version
number with the word BETA in it, put it up on a web site I designed with my
super lame web design skills, and waited for the world to beat a path to our
door.
Okay, you know how this goes, right? You can't just do that. Nobody will
come.
Well, this time you're wrong. People came. We had stumbled into a huge
unsolved problem and unaddressed market. There are lots, and lots, and
lots, and lots of legacy Access databases in places you don't even want to
think about. If you find our web site and go to Testimonials and scroll to
the bottom, you'll see what I mean. The actual CIO of a huge pharmaceutical
company called us out of the blue and asked us to solve their problem
because they have thousands of Access databases they want to share
across their tens of thousands of seats.
But I'm jumping ahead of myself. Not all those people called us on day 1.
On day 1, our website sucked, because it was talking about Access
Replication.
And what the bloody hell is replication? Most Access users with Access
problems didn't have a clue. They certainly weren't searching for it.
That didn't stop some of them from finding us and calling anyway. See,
we also had a couple of pages talking about our query engine, and they
contained phrases like "Access on the Web." Turned out a lot of people were
searching for that. They still are. Microsoft caught on with Access 2010
and marketed the heck out of that search phrase, so if you search for it
now, you'll find them and not us. Which is funny, because Access 2010 is
still basically useless for the web. But it shows what marketing dollars
can do.
Now, I'm badmouthing Access 2010 a lot here, but here's how I know it's
useless: because people keep on clicking, and searching, and I don't even
know what keywords they search on anymore, and they find us. They use
Access 2010. They're not dumb, they're real programmers, they know what
features Access 2010 has. Even if they were dumb, God knows Microsoft has
marketed them to death. And these people still want to pay us to put
Access on the web.
Anyway, I've gotten ahead of myself again. The important part of the story
is, we had a web site all about Access replication, and nobody had any clue
what we were talking about, but they called and emailed and the message was
clear: We want Access on the web. How much money can we pay you to provide
it?
Um, well, look, the on-the-web part is kind of sucky and...
...and the customer is always right. So, back to the drawing board. One
day, a customer called me and explained his very specific and immediate
problem. He had just billed a customer many thousands of dollars over many
months to build a custom Access application. Right at the end, the customer
said they were happy. Now... he should just publish it on the web and
they'll be done.
Oh. Crap. The guy was really in trouble. Serious trouble. They hadn't
specified the requirement up front; he was an Access-only developer, so he
couldn't rewrite it. Even if he knew how, it would be months more work.
(People complain about Access, but it's still, in my opinion, the absolute
fastest way in the universe to make powerful database-driven apps. Way
faster than Ruby on Rails, and you don't even have to be able to code. I
mean it. But... not on the web.)
So he had a serious problem, and let me tell you, our 5%-finished json query
language was not going to solve it. Neither was "replication." But that
day on the phone, we came up with an idea.
What if we could run Access on our servers and display it over VNC in a web
browser? What if we ran Access under Wine on Linux so we could squeeze more
instances onto a single box? What if changes to the database in these VNC
sessions could be replicated back down to your desktop copy of Access using
our plugin?
What if, indeed. Turns out there's a cool program called Flashlight-VNC
that's an implementation of VNC in flash, which runs in virtually any web
browser (this was before there was an iPad or Apple dropped Flash out of
Safari). Turns out recent versions of Wine can actually run some versions
of Access. Turns out... well, let's just say it worked. And that, my
friends, is the product we have today, more or less. Sure, since then we've
added performance optimizations, reliability improvements. We store the
database contents in git and use a custom merge algorithm for resolving
changes made while in disconnected mode. (It's neat; git can store the
whole revision history in less space than the original .mdb.) But
fundamentally, that's the product.
And people want it. No, I take that back; the product is a magnificent heap
upon heaps of insane hackery. I mean, we are running Access in Wine in X11
on Linux in an isolated user account on our server slice that revision
controls your Access database in git, and we're displaying it using VNC in
your web browser in flash. People can't possibly want that.
But they need it. Which is better.
That's the other neat thing. They need it, because nobody else has ever
created something like this. I don't think anybody ever will. I mean, how
many people know Linux, Flash, C++ (for the plugin), python (for the
server), and Microsoft Access, of all things, and are willing to combine
them all with a healthy knowledge of streaming network protocols and
database replication? And even if you could find a whacko like that, would
that person be willing to enter the market, starting from scratch, knowing
someone else got there first?
Every month, we have more revenue. And our costs are tiny, so that means
more profit.
Customers need this so badly that they're willing to pay a lot for it. Like
$35/user/month/database, for the basic plan. In case you're counting, in a
year, that's much more than a copy of Access. And just to be safe, because
we want to avoid lawyers, we tell customers to make sure all their users
already have an Access license on their desktop (in addition to the legally
required ones we have for our servers). This isn't so bad; turns out big
companies - the kind with lots of Access databases - pretty much all buy
Microsoft Office Professional for everybody anyway, so they all have Access.
So no, in case you were wondering, our business model is not about cheating
on Access licensing. If anything, people are buying more licenses than they
strictly need, and I don't feel like getting on Microsoft's bad side, and
neither do they, so everybody wins.
No, it's not about cheating. It's just about providing something people
want and are willing to pay for. What do they want? They want to not
rewrite legacy apps. Please, please, let us just keep running the app we
spent the last 10 years building, but let us run it outside our office,
because we all have laptops now.
How much money will people pay to keep their app going? About as much as
the cost of rewriting it in a web language. More, even, since it lowers
their risk. You do the math. As a bonus, it's a small monthly expense, not
a big capital expenditure.
And yes, every month, our profit is more than the last one.
...
But all that was the good news.
I've already given you a hint about the bad news. Remember when I asked
what whacko, with all those skills, would want to do this? I now know one
of the answers, and it's OH GOD NOT ME. Eventually I realized that there is
no windfall big enough to rationalize spending 3-5 years of my life, working
full time, writing compatibility layers for Microsoft Access. Where, in the
ideal world, if we were successful, my days would involve on-site visits to
huge bureaucratic companies of the sort that... well, let's be honest. The
sort that would run mission critical Access databases.
Really, on a rational level, I know that's unfair. I know these are good
people. I think Access developers are great, actually. I love the fact
that they know a good thing when they see it. Access *is* the easiest, most
rapid of rapid development environments I've ever seen. I think almost all
database developers have terrible taste, because they can use Access and
compare it to, say, MS SQL, and not see what makes Access great and MS SQL
suck, even while they know perfectly well the development in MS SQL + C# or
Java will take something like 10x as many man-hours. For some apps, it's
worth it for the higher quality; for a random internal business process app,
it's not, but people spend it anyway because they "heard Access isn't
industrial strength."
So don't get me wrong. I like Access users. Access developers, in
particular, are the anti-IT department, the rebels, the people who aren't
willing to wait for the sysadmins to provision them a server, and they don't
have to, because they can just share an Access file on the fileserver. IT
departments hate them, which is how I know they're on to something. These
are the kind of people I want to help. This is the sort of thing that's the
reason I do the work that I do. No kidding.
But, Lord, no, don't make me actually code Access plugins. Don't make me
work with Windows anymore. Just don't.
God. It's so lame when I write it down. Actually, it's been lame for
months, every time I even think it. I can't believe I have that kind of
lack of follow-through. I don't want to think that about myself. It's a
travesty. A terrible embarrassment. Something that makes me question my
self-worth. If I can't take something that's so obviously working, and milk
it for all it's worth, then what kind of human am I, anyway? I think I suck
at capitalism. Maybe that's it.
You know the truth? I don't know. I just don't know. I am a completely
irrational human being, and I hate it, but deep inside me there's a voice
that just says, "No. Get the hell out. If you continue doing this, you
will die."
So I got the hell out. I "stopped typing," as Paul Graham might say.
Nowadays I have a pretty great "real job" where I can spend all night
hacking the Linux kernel, programming embedded systems, and working on
highly parallel build systems. And even though the potential upside is much
less, I like it. For now, at least. I'm happy.
And that's my failure. Every day, my co-founder keeps working away, keeping
the systems running with as little effort as he can spare. He's got a day
job now, for various reasons; among them, he's an extravert, he needs
co-workers. I still own half the shares, but I told him to keep the
operating profits; the least I could offer, literally, I guess. That huge
pharma deal is still in the pipeline and needs another callback, but there's
nobody willing to do it. We don't optimize the web site for Google anymore;
we haven't updated the news page since 2010; even I can't find our site in
Google using any generic keywords. But I guess I'm not looking hard enough,
because new customers still find it, sign up, and subscribe. Virtually
nobody ever cancels once they've started. There is no competition. Nothing
to switch to. There never will be. Where would they go if they stopped?
I know I've let my co-founder down. If the company would just die - if it
would only be so simple, and nobody would want the product, or the users got
angry at us and quit, or it were impossible to run it at a profit and we
finally ran out of cash - then stopping would be easy. But no. They love
it instead. They need it. There's an opportunity cost in
continuing, but there's a sentimental cost in shutting it down - to say
nothing of the users who have no other options.
In short, I learned that I don't have what it takes. Someone probably does,
now that the actual insane part has already been invented, but I don't know
who.
What would you do?
Syndicated 2012-03-24 22:53:34 from apenwarr - Business is Programming