The Windsoc Blog

In commercial real estate, it’s much easier to develop a property if you have one major client signed on before you start building.

In the world of music festivals, your headliners can often make or break the entire event.

For your startup, having a big client may make the difference between the hockey stick and cricket chirps.

Smaller clients are awesome; they make for great evangelists and often give feedback that can totally re-orient your product for the better. But in the world of social proof, bigger clients reign supreme.

What’s the difference between your friends and your mom? You’ve spent hundreds of hours with them, you know them well, and they know you. The only big difference may be that your friends have (probably) never had to clean your underwear. And the differences between your friends and you earliest clients aren’t huge, either; some of our clients are already our friends, and clients become friends as business relationships grow. You best clients will eventually support and encourage you as much as… your mom. So they’re really not that far apart, after all. And investors and the media may not be able to tell the difference, and they may just assume that the customers they’ve never heard of are just friends and family.

That’s where size and buzz come in. If a company is better known, it’s much clearer to potential advisors, investors, media, and customers that the people doing business with you have never spent any time scrubbing unsightly stains from your boxer shorts. A recognized logo on your “Who Uses Us” page can do wonders for your credibility, while testimonials from those big clients are total conversion crack.

So how do you get the big client? Well, Windsoc doesn’t have a “Super-important People Who Love Us” page yet, but here’s what we’re planning on doing over the next few weeks:

1. Make sure your product is winter-ice solid. It’s still possible for the occasional crack to come in, but you should at least have gone through enough alpha or beta testing to keep the whole ice sheet from crumbling. Big clients have enough work to do without having to worry that your product is going to leave them flailing in frigid water.

We may start trying to flirt with some big names, but we have a couple more weeks before we’ll throw a dance party in the middle of our frozen lake.

2. Do your homework. Successful companies have a focus that can make peripheral offers hard to see, and for good reason: their product (and customers) come first. If you’re searching them out, you need to have an idea of what their business actually does, and why what you have to offer actually brings value.

We’re taking an in-depth look at many websites, not just to check what social integration is already in place, but also to determine the strengths of the team. Some companies are more focused on integration than others; we expect that we can provide more value to companies who haven’t had a chance to bring in as much social integration as their competitors.

3. Be careful with free. It’s tempting to promise free to the big names, expecting that this will win them over. But the sticker price of your product is likely to be far less than one percent of a company’s budget; the bigger costs are time and the risk of giving control of some aspect of their business to a new company. And a user who doesn’t pay isn’t really a customer.

We’re waiving our license fee for beta testers big and small (it’s a pretty low cost, either way), but we need to remember that a big client will increase our infrastructure cost, and at a certain point we need to recoup those costs.

4. Give them time to fall in love. This goes for customers big and small: love is positive experiences + time. Don’t push too hard in the beginning, asking for a testimonial or pushing your customer for referrals or PR. Give your relationship time to grow, and the benefits will flow naturally over time and the praise you receive will be more sincere.

We’re going to take things slow, and focus on bringing value to our customers. That sounds cheesy and insincere, but it’s really just clever and self-serving.

5. Don’t neglect the smaller customers. There are dozens of reasons why the smaller customers are important, not least of which is that over-reliance on a few big clients can bring your company crashing down if one or two feel the need to alter terms or end their relationship with you. But in the end, every customer was small and unnoticed at one point (except for Color, of course), and you definitely want to be part of a small company’s rise. Even if your product is such that they could one day outgrow you, the benefits of that relationship by then will have gone far beyond the money they’ve paid.

Our goal isn’t to grab a few big clients with fat wallets; our mission from the start has been to bring about the next generation of social by making integration with any and all services as easy as possible. That means working with the largest enterprise and the smallest side-project, in any language, on any platform, anywhere on earth. So there.

So if you’re a well-known company, don’t be surprised if I try and get in touch with you over the next few months. And if you’re a developer with a really cool hobby project or a company that provides interesting platforms or products for your customers, don’t be surprised if you hear from me, too. We’re searching for all our clients right now, big and small. And if you think that Windsoc should be one of your next clients, let us know.

Discuss this post on Hacker News

SoC 1.0 – Functional programming and the Internet Protocol Suite (1960s-1990s)

SoC 2.0 – The popularity surge of Model-View-Controller and friends (late 1990s – 2010)

SoC 3.0 – Asynchronous design, OAuth and APIs (2005 and beyond)

I’ve always been a Model 2 type of guy when it comes to designing software, although I’ve always just arrogantly called it “the right way”.

What we’re seeing now in application development can be easily demonstrated by viewing the source of Twitter.com. Asynchronous requests, loads of JavaScript (no pun really intended), and constant use of the keyword “API”. This is long past the stage of throwing some AJAX on the page to show off; we are seeing a new era of web development based strongly on Separation of Concerns. In buzzword parlance, it’s Separation of Concerns 3.0.

The API is the foundation of a well-built application.

(it must be true… it rhymes)

I’ve read a number of articles on building your product from the start on top of your API, but all I can recall now is this Quora question: Should a startup build the API first and then make the website a client?

The answers on Quora, and the answer in Regan-land (where I go whenever I close my eyes) is an absolute YES. Well, actually, I do the screen mocks first, since that tells me what I need in the API. And why?

1. APIs separate your domain logic from your presentation.
“Keep your server code blocks away from my ordered lists, thank you.”

2. APIs make asynchronicity easy.
“Why would you use more than one page load? To boost ad impressions?”

3. APIs can bring platform agnosticism to your product.
“We’re switching from VB.NET to Scala on the backend.”
“And?”

4. APIs ease expansion to other platforms.
“Do we need back-end programmers on the iOS team?”
“Not unless we want some graphics done in MS Paint.”

5. APIs can be publicly released or shared with trusted partners.
“Should our company build an API?”
“We’ve always had one. We just haven’t told anyone about it.”

Of course, having an API isn’t the same thing as releasing your API to everyone; that can happen later, or not at all. That’s your call.

We built the Windsoc API when we were building the Windsoc Social Client (which is still hiding under the bed); only later did we realize that the API was what people would really want to get their hands on. So we added OAuth support and took a second look at our model, and now we have an API that is our product.

So maybe we’re a little biased, and maybe some would disagree with having an API at the beginning, saying that it conflicts with the notion of a minimum viable product. But you have to create your domain logic somewhere, so an API vs. no API is really a choice between putting your code in one drawer or stuffing it in the bathtub and hoping that you remember to move it out of the way before your next shower. (At least, that’s how it felt in some of my past projects.)

So yes, I want to get my grubby little hands on your API. But even if you don’t want to share it, building your own API to run your product is a good choice to make.

(And yes, we could have gone with WindSoC, but the “S-o-C” can also mean social, or society, or even sociopaths. Whatever you’d like.)

Discuss this post on Hacker News

Note: I won’t purport to tell you what works for your business, but I will gladly drone on about what I think will work for us. If you think some of our strategy would make sense for you, I hope you’ll give it a try. And I hope you’ll use Windsoc, too.

Doctors make the very worst patients, or so the proverb goes. How does this relate to hackers and the services they use?

At Windsoc, we’ve created a Unified Social API, allowing developers to use one simple API for a whole pile of online services. Windsoc takes away the complexity of dealing with things like OAuth, parsers and offsets. Our goal is to make integrating with other services as easy as DOM manipulation has become with JQuery, or page layout has become with CSS Grids like Blueprint.

But making things easy isn’t, well, easy. Simplifying is often seen as “dumbing down”, functionality and customization being taken away in order to please an assumed majority of users. That approach can’t happen for APIs; the long tail is where much of the value lies.

And there’s another problem: many developers are tempted to code everything themselves. If we want Windsoc to succeed, we need to make sure that we can make the argument that what we provide is better for their products both in the short and long term. We won’t convince everyone, since some programmers will always do it themselves, but we strongly believe that most hackers will see value in what we’re doing.

So how to deal with “I’ll do it myself”?

1. Eliminate Temptation by Following Standards

If our code makes sense, there’s less of a reason for someone to rewrite it. I think of it this way: if someone wanted to re-develop our product, would they mostly just copy and paste what we already have?

I can only speak for myself, but most of the time when I get an urge to spin my own it’s because the tool I’m using seems arbitrary and inconsistent. I’m a data guy, and sadly enough, pretty data excites me more than pretty graphics or pretty algorithms. With Windsoc, we are doing our best to make the data we return match the standards set up by the Activity Streams Working Group. We’re dealing in JSON and not using ATOM (at least, not yet), but the data model is the same. And when the Activity Streams specs don’t provide the answers, we take a look at what’s being done with OStatus, OpenSocial, and other specs that are meant to federate data formats.

We’re doing the same thing with our API URLs, using REST (get, post, put, delete) for our calls and trying to stick to the notion that each URL is unique and points to a unique resource. It’s not always easy, and we may not always get it right, but that’s what Version 2 is for.

2. Emphasize the Pain and Give Them Some Aspirin

Showcasing the maintenance we do and the problems we continue to solve will underscore the ongoing value of our product.

There are two types of pain in working with APIs: development and support. Most programmers are familiar with the first, particularly if they’ve tried to use the same OAuth code for Twitter and Facebook, or if they’ve tried to convert LinkedIn XML into JSON. Windsoc helps with development, and that’s very good to have. But the second pain point is a much bigger headache.

I can write code at work, at home, even on the bus or on the toilet (although I don’t recommend the last one). If I want to enjoy the weather, I can close the laptop and go outside. Development allows for flexibility, but support does not. When something breaks, it needs to be fixed, not later, but right now. At least that’s the case if you still want to have paying customers.

And when does support rear its ugly head? Usually whenever you can least afford it, like the middle of the night, or when you’re on a plane to Cleveland, or if you’re a part-time bootstrapper it’s when you’re at your day job. You have enough support issues as it is, so Windsoc handling your service integration and dealing with changed or broken APIs certainly reduces the load.

We have processes to use that monitor API usage so we can know which customers/products are affected by specific API changes/issues; we also have a test suite to check all methods to ensure that they are still functioning according to spec. When a service API is updated or we receive notification that an external method is no longer doing what it should, we’ll make the required changes even if it is at 3am, and then we’ll contact our clients who were affected to let them know.

Rather than having thousands of developers tracking down and working to update or fix API calls, Windsoc will take care of the problem before most clients even know that problem existed. And clients won’t need to make changes to their code to stay up-to-date with integrated services.

3. Show the Possibilities

By taking care of a peripheral component, we give businesses and developers the opportunity to focus on innovation and growth.

Most sites start with Facebook or Twitter integration, and they often leave it there. Why would they bother learning yet another API when they’re not even sure how it would look, or if people would even use it? Windsoc not only allows developers a much easier route to adding a new service, we are also creating demonstrations of what Windsoc can do. Our first public example is http://mentorstream.com. It’s a very simple application (written by me, Regan, and not Mike, the REAL programmer of our team) that tracks the status updates and activities of a select group of mentors in Startups/Tech. What’s interesting about MentorStream is that it brings in data that isn’t often found in aggregation, including Quora activities and submissions on Hacker News. Adding another service to MentorStream isn’t limited by technology, but by whether or not I can find a service that brings in more updates from our mentors. Check it out, and let me know if you can think of a mentor I’ve missed, or a service that I should add.

There is much more than can be done with MentorStream if people find value in it; allowing users to login and create their own personal mentor lists would obviously make sense. And since it’s powered by Windsoc, I can add logins for Facebook, Twitter, or even Gowalla. It brings integration away from being a technical challenge and makes it a business decision based on what’s best for your product.

4. Let Them Tinker

Give your potential clients the time and space they need to really use your product, without forcing them to focus on pricing and sales pitches.

Most hackers work on more than one project, often creating side projects that have the potential to become their major focus. We want people to use Windsoc on their projects, even if those projects aren’t going to be the next Zynga or Groupon. We want to be an accelerator for development and deployment, not an anchor that weighs products down. So rather than trying to sell the biggest corporations on switching to Windsoc, we want to focus on helping programmers and startups to grow their products and their companies, to be a part of the success whether they’ve been working on it for a while or just starting out. So if you have a project that you think would go well with Windsoc, please let us know. We’re actively looking for beta testers, and would love to get a mix of industries and business stages.

5. Make the Cost Match the Usage

Charging money is a scary thing, but we know that customers would prefer a service that has a plan to keep the servers running and the programmers fed.

Windsoc is not just an API translator, a Rosetta Stone of sorts; it’s also an API platform, where we work to make calls more efficient with pooling and caching. There are also occasions when we’ve combined data from multiple calls into one data stream, and that may become a larger component in future. That’s on top of translating disparate data into a common format that’s easy for developers to use. It all makes Windsoc very powerful, but adds to our server costs. On top of those costs, we have support and code maintenance, in addition to product and business development. That’s why Windsoc can’t be free for everyone, but at the same time we know that we need to make sure that any money you give to us is still working for your business by saving you development and support time, and by adding new functionality that brings value.

Obviously building a kick-ass API will help on the one end, but we also want to make sure that our billing is fair. Rather than charging a monthly subscription for every person who wants to try us out, we’re looking at a different model. Now this is still just a proposed model at this point, so please be sure to let us know what you like and dislike about it:

30-Day Trial

This should be enough time for you to see if Windsoc makes any sense. If you don’t feel like it brings any value to your projects, we’ll accept your decision to leave without sobbing uncontrollably.

$50 Developer License (1-year)

This would allow you to use Windsoc in up to five of your applications at a time without further charge. Usage limits should be high enough for beta, and even for an initial release for most apps. What the license fee pays for is usage and support, so that we can take the time that’s needed to help you build your products. Our closed beta users for Windsoc will not be charged a license fee, so please sign up if you want to be a part of our early rollout.

Higher Usage Plans – $29/month and up

For apps that have grown beyond the initial release and are reaching the initial usage limits because they’re finding success, we plan to offer higher usage plans starting at $29/month.

∞. Be prepared to change the strategy

So we have a strategy, but I think the biggest part of the strategy is right here at the bottom . We can’t even begin to imagine all of the possible uses for Windsoc, or all the services we may be requested to add. We’ll just have to listen to what you have to say.

I’ll just sit here and wait. No pressure, but I’m here… waiting…

Visit Windsoc