Ease of use is certainly something that was in my mind during development. With bitbox.co, you just have to create an account and start dropping files to get going. You can add key/value metadata as you drag and drop. Of course deeper integrations will become more complex, but even then, I want to build a simple "upload/download/search" option that is only a few properties of complexity.
Centralized storage, accessibility, abstraction and usage tracking of all corporate documents sourced from all divisions / systems with proper access controls and redundancy. (That's a lot of business speak).
I've seen this done with a network share / filesystem or as blobs inside an RDBMS; both of which start to fall apart after a certain volume for different reasons. Especially after building a company through acquisitions of various systems. The first step in merging systems acquired through M&A would be to migrate all the documents into a centralized repository (like bitbox).
These systems usually have an auto-kill feature after X years which would be the legally required time to keep a document. Companies would purge the documents to avoid any unnecessary liability after the required retention period (incase they got sued).
Also, they were interested in hot and cold storage, so documents that are say over a month old would get moved to cold storage (or whatever the company workflow dictates) to save money on storage costs (hot = SSD, cold = mechanical).
I was thinking integration would be useful if this got any foothold. Integrate with email servers, scanners, existing sites with upload capabilities, etc. It also keeps a history of everything that happened to a file.
Unfortunately the B2B enterprise sales cycle is brutal and I wanted to avoid that until we got bigger; funding the company through subscriptions of smaller companies that may not have the technical expertise to build a robust system, but still has the need of document storage.
Yes, that was the point of posting this show HN, to see if there is any market demand. I have a few other products in the pipeline and more ideas which are probably more promising.
If nothing else, we use bitbox.co as an internal file storage mechanism for our other upcoming products. We're currently using it in one that is yet to be announced / released.
Can you elaborate on the client issues? We decided to go with WebAPI for universal access. Also, for public images, you can reference the endpoints directly in your HTML, so <img src="https://bitbox.co/files/1.png">
I've built one of these several times for larger companies. They need a place to store millions of documents that integrates with their multiple existing internal systems. These documents would come in from fax, email or integration services.
A benefit this has over cloud storage is that you can store your files across cloud vendors; so it would have cloud vendor redundancy. If Amazon goes down, it will pull files from Azure, and vice versa. This is a future feature if this gets any traction.
Other things it might have over a cloud storage is you can assign tokens with different access levels, so your applications that need read only will be assigned read only tokens and your applications that need read/write can use read/write tokens.
Larger customers that aren't interested in the cloud or are cloud averse with their sensitive documents can do a local install and have it store on a share inside their own network, so the method of storage is mutable; Azure, AWS, SMB, even FTP.
You can also assign searchable metadata to each document, or upload a bunch of documents with the same metadata. So say you have a referral of some sort and it has 20 documents; you can upload all 20 and assign a meta tag as ReferralID: 123, then reference those documents in searches.
![https://bitbox.co/files/1.png">](https://bitbox.co/files/1.png">){kind=link}