Do you have any examples?

Build a simulation(in some multiphysics simulation tool) that shows your concept may work and can be validated by a 3rd party.

That not a great example. A better one is to build a v0.00000001 that actually works but is obviously not the final product nor even an MVP. E.g. a technical demonstration of some component.

Can you get more concrete? "a technical demonstration of some component" isn't really an example.

My point is, a simulation is not going to impress anyone.

There was a book written to answer this exact question by psychologist Mihaly Csikszentmihalyi. It's titled "Flow: The Psychology of Optimal Experience"

Excellent, just bought it on my kindle. Thanks for the reference.

How much do you have in savings? 5 figures, 6 figures?

There are additional risks with hiring more people... you need to find stuff for them to do, and you end up building things that aren't valuable. At worst, you make the product worse. Once you've found the main valuable idea that'll get you most of the value.

Don't businesses use wikis?

The user interfaces on most wikis I've seen (including Wikipedia) are not really usable by casual non-technical users. Thus, wikis, if used in businesses, tend to be in places like software development groups, and those groups can easily set up their own wiki if they want one - there are dozens of free, open source wikis to choose from. (I set one up on my machine at work.)

At my company, the non-developers use software like Microsoft SharePoint rather than wikis.

Still, there are already a whole bunch of hosted wiki services. You can find a list on Wikipedia:

https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_ser...

So you'd be competing with these established companies.

There's also Confluence (https://www.atlassian.com/software/confluence).

For me, I need either socket support or go support.

Go support? You can run binaries on lambda, as long as they're small enough.

http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/

I would argue they were not moving slowly, but in the wrong direction.

Yes and you could almost say Myspace moved too fast, chased after local maxima (rapid A/B testing) and pursued vanity metrics (registered users). In contrast, Facebook stepped back enough to have a real vision, and carefully chose the right metric (active users). DAU and MAU are industry standards today, but back then it was a bold and careful decision by Facebook.

What's DAU and MAU?

Daily / Monthly Active Users.

Friendster absolutely was a victim of unfixed performance problems.

As users are editing a doc, do you send diffs? What diff algorithm do you use? What's your logic like for merging changes and handling conflicts?

Our documents are broken into lots of smaller components we call sections. So, in a billeted lost, each list item is its own section.

Sections have a GUID and can be modified without touching any of the other parts of the document. This is useful in that it minimizes most common merge conflicts - they only happen of people edit the same sentence or spreadsheet cell while offline, but simultaneous edits of the same doc generally don't result in the need for any merge algorithm.

For offline edits of the same section, we use a fairly standard three way merge algorithm. Then, we show the edits we chose in the left hand side of the doc with the conversation along with a "Revert" button so you (the end user) can revert if our algorithm was wrong.