Why we're getting away with what we're doing

A rare post in which I talk about my day-job.

We're doing a few things that are either really freaking cool or head-scratchy depending on your point of view. We've kicked a Software-as-a-Service product out the door that's aimed at the business market, specifically the legal bits of the business market.

Not supporting all IE versions.

A B2B product that doesn't support all IE versions? We're nuts.

And yet... there are enough law-firms, corporate legal departments, and civil-service law entities out there that don't have Mandatory IE policies that we're finding quite a lot of business. Yes, it does prevent some potential clients who are otherwise enthusiastic about the product from being able to use it. But we feel strongly enough about not having to support older IE versions (anything IE8 and older) that we're willing to let those sales go elsewhere.

We feel that those entities that do have flexible browser policies gain a significiant competetive advantage by using us, so we're OK with letting the inflexible slide. They'll get the clue eventually. We'll be there for them.

Embracing collaboration between entities, not just within the entity.

The nice thing about a SaaS product like we've built is that it allows people across the world to use it without having to have their own local install. This is a surprisingly revolutionary thing in this market because this market is filled to the brim with ultra-conservaties when it comes to data handling. Collaboration is the product of careful negotiation between entities over exactly what kind of data must be shared, what meta-data about the data will also be shared, and who will have access to it.

HIstorically the workflow for this has been:

  1. Negotiate.
  2. Build an export of the data and meta-data using industry standard(-ish) formats.
  3. Export data (possibly to disk).
  4. FedEx / FTP data to the other entity.
  5. Import the data into the system.
  6. Dicker over incompatibilities (those industry standards are only standards-ish).
  7. Repeat steps 2-6 until it imports right.

Total run-time, 1-5 days.

Our product can support this old-school workflow (up to step 3, same as the old days, and we're working on step 5), but we're really pushing for a new model based on online collaboration.

  1. Negotiate.
  2. Build and tag a dataset for sharing.
  3. Add a user to the Project with access to just that restricted set.
  4. Communicate with the other entity and get them logged in.
  5. They start working.

You can do that in a day. And if you can skip the first step, such as with an Expert Witness, it goes even faster.

The people we've shown this to have been blown away, even though this workflow is present in other markets. I believe I mentioned our market is deeply conservative? Yeah. We're working on changing that.

30 days to pay your bill or you get locked out

Anyone who has ever done business with certain types of big business or government knows they're big fans of the "pay you eventually" model of finance. You'll get your check, but only after a long wait (60-180 days) or whenever they feel like paying. The SaaS movement has been doing a lot to break this since so many such services operate on the pay-in-30-or-else model.

[Which we ran into ourselves. One of the company credit-cards expired in April and we didn't do a good enough job of tracking what all was using it for auto-pay. A whole bunch of services locked us out at the end of May.]

A client of ours who could be a major customer is learning this right now. They're a pay-in-3-6-months kind of shop and figured that bit of the usage agreement didn't apply to them. They're learning about or-else right now.

This pay-eventually model is rife in the non-SaaS market, which we've been in for many years. We know what these entities will pull because they've pulled it on us before (one memorable now-fired client went a year and a half between payments). Going SaaS and embracing the SaaS payment model allows us to lever sanity into our finances.

Yes, it'll lose us clients. But...

Not all clients are worth having.

This is something all small businesses figure out, and we're embracing it.

  • Technologically backward clients aren't worth the trouble to backport our stuff to.
  • Clients who are assholes about money aren't worth our time to bother with.
  • Clients who are endless fonts of special needs aren't worth the trouble (though they may be a good source of feature-requests).
  • The SaaS market we're in is wide open, there is always another client.

Yes, we may only be able to 'reach' 60% of our potential market (that number is made up), but those that do work with us will help bootstrap the industry into the modern era. Especially after the network-effects of collaboration kick in.