…unless they don’t.
Nothing’s ever as simple as it first seems. Scarecrow, a product we’ve been working on lately, started out as a “simple” request from a local business owner. He wanted to know: is there some sort of script that can tell me if my website gets hacked?
Hmm. Interesting. “Why, LBO,” I said, “maybe. How come you want to know?”
Turned out his site had been hacked already. The web developer he’d hired had left a vulnerable script accessible, and suddenly the site was all about porn (no, not this kind). Clever, too, the way the hackers did it–it all seemed designed to increase the Google page-rank of some sleazy sites, which isn’t quite like solving world hunger, but still.
So Cabin Fever’s WebChecker was born. WebChecker (now obsolete) went out and verified that a website’s source files hadn’t changed. If they had changed, it logged the issue and sent email. It didn’t have much of a user interface, because it ran in the background as a service (under Windows).
So that was okay, as far as it went. But then…suppose WebChecker had that user interface? What if it could show you, not just a list of files, but exactly what had changed? To do that, of course, it had to save previous file versions. If it was saving them–hey, that’s a backup program! And maybe it could restore files too!
And…what about people who didn’t want to install software, or wanted to access their data from different locations? Could we do the whole thing as a web application?
Well. Sure. Of course we could. It was just a matter of dedicating the time. And why not build in a site uptime checker, while we were at it? And shouldn’t this be a distributed application, with “checkers” thousands of miles apart?
Of course it should have all that. And more.
Thus, Scarecrow. Which looks to us like a marketable product.
Then there’s our “configulator.” It doesn’t get capitalized (which is a deliberate pun, and I don’t apologize). There’s this other local business, see. They build and maintain computer networks. They wanted an easy way to use standard templates for text files. They’d messed with MS Word macros and mail merges and so forth, and it was just too complicated. Or at least it wasn’t easy.
So…okay. We built ’em an easy solution. They make text file templates, putting stuff that changes in angle brackets, like <<this>>. The configulator then creates any version of the template they like, substituting actual data for <<these>>. So all our customers needed was a way to create templates and enter data, right? How hard could that be?
At first this seemed to be a no-brainer desktop application, but it turned out they wanted, eventually, to let their customers use it.
Suddenly it was a web application. And it needed user- and group-level security to protect the templates and “data files.”
Data files? Well. Suddenly they’re saved versions of the template, with user-entered data substituted for the <<stuff>>. And they’re downloadable in either .txt or .csv format.
We built that. And then…well, what if the thing allowed .csv uploads of data? What if it also allowed a .zip download of all templates and data files, for backup/archiving purposes? What if it allowed a .zip upload for that matter? Shouldn’t we allow our customers to each have their own logo and color scheme, as well as separate databases for their templates and data files? I mean, that’s pretty reasonable if they’re going to show these things to other people, right?
See, no part of this game is hard. None of it takes much time, in itself. But if we kept playing with the configulator it would get huge quickly. And we’d need a reason for that. Even though the above features would only take us about four days to implement, test, and deploy…that’s four days we wouldn’t be spending on something that users actually want.
Here’s the thing: WebChecker got to grow up and become Scarecrow. The configulator? We don’t see a market for it. We’re proud of it, we enjoyed working on it, but at this point, it doesn’t look like a product to us. So we’re done.
This is your chance to tell us we’re wrong. If we are, we’ll pick it up again.