Show HN: Bitbox.co – Cloud Storage for Developers
46 comments
Quick thoughts:
- I don't understand the value proposition relative to other cloud storage providers
- Hire someone to do your UX (could start with just landing page layout, icons, and color theme)
- Selling to developers is a challenge (http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html)
- Your pricing sets you up to compete on Gb/$/month which sounds like a hard battle for any startup to win
- Keep going!
- I don't understand the value proposition relative to other cloud storage providers
- Hire someone to do your UX (could start with just landing page layout, icons, and color theme)
- Selling to developers is a challenge (http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html)
- Your pricing sets you up to compete on Gb/$/month which sounds like a hard battle for any startup to win
- Keep going!
I agree with this comment except for the keep going part. It seems you've spent a lot of time building this but not a lot of time considering the value proposition. I think there is nobility in stopping projects, and this one seems liable to eat another year of your life if you continue as you have.
This is harsh. Any creator knows the feeling of pouring time and effort into something, the anticipation of showing it to people, the excitement of making people happy, the doubts of being judged and criticised. And the crushing feeling of seeing negative feedback.
I appreciate that you're trying to save some kind of longer-term pain and to encourage loss-cutting, but I think the tradeoff of the damage you can do with a two sentence comment that takes a couple of seconds to fire off vs the hundreds of hours that went into creating something like this, far outweighs the potential benefit (though it seems the creator took it graciously).
To me it seems like a "benefit of the doubt" applies here. The creator obviously saw a need and tried to fill it. As someone who has spent hundreds of hours dealing with Dropbox and S3 APIs, I believe there definitely is room for a far simpler service. Sometimes you just want to dump a file somewhere and retrieve it.
This looks to me like it could grow into the sqlite of the filestorage world, where Dropbox is probably the MySQL. It looks slightly rough around the edges, but very promising, and I will be watching development with great interest.
I appreciate that you're trying to save some kind of longer-term pain and to encourage loss-cutting, but I think the tradeoff of the damage you can do with a two sentence comment that takes a couple of seconds to fire off vs the hundreds of hours that went into creating something like this, far outweighs the potential benefit (though it seems the creator took it graciously).
To me it seems like a "benefit of the doubt" applies here. The creator obviously saw a need and tried to fill it. As someone who has spent hundreds of hours dealing with Dropbox and S3 APIs, I believe there definitely is room for a far simpler service. Sometimes you just want to dump a file somewhere and retrieve it.
This looks to me like it could grow into the sqlite of the filestorage world, where Dropbox is probably the MySQL. It looks slightly rough around the edges, but very promising, and I will be watching development with great interest.
Benefit of the doubt is not a good heuristic for evaluating whether a business venture is a good idea.
I appreciate your candor exactly for the reason you stated. I need to know whether to spend more time on it, or move on to something else.
I'm not quite sure how to analyze the results as a whole though.
I'm not quite sure how to analyze the results as a whole though.
To clarify: keep generating landing pages and MVPs. You will likely find a more promising MVP.
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.
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.
Exactly what I was going to say, great thoughts. It's a challenge, but keep it up OP!
Seems like a nice idea, it’s not obvious to me why an IT team would need this over any other flavor of cloud storage available currently. Do you have a first customer that you built this for? How do they use it?
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.
There is also a built in file conversion.
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.
There is also a built in file conversion.
I don't mean to be harsh, but the number one feature you just described to differentiate your product from existing offerings... doesn't exist yet? I really don't see how your product is any better than the multitude of other storage options that already exist, and on top of that your pricing is super steep (comparatively).
>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.
azure has secondary region built into their blob solution, which is essentially what you're describing. and considering your site has a bunch of moving parts (multi-cloud, file conversion, search, etc.), I'm not really convinced that you'll be more reliable than the cloud provider. in other words, you'll be the cause of downtime more often than s3 failing.
>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.
aws/azure iam handles this.
>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.
but there are many storage appliances (what you're essentially describing) out there, including open source ones like owncloud. what makes yours stand out?
azure has secondary region built into their blob solution, which is essentially what you're describing. and considering your site has a bunch of moving parts (multi-cloud, file conversion, search, etc.), I'm not really convinced that you'll be more reliable than the cloud provider. in other words, you'll be the cause of downtime more often than s3 failing.
>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.
aws/azure iam handles this.
>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.
but there are many storage appliances (what you're essentially describing) out there, including open source ones like owncloud. what makes yours stand out?
> azure has secondary region built into their blob solution, which is essentially what you're describing
How does Azure's secondary region capability provide cloud vendor redundancy?
How does Azure's secondary region capability provide cloud vendor redundancy?
It doesn't. But I don't think that's an issue considering providers wide outages are exceedingly rare. Even last year's massive AWS outage was isolated to us-east-1.
A providers outage can also be named a price hike, a change in license or a security breach. In that case you might want your data out of the provider asap.
Its a nice feature but not relevant enough.
My experience is, that a company who decides to use AWS (or whatever) only decided to use one specific vendor and would need to reevaluate every other vendor the same way.
If you can't trust AWS enough, i wouldn't use AWS.
My experience is, that a company who decides to use AWS (or whatever) only decided to use one specific vendor and would need to reevaluate every other vendor the same way.
If you can't trust AWS enough, i wouldn't use AWS.
if the software is cloud agnostic, wouldn't a simple copy operation between the cloud providers suffice?
>security breach
if you want to reduce your attack surface, copying your data across multiple providers is counter-productive. instead of having to hack your specific cloud provider, the attacker only needs to hack one of many cloud providers.
>security breach
if you want to reduce your attack surface, copying your data across multiple providers is counter-productive. instead of having to hack your specific cloud provider, the attacker only needs to hack one of many cloud providers.
In some cases a copy might not be viable, especially with price hikes. If AWS increased storage and outgoing data costs greatly then exporting all your data will most likely cause a much larger bill.
Splitting your data across multiple vendors protects against all kinds of failures from all sides (including the vendor simply closing your account for no reason)
Splitting your data across multiple vendors protects against all kinds of failures from all sides (including the vendor simply closing your account for no reason)
While true, but the UI for these is pretty bad afaik.
There is value in improving the UI for less experienced devs / non technical users.
Might be worth exploring other markets?
There is value in improving the UI for less experienced devs / non technical users.
Might be worth exploring other markets?
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.
Congratulations on the launch. Some constructive criticism. Give your website some design love. It doesn't look like a company website. It looks like a side project right now. If I came across this site on my own I wouldn't even think about entering my credit card info.
I hope this doesn't come across as too harsh. I sincerely wish you the best!
I hope this doesn't come across as too harsh. I sincerely wish you the best!
If you can build a dataroom product for startup founders to run fundraising ( https://blog.ycombinator.com/process-and-leverage-in-fundrai... ) similar to https://www.box.com/business/virtual-data-room/, that would be cool.
A data room for fundraising with an API, GDPR, etc
A data room for fundraising with an API, GDPR, etc
I'm not in our target customer audience but here is my take:
1. You should probably work on the landing page and try to make it look like an enterprise product.
2. Your target audience is obviously enterprise companies so you should probably need outbound sales strategies unless you open-source the app and spend at least two years for visibility.
3. The main problem is that your target audience probably has enough resources to build their own solution and if the privacy is important for them, they probably won't be willing to try out your service. You need to do a market research and maybe build an on-prem version of the app.
4. You should probably spend some time to find the best value proposition for your product. Here are a few ideas that can help you to find it:
* Make it so simple for the companies can integrate it easily within hours. You should probably make the system pluggable so that they can integrate their internal services easily and switch to cloud if they want.
* Give away some free carrots to them in order to attract the potential customers. (Maybe open-source?)
* Do some paid POC and work as a consulting company. If you get closer to your customers, it can help you to find out the actual problem and turn your company into a product company. (i.e. Do Things that Don't Scale)
1. You should probably work on the landing page and try to make it look like an enterprise product.
2. Your target audience is obviously enterprise companies so you should probably need outbound sales strategies unless you open-source the app and spend at least two years for visibility.
3. The main problem is that your target audience probably has enough resources to build their own solution and if the privacy is important for them, they probably won't be willing to try out your service. You need to do a market research and maybe build an on-prem version of the app.
4. You should probably spend some time to find the best value proposition for your product. Here are a few ideas that can help you to find it:
* Make it so simple for the companies can integrate it easily within hours. You should probably make the system pluggable so that they can integrate their internal services easily and switch to cloud if they want.
* Give away some free carrots to them in order to attract the potential customers. (Maybe open-source?)
* Do some paid POC and work as a consulting company. If you get closer to your customers, it can help you to find out the actual problem and turn your company into a product company. (i.e. Do Things that Don't Scale)
> you can reference the endpoints directly in your HTML, so <img src="https://bitbox.co/files/1.png">
> There is also a built in file conversion.
How do these work in conjunction with each other? Could I just request https://bitbox.co/files/1.jpg?
![https://bitbox.co/files/1.png">](https://bitbox.co/files/1.png">){kind=link}
How do these work in conjunction with each other? Could I just request https://bitbox.co/files/1.jpg?
Yes.
So is it like S3/Object storage with a convenience layer on top?
If you're targeting IT departments, I'd look into :
-Integrating with directories (AD / LDAP / ...)
-Search feature (ELK? Algolia?)
-Integrating with mail platforms (the on premise ones for example)
-Backup solutions
As others have stated, I don't think what you provide is the best fit for your target.
So instead you should probably look at what problems those guys have and the list above is merely a guess as to what keeps this might be for your average IT team.
Also, while you're trying to get the IT teams to want your product, it's ultimately the execs which will have to sign on that, so you should make sure you convey business value to those guys. Because right now, it's not obvious.
Hope this helps.
If you're targeting IT departments, I'd look into :
-Integrating with directories (AD / LDAP / ...)
-Search feature (ELK? Algolia?)
-Integrating with mail platforms (the on premise ones for example)
-Backup solutions
As others have stated, I don't think what you provide is the best fit for your target.
So instead you should probably look at what problems those guys have and the list above is merely a guess as to what keeps this might be for your average IT team.
Also, while you're trying to get the IT teams to want your product, it's ultimately the execs which will have to sign on that, so you should make sure you convey business value to those guys. Because right now, it's not obvious.
Hope this helps.
Sounds really cool. Does it support remoteStorage? [0]
[0]: https://tools.ietf.org/html/draft-dejong-remotestorage-09
[0]: https://tools.ietf.org/html/draft-dejong-remotestorage-09
Not currently, but it will definitely go on the future feature list. Thanks for the tip.
What's the benefit over using something like s3 or Blob Storage directly? It seems like they all support your features in some way
On your main page there is no info about any clients.
Not sure why i should use your service over one of the following:
- Office 365 Sharepoint or OneDrive - Dropbox - Box - Google Drive
In my previous company, we used box. One of the biggest issues was the client. For cases like images for a website or other stuff, we used S3 directly.
I personaly wouldn't use it in my it department. i would use nextcloud or one named above.
Not sure why i should use your service over one of the following:
- Office 365 Sharepoint or OneDrive - Dropbox - Box - Google Drive
In my previous company, we used box. One of the biggest issues was the client. For cases like images for a website or other stuff, we used S3 directly.
I personaly wouldn't use it in my it department. i would use nextcloud or one named above.
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">
S3 has an api and there are libraries out there how to use it. It has access policys, access tokens with different permission level. Everything you have but better.
Now what you don't have, is a client software which allows any employee to use your storage system easy.
Only a WebAPI is not enough. I would even prefer any S3 open source self hosting solution over your solution and put a backup strategy behind it.
Now what you don't have, is a client software which allows any employee to use your storage system easy.
Only a WebAPI is not enough. I would even prefer any S3 open source self hosting solution over your solution and put a backup strategy behind it.
I could run some IPFS nodes giving me 1TB of storage for $10/month per node. There's no scale here and you could easily DIY more storage for far less cost. Look at online.net or scaleway or ovh if you want to roll your own easily.
I would open up your search to different markets.
You have a significant body of work that solves a problem you perceive.
I'm not sure that the people you think will value it are the people who value it.
Why did you have to build one at your previous companies? Who drove that decision?
You have a significant body of work that solves a problem you perceive.
I'm not sure that the people you think will value it are the people who value it.
Why did you have to build one at your previous companies? Who drove that decision?
>Who drove that decision?
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.
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.
I understand "why" it's valuable. I meant who in the company!
That would give you persona to look for when marketing / reaching out.
That would give you persona to look for when marketing / reaching out.
I'd like to have an aws glacier backup tool. I'd expect it to be open source, and be simple enough to read over. If it encrypts and decrypts documents too that's a plus
Change the Subject to Show HN , might get more attention.
Good Luck!
Done. Thanks for the tip.
Looks interesting! One thing, why do I keep seeing mention of WebAPI and not just simply API?
Looks good, but put some work on the marketing side.
Currently not many cloud storage systems support cryptocurrencies. Might be an easy way to win more customers.
Seafile accepted Bitcoins, not sure if they still do. https://bravenewcoin.com/news/seafile-accepts-bitcoin-after-...
Seafile.de doesn't even work.
The company split, I think the German entity no longer exists. Seafile can now be found at: https://seafile.com
The German entity is now https://syncwerk.com/
This is an MVP and it's simple. Upload a file, get a token; like a valet or coat check. When you want that file back, send the token and you get a byte stream. There is also a built in file converter, so you can can upload a docx file and retrieve it as a pdf by appending .pdf to the URL, for example: https://www.bitbox.co/files/1.pdf, or perhaps a tiff: https://www.bitbox.co/files/1.tif. Files can be marked as public or private, and account owners can invite other users to join their team with read, write or admin privileges.
There are some directions I want to possibly go:
This was designed for IT departments without a strong development team to save money. Does anyone have a need for something like this?
www.bitbox.co