SaaS To-go

I am building a startup, Tap, a place to write and build awesome tools.

There is a very reasonable concern of Tap members that once they build up a collection of content, and for whatever reason want to leave the service, have no way of continuing to use that content.

I've tried to address the concern in a few ways:

• Export your content anytime to a standard format that can be utilized elsewhere
• Parts of the software are open source. Build your own app!
• Combine the two features above and you can (in theory) reconstruct your Tap experience elsewhere

However, these options haven't fully satisfied the concern. For one thing, the options are limited to people with experience manipulating data or building software. The completeness of your independent-Tap-experience is correlated directly with the skill you have to develop it.

The feeling that Tap's current solution is inadequate led me to a different way of thinking. I'm referring to it as "SaaS To-go". You heard it here first.

The idea is pretty simple: while you use Tap you're building stuff that can be taken with you when you leave.

To start, every Tap account can export their collection (or part of their collection) into a static website. The static website is packaged as a zip file containing a folder with all the site files. That zip can easily be uploaded to any number of static website hosting providers. See our guide on how to upload to some of the more common services available (some for free).

Going forward I would like to continue to expand the range of outputs available.

Some ideas:

• Content to PDF, Doc etc.
• Content to e-reader
• Beans to Excel, Sheets, etc.
• Etc.

Many services out there produce artifacts: design software, image manipulation, invoice generators etc. What I'm aiming to do with Tap is a little different. Members build collections of content and data, then put those collections to use, inside and outside Tap itself (both, while you're a Tap member and after you leave).

The difference is subtle: SaaS To-go is about leveraging as much of the original experience as possible independent of Tap the company.

Other Notes:

Another popular option to ensure there's no lock-in and also provides a life-after-death solution for the service is an "open-core" model.

I've considered it. There are two things preventing this at the moment: availability of my time and service integrations. The first is pretty clear. I'm bootstrapping Tap, one person (apart from Santa) writing all the software, marketing content, documentation, running support, keeping the servers running. I also have a toddler, farm and another job.

For the time-being I've decided against it for a few reasons:

• Most of the work on Tap is a one-person show, an open source repo is work in addition to the already intense workload of running the business
• And I'm not interested in building an open source project as much as I am about building a company (for now)
• A lot of the functions of Tap are not easy to replicate without integrations to other services (paid and unpaid): SMS, email, Telegram are a few examples.