(public).sospep.systems ~ view step ~ 018-product

<h1 style="text-align: center;">STEP - 018</h1>
<ol>
<li><strong>] ANSWER: </strong></li>
<ol>
<li>] a defensibibility strategy? - at this point, we don't really have a formal&nbsp;one per se,</li>
<li>] for small teams - to copy sospep - There are a lot of moving pieces - its a not a single app with a single purpose, its multiple apps with multiple uses, that are designed to work together.</li>
<li>] for big teams - to copy - Design by committee would problematic, there are a lot of decisions to be made, which could get problematic quickly&nbsp;with many stakeholders.&nbsp;Either way, not saying it couldn't be done, I don't think it would be easy/trivial to do so and&nbsp;until someone prooves the market -&nbsp;I don't see any&nbsp;teams too interested in trying&nbsp;... once we have, we&nbsp;can strategize more on that.</li>
<li>] for customers - to keep them from leaving - we want to avoid any type of proprietary "lock in", we want to make it as easy as possible to not only put your data into sospep, but to get your data back out of it. Maybe it's <strong>naive to think</strong> that this&nbsp;would be a "selling" feature to end users, apple is obviously a great example of where lock in works but in todays market for a newcomer to engineer it into&nbsp;a product&nbsp;like this, not so much.</li>
<li>] of course, IMO, before anyone is going to invest in&nbsp;knocking&nbsp;sospep off, someone has to proove that it's a viable product/business model to begin with and that's where&nbsp;my focus is now.</li>
</ol></ol>

~ view step ~ Procedure] 001-application-questions-ycombinator FROM [ App] project-accelorator-application IN [ servers] prj-022-sospep