Other folks have provided a bunch of commentary on the validity of your idea, so I won't address that.
BUT: if this is a good idea, your pricing is far too low for a niche product like this. $10 (or 10 quid) is too low a monthly fee for pretty much any product marketed as a business product. 10 per seat per month is probably also too low, but would be a better starting point.
Likely objection: "But Spotify is only $10/mo!!!" Spotify has the much larger addressable market of people with hearing and an Internet connection. Even Dropbox has a higher price point for business users, and it also has a far larger addressable market.
If you're building something that's useful for people, charge more.
The Black Art of SaaS Pricing: https://training.kalzumeus.com/newsletters/archive/saas_pric...
Doubling Saas Revenue by Changing the Pricing Model: http://www.kalzumeus.com/2012/08/13/doubling-saas-revenue/
Selling To The Fortune 500, Government, And Other Lovecraftian Horrors: https://training.kalzumeus.com/newsletters/archive/enterpris...
Patrick's default pricing model:
And you don't want to lock too many customers into low pricing early on - it's a real challenge to start charging customers more when they're used to paying a ridiculously low rate.
It's hard enough to train people to use existing baseline document management systems and not simply email these things around.
Also, the fact that you need to use your cloud service is a red-flag for certain clients.
1. You have a fantastic product
2. Many potential users won't accept to have their documents stored "in the cloud" (even though those same users share those same documents by email with zero security, all the time)
3. Offer a stand alone version and sell a licence (or a rent, think the former Google Search Appliance)
4. Charge an arm and a leg for it -- think Oracle pricing
5. Get rich!
Have you tried to use Word's features as part of a mid-size team to manage a complicated document being edited by multiple users? Word's merge is crap.
My old law firm used version control software that appeared to be straight from 1991. So there's plenty of room to solve real problems here.
OP, I wish you the best of luck. But I concur with others, the use case for this product I see is for a team or company to learn to use it internally, not for a bunch of lawyers to use it across firms. So, keep the free tier to attract people who are willing to use it on their own (or in case someone can convince those outside their organization to sign up in order to participate on projects), and then increase pricing to any sort of team.
Also, I'm sure my firm could never have used a cloud-based solution, regardless of security, because we probably had clients who would not allow their information to be stored in the cloud.
Also, because I can speak to lawyers, the diffing needs to be excellent and it needs to be easy to create and share redlines in the ways lawyers are used to (send as a word doc/PDF, etc.). Perhaps this is already there, I'm excited to check it out.
I work in legal and compliance technology, and it is very important to keep documents secured internally if the have confidential information.
Make this a standalone product and it's a no-brainer that can command an enterprise price point.
Here's my unsolicited opinion: you preemptively answer "why wouldn't I just use git?" but I think "why is this better than track changes?" is the question prospective users are more likely to have. Comparisons to SharePoint versioning might also be helpful.
If you save your LibreOffice documents in flat XML format, (e.g. fods, fodt instead of ods, odt), placing them under version control becomes slightly less annoying — the diffs become at least _potentially_ human readable.
 It has to be a word document for integration with tooling that does stuff like generating tables of authorities and whatnot.
Most law firms (and I would guess all major ones) will not allow uploading of client documents or work-product to any cloud provider, let alone an unproven start up. This risk is frankly way too high.
The only way I see this happening in the legal context is if it can be run from the firm's servers with all data hosted locally.
You're right with respect to internal memos, notes, drafts of pleadings, etc. But I suspect this is changing too as more lawyers want to be able to work on docs from their phones and iPads and remote laptops.
- unzip the .docx file into xml files
- parse the xml into something organizable by line (csv? etc)
- commit this other file format
- in the GUI of your app, when someone selects a snapshot in
time, go from the by line (csv? etc) format back to .docx
- open in word
(way back when we did this with excel, but ultimately gave up https://github.com/decisive-wizard/GridHub)
I'd like to have the option of Word documents in Git but I don't want a whole other system just for the special snowflake that is Word as I'm already using Git for managing LaTeX documents and doing that entirely on my own infra.
If you do use it, feedback is always appreciated (I'm one of the Overleaf founders), thanks.
I'm asking honestly as someone who was in this space several years ago, I'm not convinced that even if it was backed to git that would be a big enough lure to make people want to use it.
Please feel free to convince me I'm wrong :)...
Also when collaborating for writing a paper with Word, version control can be a huge help.
As much as I hate having to work in Word for small things that could so easily be a plain-text format, the versioning system within Word isn't exactly the worst thing ever.
Most engineering firms (web dev << the development world) have a need for proper documentation, and LibreOffice generally won't cut it either.
So not so few people :-)
I like the idea, let's see how it plays out.
The main limitation with Git is that it only works with
plain text (think Windows Notepad). I have seen authors
resort to plain text or markdown in order to take
advantage of Git, but this means losing all of your rich
formatting such as images and fonts. This is usually too
much of a sacrifice for companies as formatting needs to
be reapplied with each publication, which is very
time-consuming and prone to errors.
For plain text, sure, for markdown, nope.
Sure, but formatting can be applied after. With markdown, it supports HTML so you could event apply custom formatting inline, if you really wanted to do something so dirty.
"This is usually too much of a sacrifice for companies as formatting needs to be reapplied with each publication, which is very time-consuming and prone to errors."
Why not solve this problem? Why not make markdown more accessible to those wanting to use Word? Make something that looks like word, but in reality takes markdown and renders it using some flexible settings file?
I personally quite like markdown, to me it represents a minimal, future proof language. I would actually change a few things about markdown to make it more useful in an academic setting. Issues for me are referencing structure, diagrams, embedding content (at the position) and plots. Those things fixed, I would never look back at LaTeX or Word again.
One thing I would like to see remain, is the plain-text readability and being able to process it line-by-line without having to remember anything about the previous line.
Good luck with this venture, but if you're wanting to take a pivot, let me know :)
Anything other than Word is a non-starter for 99% of law firms (and the other 1% is still on WordPerfect). Markdown is awesome and I use it for my notes files and all kinds of things but contracts, settlement docs, pleadings, motions, etc etc all exist strictly and only in Word. And probably 50% of those are still .doc format, which was left behind more than a decade ago in Word 2007.
This product, if it works, will be a God-send for firms like mine (small to medium litigation shops that don't use full document assembly software with built-in version control like the AmLaw 100 firms. And it looks like even those firms might profit from this solution if it plays well with their customer style sheets and macros.
I wish it were different, but sadly the state of legal tech is mired in the late '90s.
But the VC tends to be centralised, rather than distributed. I've often hankered after a more git-like experience when working remotely or offline, and I will follow this project with interest.
One area that is underserved at the moment is diffing .ppt files. Since a lot of the tax industry in particular uses PowerPoint for step plans and structure papers (because it is generally easier to build structure charts). Whilst it isn't the right tool for the job, for as long as people continue to use it, getting this working on your app would be huge.
I agree the developer needs to take a look at these if he/she has not already but there's plenty of room to improve on those products; I don't think the existence of some mediocre solutions should put the developer off.
There's a real market here. Word is huge, and people aren't gonna give it up. This looks to be a good technical solution. Trying to move people from word to markdown is an ok ideal, but not a practical business move.
My advice to the creator, ignore bArray's advice.
I'm coming at this exact problem from the opposite direction, making a Markdown-based static-publishing CMS intended for corporate use (aimed at official documentation, standard operating procedures, handbooks, etc) and weening people who are used to it away from Word is the most difficult part of the entire process.
On the other hand, Word falls short when it comes to a large number of related documents, with inconsistent styling, flakey 'hyperlinks', ridiculous attachments and lack of good version control (something Simul appears to be tackling).
There's plenty of room for innovation in this area and props to the OP for actually tackling the harder challenge head on. My fear in trying to sell this to businesses would be that letting their confidential docs leave their network is going to be a hurdle. A self-hosted version would definitely be onto a winner, and anything that's not Sharepoint is a good thing.
I'm sure lots of people will happily throw money at you for this!
Most of the damage done by not enforcing anti-monoploy laws is entirely invisible, the dogs that don't ever get a chance to bark.
It also means that when someone checks a file out and then goes home for the weekend without checking it back in no one can update the file in the DMS without administrator support.
I can't imagine lawyers will be queuing up to host their sensitive legal documents on someone else's server.
Thus, I'd remove pretty much all mention of Git from your project landing page (except perhaps to say that it was inspired by its success in the programming world to manage a similar need) so as not to scare off your likely target market (lawyers... who are ALSO notoriously Luddite!)
I'm fairly convinced that Google doesn't really give a shit about their apps suite. The apps have barely changed in years.
There is a lot of overlap here with the authoring process of a Word document. You don’t necessarily want the real-time coauthoring experience offered by Microsoft SharePoint or Google Docs., this can inhibit your ability to determine who is responsible for specific changes to content. Branching offers a much clearer audit trail of changes. Like with code, tags can be added to signify a minor or major version of a document is ready to be published.
...but people here irrationally hate svn, so you're getting unfairly downvoted.
My two cents: Congratulations on launching your product! There simply is no real good versioning system for Office files, so this is a step in a good direction.
I agree with others that ditching all the "Git" references would be beneficial, because your target market most likely doesn't care about Git. What is missing in the versioning market is exactly what you may provide: A clear way to see what has changed where and an easy way to merge things together.
I do believe that you are missing a valid comparison / valid take on what Office 365 / SharePoint Online / OneDrive versioning can give you. Your main argument against it is "necessarily want the real-time coauthoring experience offered by Microsoft SharePoint or Google Docs., this can inhibit your ability to determine who is responsible for specific changes to content". Comparing Co-Authoring to versioning is comparing apples and oranges.
The co-authoring experience in Microsoft products is great! I can work on a document with multiple people at the same time and I can even see in real-time what part of the document they are working on and what they are changing. We're working with multiple people on important documents simultaneously very often and this is a life saver.
Versioning of course could be better: SharePoint only offers you a main branch and no tags. That means I can go back to a different version, also compare that version to my current version or any other version (!) - but I don't have tags or a method to know that "version 12.0 from 07:02" was the version I was looking for. However the versioning system is very robust and proven. With products such as OneDrive / OneDrive for Business or Office 365 I have said versioning out of the box plus 100 other features. I don't know whether your versioning would make me want to switch just for the additions you show.
What I can't see in your demo (and can't test myself) is how you handle complex changes and this is where the meat is. Changing fox to wolf... yeah... I have documents where all heading format changes from Arial to Times New Roman and the bullet points are arrows now instead of bullets. Also my colleague has added three images and right aligned two of my images, oh yeah and applied some pretty image borders around some images. Would all of that show in the "what has changed" view of Simul? It would show when using SharePoint versioning together with Word. Granted: I can't see all these changes in SharePoint - but Word does show everything perfectly.
Again: Love the way you are going with this. The existing versioning could be made better, but besides branches and tagging I don't see any benefit compared to regular versioning using Microsoft products.