Thingamy, startups and building web applications 12:16 on Friday
Last week I had a couple of long chats with Sigurd Rinde on mini startups providing and building web applications on top of Thingamy. Coming from a small-scale web development background, that is what I’m interested in. So keep in mind this is not about killing SAP or anything. ;)
First of all, I think Sig and I actually had two simultaneous, intertwined discussions, which kept mixing things up a little:
- A more philosophical question of whether to search for the “functional epicenter” within the business or outside the business (referring to 37 Signals’ epicenter design and Sig’s response to that), and
- To what extent is a web application part of the application provider’s business model; i.e. what part of the application functionality goes into Thingamy and what doesn’t
The epicenter outside the business — by this I refer to 37 Signals approach of taking a functionality (calendar) and finding the most essential, can’t-do-without-it element (epicenter) of the calendar functionality (creating events), and starting the design from there. The argument being that this “epicenter design” automatically prioritizes features and creates simpler software. This is application development of off-the-web (equal to old school off-the-shelf) products, applications anyone can use as they wish and extend by integrating to other (web 2.0) apps using APIs.
The epicenter within — aka Sig’s approach. Instead of finding the epicenter of a functionality, he asks “why?” and looks for the epicenter of functionality in context of the business. This is bespoke development, aiming to create a solution that addresses an exact, individual problem. And if all problems are solved inside Thingamy, the solutions form an uninterrupted flow with no detours to separate applications (on the web or the computer). Task-based design versus flow-based design? Maybe.
For a mini startup providing a web application, it could be said the company is software. It might have an employee or two, but most of the company is software. Thingamy is an open-ended, no-limits system, designed to model and run a business, but also containing an object-oriented database, tags support, API… lots of elements that sound useful when running not only the business side, but the actual web application. So the somewhat technical question inevitably surfaces: to what extent the web application provided by the startup is a part of the startup’s business model? Where does the business model end? For a small startup it’s not an either/or question whether to use Thingamy, it depends on where you draw this line.
One possibility is that the startup would run the web application and the business model (Thingamy) separately, with the only link between being the transfer of customer invoicing information, for example. Or alternatively, they could have the web application data and logic inside Thingamy and have a thin layer to produce web pages out of it, reflecting the view that the web application is the business model. It sounds lucrative, but having tried that (in a micro-proto-scale) it doesn’t necessarily work so well. After all, Thingamy is a business modeling application, not an infrastructure for a web application.
So, if a startup that has their business and application separated, and they can get by managing their invoices with Blinksale, their development with Basecamp, customer support with Mailroom and the odd database in Dabble DB, then the unified flow is already broken. To get into the Thingamy flow, the startup would need to either:
- Build a custom app-less version of the required features from all of the above third-party applications, or
- Integrate the existing third-party applications into their Thingamy flow
For a mini startup, both options are too much work. However easy it is to model a business in Thingamy, to get the same user experience, ease of use, task-specific interface and simplicity that well-made off-the-web solutions can offer… there’s a lot of work to it! Enough work to kill any return on invested time.
Thomas Otter raised a similar concern for big businesses, saying that there is no reason to start from scratch and re-build “complex boring stuff”.
I want to be clear though on that I believe the returns are in no way directly proportional to the time invested in Thingamy; I rather think there is a certain “minimum investment” and therefore you need a company of a certain size to enjoy the benefits. I also believe that the bigger the company, the bigger the benefit of using Thingamy. (visualize an exponentially rising curve here)
I know Sig is probably going to kindly imply my head being stuck in the old mindset and he’ll repeat that to extract maximum value a startup needs to look at their clients’ whole business model (and beyond) and try to deliver a product (web application) that fulfills as much of the clients’ business as possible. Creating more value equals a better ROI for implementing Thingamy.
But this is answering the question of a mini startup not having an incentive to implement Thingamy by altering the business model of the startup, expanding the model and increasing risk. Not everyone is ready or willing to do that, they might be perfectly happy in the business of providing a web application that has its epicenter outside the clients’ business.
As you can see, this discussion loops around itself. And no wonder, it’s about epicenters both in the applications provided by the mini startup, and epicenters in the applications used by the startup. And finding where Thingamy fits in.
Sig is a visionary and he doesn’t want you to just run your business, but to model your business, look at the system dynamics, and re-model the business until you extract the most value. The source for “most value” might be different than the current source of value in your business. That is not simply modeling the business, it is (potentially) changing the business.
Thingamy is a bold bet, but I’m thrilled to have a seat and see how it turns out.