My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.

Trojan Horse Strategy

Platforms are notoriously difficult to sell, because customers do not need tools, they need solutions to their problems. And they have no way of knowing in advance that a particular tool could be used to develop working solutions to these problems. That’s the reason why you always want to sell a platform by disguising it as an application.

Unfortunately, finding the “killer application” can quickly turn into a wild-goose chase. If you’re lucky enough, you might stumble upon one (eg. CRM for, but if you pick the wrong one, you’ll never be able to develop a real platform business out of it. Platforms are tough.

That being said, platforms are irresistibly attractive, because when you manage to build one, you’re sitting on a gold mine. Fortunately, there is an alternative path for selling a platform through an application. Instead of focusing on a single killer application, you can focus on a killer application delivery model. This is what John J. Donovan managed to do extremely well at Cambridge Technology Partners when he and is team “pioneered fixed time/fixed price consulting services and RAD Methodology, helping clients transform from mainframe-centric solutions to client-server architecture and packaged solutions.” (Source: Wikipedia)

John’s strategy was made possible because the industry was undergoing a tectonic shift, moving from mainframe to client-server. A similar strategy could be applied today thanks to the cloud computing revolution. And this strategy is what we’re going after with our Fast Track Package. But we can’t stop there, because unlike John, we’re not trying to build a consulting business. Instead, we’re building a platform business, which could scale exponentionally once the underlying product is fully working.

For us, the first application that will be built for a customer through a Fast Track engagement will act as a Trojan Horse. It will give us a foot in the door. It will give customers a first taste of STOIC. And because the Fast Track Package is built upon a partnering model with small to mid-size consulting practices that tend to be very local and vertical, it has the potential to scale at a fairly rapid pace. Nevertheless, if we leave our Trojan Horse sitting there within the confines of a customer’s first and only application, there is very little chance that users will use the platform for anything more than the initial application it was deployed for. In other words, a platform remains a platform, and users still don’t know what they can use it for. At best, they’ll know that it was used to develop one application. Nice to know, but not game changing.

In order for us to move a step further, we need to make our platform consumable by users who are not looking for a platform. To do so, we need to slice our monolothic platform into bite-size services that could be used to solve very specific problems. In other words, once our mythical Trojan Horse is in the place, we need to conquer Troy by unleashing all the soldiers that were hidding into it. These micro services will be our embedded foot soldiers.

So, what are these micro services? These are services that are making all the goodness of cloud computing consumable by mere mortals. If you look at the countless products and services currently available under the Amazon Web Services umbrella, you quickly realize that you need to be a very seasoned architect to take advantage of them in order to develop your application. And if you’re a business user, or a less technical user, you need some kind of user interface that will make these infrastructure-level services consumable. for example, you’re not going to use Amazon SES for sending bulk emails, you’re going to use MailChimp.

Unfortunately, these off-the-shelf services are really good at doing one thing really well, but they quickly become cumbersome when you need to use multiple of them in order to address more complex scenarios. And because software is eating the world, these complex scenarios are becoming more and more commonplace, and are being encountered by more and more people, who are neither distributed computing experts nor data scientists.

Therefore, there is a need for a collection of micro-services that could be used in a few minutes to address a very specific need, then combined together in a few hours or a few days to implement a more complex scenario. Said another way, we need a generic platform capable of handling the multiple aspects of developing and deploying custom-built application in a cloud and mobile environment, yet packaged in such a way that it can be used for a wide range of simple scenarios. And last time I checked, it looked like STOIC was not too far from fitting that bill.

The micro services I am talking about would take two forms: single-page applications for business users, and single-page API for developers. Single-page because you want them to be as simple and consumable as possible; UI and API because you want to make the platform consumable to both business and technical user. And while the following list remains a work in progress, here is the set of services that can be offered by the STOIC platform today:

  • Authenticaion: Enable cross-service access control.
  • Authorization: Enable cross-service authentication.
  • Badges: Add gamification to any application.
  • Benchmarking: Benchmark anything in the cloud.
  • Charts: Turn spreadsheets into charts.
  • Database: Store complex data in the cloud.
  • Drives: Get a single API for all online drives.
  • Email: Get a single API for all email services.
  • Forms: Turn spreadsheets into online forms.
  • Formulas: Execute formulas in the cloud.
  • Logs: Log machine data in the cloud.
  • Mobile: Turn spreadsheets into mobile applications.
  • Monitoring: Monitor anything in the cloud.
  • Perspectives: Turn spreadsheets into visuals.
  • Pipes: Connect anything to anything in the cloud.
  • Processors: Automate multi-step processes.
  • Scheduling: Schedule jobs in the cloud.
  • Spreadsheets: Turn spreadsheets into APIs.
  • Transformation: Transform data in the cloud.
  • Widgets: Turn anything into widgets.
  • Workflows: Add workflow to any application.

Once an application built on top of STOIC will be deployed within a company, its employees will automatically have access to this collection of micro-services. They won’t require any additional payment, or any new user registration. They won’t require anything new to be deployed, nor any expert skills. In other words, they’ll be eminently consumable. And if they work well enough, simple word-of-mouth within the company should make them spread.

Initially, these services will be used by users of the initial application that brought STOIC into the company. But sooner or later, an extended group of users will discover their benefits. At first, users will adopt one or two services that really matter to them. But over time, they’ll start to use more and more services, and when they do so they’ll discover that the more services they are using, the better these services are working together. They might not yet understand why (because they’re all powered by the same underlying platform), but they’ll realize that these services are working better than alternative standalone services that are available on the open cloud. In other word, some network effect will start to kick in.

For most users, it will stop there. Much like most users of Excel have never used it for antyhing more than laying out data within the cells of a grid, and have yet to write their first formula. But for others, the adventure will continue. Sooner or later, they’ll discover that our single-page applications also have links to a more complete user interface giving them access to many more features. Over time, they’ll start to develop some mental picture for the underlying platform. Then, on some glorious day, they’ll have an epiphany and they’ll decide to look behind the curtain. They’ll step into the world of the platform. And they’ll never look back…

To recap, our incremental adoption process will look something like that:

  • Use an application that happened to be developed on top of STOIC
  • Use a first micro-service in relation with the initial application
  • Use a micro-service on its own
  • Use multiple micro-services individually
  • Use multiple micro-services together
  • Use the platform to develop a new application

Once we make our 1.0 release (sometime in September), we’ll spend the next twelve months working with a few dozen customers to implement this incremental adoption process for the platform. We’ll start with small projects first, then tackle more ambitious ones. Initially, we’ll work with small datasets (gigabytes), then upgrade to bigger ones (terabytes and more). We’ll refactor many parts of our server and user interface to package these micro-services, which will strengthen the underlying platform by making it less monolithic. We’ll instrument their utilization by customers and monitor their adoption rates. We’ll discover which services are valuable, and which ones are not. We’ll learn what it takes to build a successful service. And when we get there, we’ll figure out a way to scale this up aggressively.

Let’s embark on this journey together!

Go-to-market application

STOIC is a platform, and platforms are notoriously difficult to bring to market. This is something that we’ve known intuitively for a long time, but we’re starting to better understand why. The reason was best summarized by someone we talked to last week during some due diligence: unlike applications, platforms deliver very little business value initially. Their value is delivered over time, in a very incremental fashion. Over a long period of time though, the value increases and is guaranteed for even longer periods of time afterward, because of the fact that successful platforms tend to be sticky. But the time-to-value can be quite long, especially when you consider that platforms can have switching costs (cost of switching from one platform to another), hence their initial business value is actually negative, and can remain so for a while.

Unlike platforms, applications deliver most of their value immediately after they’ve been deployed. This could take a while for complex applications like ERP systems, but simpler applications like office productivity suites will deliver value from day one. That being said, this value tends to decrease over time, because better applications invariably become available on the market, and the perceived value of legacy applications diminishes as a result. And in the world of business applications, for better or for worse, perceived value is almost as important as actual value, at least from the viewpoint of the economic buyer who will sign a large check for buying new applications. Nevertheless, the fact that applications deliver most of their value initially makes them dramatically easier to sell than platforms.

Such is the challenge of bringing platforms to market: platforms are great over time, but you’re always better of selling an application built on top of the platform instead. Of course, if you do so, you might end up over-optimizing your platform for the particular set of use cases supported by the application you build on top of it, thereby restricting the applicability of your platform to this particular application. As a result, you end up with nothing more than an application, instead of a generic platform that could support the development of a wide range of applications.

Another approach consists in developing a very simple application to support your go-to-market strategy, while working with partners who develop other applications on top of your platform. The former will bring in a steady revenue stream, while the latter will ensure that you keep building your platform at the same time. If you do that long enough, you should end up with a successful application and a solid platform underneath. It might take a while to get there, but it’s a powerful way to break the catch-22 cycle that too many platforms get caught into.

Picking the right application can be a challenge though. You want it to be simple enough that it won’t divert too many resources, yet sophisticated enough that it will really take advantage of the platform underneath —  otherwise, your platform becomes a liability more than an asset, and you’re much better of developing your trivial application on top of a more established platform.

You also want to pick an application for which there is a market, which I would define as a set of people who have money to spend in order to solve a problem they wake up in the morning knowing they have to solve. And you want this market to be large enough that it could support you and multiple competitors for a while, yet not too large that it’s already captured by established players. In other words, you want an application that can address a fast-growing emerging market, with plenty of room for many different players.

Then, in a perfect world, you’d like to pick an application that can effectively showcase the features of your platform, giving users a taste for what they could do with it if they were to peel a few layers of the onion. But you want this onion peeling process to happen over time, at the user’s own pace. In other words, you want the application to be able to sustain itself as a standalone product initially and for a while, yet be enhanced by its underlying platform. Or, coming back to the time-value analysis introduced earlier, you want the value of your application to increase over time, precisely because it is built on top of a platform, instead of being nothing more than a bespoke application which value ineluctably decreases over time.

Last but not least, you’d like the growth of the market defined by this application to be supported by tectonic changes that are happening in the industry, and are not limited to your application’s market. You want these changes to apply at a systemic level, to be positively guaranteed, and to be long-lasting, because it might take you a while to deliver the right application and to make its underlying platform work at scale. 

If you can find such an application, and if you can package it in such a way that your platform initially becomes almost invisible, you’re in good shape. And if you can find a way to bring this application to market without having to spend massive amounts of money in sales and marketing, you should find success along the way, no matter how hard you try not to.

Ever since we’ve started STOIC, we’ve been pondering this issue, one way or another. But we could never find an application that fit all the criteria outlined above. Then, over the past few days, a candidate has been slowly but surely emerging: STOIC Drive. We’re not yet certain that this is the application that we’ll use to go to market in the way that I just presented, but it’s looking more and more promising. Here is why:

First, let me explain what STOIC Drive is. In a nutshell, it’s a private clone of Google Drive. It’s something that you can deploy in your private or hybrid cloud, and will give you most of the features offered by Google Drive. It’s not very fancy, and there is a well-defined market for it: Enterprise File Sync & Share. There are quite a few players in that space already, but no market leader yet, and very few (if any) that are focusing on the segment we’re interested in.

Second, let me explain who STOIC Drive is for. It’s aimed at large companies who have just deployed OpenStack to create their own private or hybrid cloud and are now looking for applications that could be deployed on top of it and could reduce the rogue usage of public cloud applications. By far, the most popular SaaS applications are public drives like Box, Dropbox, Google Drive, or Microsoft SkyDrive. Therefore, it is reasonable to think that early adopters of OpenStack will soon be looking for online drive alternatives that could be deployed on top of their brand-new private cloud infrastructure. These early adopters are the initial target that we have in mind for STOIC Drive.

Third, let me explain what problem STOIC Drive solves: on one hand, business users want the convenience of consumer applications like Dropbox, which is the reason why they’ve been adopting them in droves, and the recent BYOD trend has accelerated this adoption even further; on the other hand, IT managers want to keep control of their infrastructure and enforce the variety of governance policies that justify their very continued employment within large organizations. STOIC Drive helps reconcile both needs, by delivering the convenience of consumer applications with the governance of enterprise systems.

Fourth, let me explain how STOIC Drive works. At the most basic level, STOIC Drive is deployed as an application on top of OpenStack. It takes advantage of OpenStack Swift to store large amounts of file-based content on the customer’s private cloud. But STOIC Drive also happens to be an application built on top of STOIC, with a great user interface for both static and mobile devices. In between, it offers a set of connectors allowing you to mount the most popular public drives (Box, Dropbox, Google Drive, Microsoft SkyDrive, etc.) as virtual folders on the drive. It also provides an API to connect to Amazon S3 so that you can do this cool cloud bursting thing that everybody seems to be so much in love with.

Fifth, let me explain what’s so cool about STOIC Drive. By providing this connection to all public drives, it allows business users to continue using them, while having full backups on the private branch of the drive. And by having the drive built as a STOIC application, it adds a host of features to all public drives, including:

  • Advanced permissions (Cf. Authorization engine)
  • Indexing & Searching
  • Publishing
  • Relations
  • Properties
  • Tags
  • Dashboards
  • Discussions
  • Notifications
  • Tasks
  • Workflow

In other words, this drive actually provides most of the features usually offered by traditional Document Management Systems, but with a consumer-grade user interface, and a hybrid cloud deployment model. And because it’s built on top of OpenStack Swift and ElasticSearch, it will give you petabyte-level scalability, while remaining highly cost-effective.

If we summarize, here is what is getting us excited about this application:

  • Emerging market with high potential for growth and no dominant player
  • Well-identified economic buyer buyer
  • Clearly-understood value proposition
  • Large addressable userbase including both business and technical users
  • Large number of paying users within accounts
  • Small number of required features
  • Significant potential for showcasing the underlying platform

For all these reasons, we think we have a winner. We also think that picking the wrong application is actually less damaging than picking no application at all. If this one does not work out, we can always build another one. But not focusing on any application is a sure way to fail as a platform vendor. As a result, we’ve decided to investigate this opportunity as aggressively as we can, and to make a final decision during our upcoming company-wide gathering at the end of the month. In the meantime, Pascal is burning the midnight oil to get a prototype ready soon.

Fun stuff!

Vertical focus

Our market research work concluded that we should focus on the following verticals:

  • Retail
  • Manufacturing
  • Media
  • Higher Education
  • Local and State Government

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…

Pricing model

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:

  • Make it attractive to third-party developers, yet fair to the platform vendor.
  • Work for both end-user applications and third-party applications.
  • Generate high-margins for high value-added applications.
  • Tolerate free and low-cost applications.
  • Lower initial barrier to adoption.
  • Ensure profitability and scalability across all major scenarios.
  • Remain within the bounds of well-accepted pricing models.

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 is a good starting point.

As a result, here is what our pricing could look like:

  • 30 days free trial (once we go GA)
  • $25/user/month for power users, including 100,000 API requests (push or pull) per month
  • 15% commissions on sales through our marketplace
  • 10¢ per 1,000 API requests over cumulated power user allowance

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.

Intellectual property strategy

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, licensespatents, 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…

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.

Now that we’ve acquired the 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 (,, 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 ( or Twitter (@wearestoic), but things there are a lot less straightforward unfortunately.

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

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!

Go-to-market strategy

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).

A step closer to the epiphany

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:

  • Small businesses or large enterprises
  • Systems integration firms
  • Independent software vendors

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 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.

Early market validation

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!

Leveraging custom developments

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:

  • Sign a first customer before hiring your first employee.
  • Ship a first version of your product before you think it’s ready.
  • Generate revenue and become profitable before you take VC money.

Constraints foster creativity

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:

  • No VC funding
  • Day-one profitability mandate
  • Small team
  • Tiny office space
  • Limited technical skills
  • Narrow window of opportunity

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.

No logo

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.