Our market research work concluded that we should focus on the following verticals:
We will develop one use case per vertical, and work with three customers for every use case in order to quickly build success stories. Candidate use cases have been identified for Retail and Higher Education. We need a bit more work for the other three. Stay tuned…
Over the past couple of weeks, we’ve had quite a few discussions regarding our pricing model. Quite frankly, this has to be the most challenging thing for any platform vendor, and everybody in this business is struggling with this very issue, one way or another. Here are the things that a proper pricing model must achieve:
While this equation might seem unsolvable at first, there are ways to reduce the basic set of constraints and come up with a solution that should work pretty well for all parties involved, namely end-users, third-party developers, and platform vendor (STOIC).
First, we make a distinction between power users and regular users. We define a power user as one who has an account on the Google Apps instance on top of which STOIC is deployed, and a regular user as one who does not. Power users are authenticated using Google’s OAuth 2.0 API, while regular users are authenticated using our own OAuth 2.0 service. Power users have access to our advanced user interface, while regular users have access to widgets only.
Second, we recognize the fact that ultimately, the best business model is the one pioneered by Apple for the App Store. In essence, it lets third-party developers the freedom to define how their applications should be priced (from free to outrageously expensive), and we simply take a cut of the action (most likely a lot less than what Apple takes).
Third, we add a utility pricing to the mix in order to prevent abuse and guarantee that the infrastructure can pay for itself, even when applications are distributed for free. Something similar to the transaction-based pricing model used by Parse.com is a good starting point.
As a result, here is what our pricing could look like:
Of course, these are very preliminar ideas, and everything is subject to change without prior notice. But directionally speaking, I think we found a model that could address most of the constraints we set initially, and most of the feedbacks we received so far from early adopters.
Over the past few weeks, we’ve been working with our lawyers to define our long-term strategy regarding intellectual property. It’s a fascinating topic, but a rather complex one, especially when you consider the inter-relationships between the common types of intellectual property rights, including copyrights, trademarks, licenses, patents, design patents, and trade secrets. Let me cover them one by one, while outlining some of the most critical inter-relationships among them. And keep in mind that I am not a lawyer (unlike my brother), and that we’re working with three different law firms to put all this together…
Copyrights
This is by far the easiest part. By default, everything we produce is automatically copyrighted. Adding the © symbol on every piece of content that we create certainly does not hurt, and we’re likely to register our work once or twice a year just to be safe. Beyond that, we will start licensing some parts of our work using Creative Common Licenses, but we need to become a bit more familiar with them first.
Trademarks
Now that we’ve acquired the stoic.com domain name, we’re in the process of shifting our brand from Sutoiku to STOIC. First, we’ve started the registration process for the STOIC trademark. Second, we’ve registered a few additional domain names (stoic.cc, stoic.io), and we might register a few more down the road. Third, we will eventually rename our company from Sutoiku, Inc. to STOIC, Inc. or STOIC Corp. We might also apply for a trademark in relation to the simplify™ campaign. Finally, we will try to rationalize our handles on various social networks such as Facebook (stoic.io) or Twitter (@wearestoic), but things there are a lot less straightforward unfortunately.
Licenses
By default, our software will be licensed through a traditional end-user license agreement (EULA) and our online services offered through conventional terms of service. But we’ve also started a few open source projects. These are licensed under the MIT License, because it’s one of the simplest and most liberal. It’s also the most popular license within the JavaScript community (Cf. Community ethos). And as you would expect, we’re using quite a few pieces of open source software to develop our own product (Cf. Foundations), but only software licensed under liberal (non-viral) licenses such as Apache, BSD, or MIT. Granted, we could use the GPL License and a dual-licensing strategy made possible by the inter-relations that exist between copyrights on one hand and licenses on the other (ask Maureen at Paradigm Counsel for the English translation), but we’d rather keep things simple…
Patents
For a software company, patents are always a rather tricky subject, and we’re not exempt from it. On that front, we’re likely to apply for a few patents covering very specific aspects of our work, but none that would even remotely relate to our open source projects. What’s a bit challenging for us is that many of the ideas that we’re implementing at STOIC are the direct result of interactions with our community, especially on this blog. As a result, we need to be very careful to not talk or write about anything that we might want to patent at some point. Since we don’t have a lot of experience in this area, we will apply for a couple of utility patents for the ideas that we feel are truly novel, and use provisional applications for everything else. This should save us quite a bit of time and money.
Design Patents
Design patents are a type of industrial design right. We might apply for some in order to protect our logo, user interface, and icons, but they have a much lower priority on our list, mostly because our designs are very likely to change quite often, especially in the early stages of development.
Trade Secrets
Like any company, we have trade secrets that need to be protected, and we do that mostly through the use of solid employment contracts and secure communication tools. For the latter, we mostly rely on Google Apps, with the acknowledgement that Google has considerably better and larger resources than us that can be deployed on the IT security front. That being said, trade secrets are not very important for us, especially considering our open kitchen culture. It’s not something that our lawyers are super excited about, but they’re being paid to worry about this kind of things. We’re not. Or to be more precise, we’re being paid to break as many rules as possible, so that we can out-innovate and out-execute our competition. Game on!
Our recent roadshow in Asia gave us plenty of opportunities to refine our go-to-market strategy. Ultimately, our product can appeal to any business user interested in developing a custom application for the cloud. But we can’t really target such a broad and ill-defined audience. Instead, we must identify smaller market opportunities and develop complete solutions for them, one after the other, in a very incremental fashion.
Initially, we’ve decided to focus on small to mid-size Independent Software Vendors (ISVs) that have an existing application in need of an upgrade to the cloud. Typically, the application is designed for a particular vertical industry, and is distributed within a limited geography. It was originally designed for the web (or migrated from a client-server legacy), never architected for multi-tenancy, and does not provide proper support for mobile interfaces. And now time has come to migrate this application to the cloud, with an existing development team, very limited R&D investments, and no disruption to the existing customer base.
For this particular market, Sutoiku will provide a platform that enables the rapid migration of an existing application to a cloud environment, for a fraction of the time and cost required with any other tool we know. We will also provide some professional services to help with the migration, both in terms of strategic consulting (how to sell an application in the cloud), architecture design (how to design an application for the cloud), and technical implementation (how to migrate). These services will be delivered by a group of consultants based in California and Singapore, as well as software engineers based in China. We will initially focus our sales and marketing efforts toward customers based in Silicon Valley, then extend our footprint based on market demand.
Later on, we’re likely to push our platform through specific applications, either targeted at specific vertical industries, or focused on particular business processes. While it’s too early to tell which applications will have the most traction, a few are interesting to us, for various reasons.
From a vertical standpoint, we’ve been giving very serious thoughts to the development of a fund management application targeted at the private equity market, especially venture capital firms. This application would be used by partners, analysts, and other staff members in a VC firm to automate the process of raising a fund, developing a deal pipeline, closing deals, making capital calls, and generating annual reports. We like this application because of its high level of value added (translation: you can sell it for a lot more than $20/user/month), and because we have so many prospects in our backyard (think Sand Hill Road).
From an horizontal standpoint, activity management (Events, Projects, Tasks) will be our first attempt, with what we call Sutoiku Activities. Here, we’re interested in promoting an application that everybody needs (I have yet to meet someone who found the perfect task manager) and that can support the development of many vertical or horizontal applications on top of it. Essentially, Sutoiku Activities will be the mother of all templates, and should teach us a ton of things about what can be done to facilitate the adoption of a new development tool.
Beyond these first two applications, we will gather as much user feedback as possible on this blog, prioritize inbound requests using a tool like Get Satisfaction, and fund development through dedicated Kickstarter campaigns. These are our three steps to the epiphany (three, not four).
One former business partner I worked with for far too long kept telling me about the four steps to the epiphany. I never followed his advice, but I now realize that I made a mistake, and I won’t make the same mistake twice.
For us to be successful, we must listen to the market carefully.
Sutoiku is a platform for building cloud applications. It’s as easy to use as a spreadsheet, yet as powerful as the core technologies it is built upon (Node.js, Big Data). As such, it can be used by three types of organizations:
We believe that we have a fairly decent understanding of what the first two need, and why they will love what we’re building. But the third one are more of a mystery to us, therefore we need to talk to as many of them as possible.
More specifically, we’re targeting small to midsize software vendors developing applications that are sold to business users and delivered over the cloud. We’re especially interested in companies that would like to use platforms such as Force.com or QuickBase, but cannot for a variety of reasons (pricing model, deployment model, scalability, etc.).
If you’re working for such a company and recognize your firm in this profile, please give us a buzz. We’re not trying to sell anything at this point. All we care about is to learn more about the challenges that you’re facing, so that we could develop a better understanding of what the market really needs.
This will take us a step closer to the epiphany.
Yesterday, we had lunch with a potential partner for our company. While we could not share very much information with him, we managed to validate most of our assumptions through specific questions. Unfortunately for our partner, that must have been a very frustrating meeting. But for us, it gave us all the answers we needed. At the very least, we picked up the lunch tab. Note to partner: we’ll make it up to you as soon as we go live!
One of the challenges faced by self-funded software companies is to find ways to fund product development through custom projects developed for customers. More often than not, what the customer needs is not exactly aligned with the product’s roadmap, and leveraging custom developments becomes difficult, if not impossible. We’re acutely aware of that risk, and we only take on projects that we believe can be leveraged to a very large extent. We also structure our deals so that Intellectual Property can be shared across both parties, either through cross licensing arrangements, or by using open source licenses (MIT preferably). Our first customer project follows that pattern, and a week into it, we’re starting to have a pretty good idea of how we will integrate its output into our product. This should give us a couple of really nice features that we could not have afforded to develop on our own before quite a while. And the next project that we’re negotiating right now should be even better, but that’s for later posts.
When creating a new business, following these simple rules might help:
For someone with a Type A personality (I would fall into that bucket), constraints can be viewed as a negative, an impediment, something to avoid, at all costs. But that would be a mistake, for constraints can foster creativity.
It’s only within the bounds of constraints (external or self-imposed) that one can come up with truly original solutions. Therefore, one should embrace constraints rather than fighting them.
In our case, constraints are many:
On one hand, these constraints are dramatically reducing our set of options. On the other hand, they are forcing us to come up with far better solutions. For example, our office is so small that we have no place to store printed documents, therefore we went 100% paperless. Another example is that because we have so few engineers, we could not afford to develop our own User Interface. As a result, we went headless and stumbled upon a great way to bring our product to market.
Innovation comes from unexpected places. Constraints are great shortcuts.
Sutoiku will remain in semi stealth mode for a while, therefore we do not need a logo yet. This will allow us to develop our unique culture over a few months, then design a logo that can best depict what we’ve created. Beside, we can’t afford a good logo design yet.
As mentioned on this presentation, user-centricity should be our very first design principle. It was reminded to us by one of our Board Members during our Founders Meeting (meeting at which all founders met for the first time). We have been thinking about this concept since then.
Usually, software companies tend to position their product at the center of their targeted user’s universe, unless they’re deliberately developing a plug-in to an existing application. Unfortunately, most users don’t see it that way. In reality, users tend to spend a majority of their time with a few applications, and consider everything else as an add-on. This reality should be embraced rather than ignored or resisted.
In such a context, when designing our user interface, we asked ourselves the following question: “What is the primary application of our targeted users?” Then, we wondered whether our user interface should look anything like this primary application, or whether it should look completely different.
After failing to answer this difficult question for a while, we changed our vantage point and asked the real question that we should have been asking ourselves from the very beginning, which is: “Do we really need a user interface at all?” This question was immediately followed by yet another: “Could we use this primary application as our user interface instead?”
An affirmative answer to the later made everything clear.
We call this user interface virtualization.
