Ashish Datta, Author at {5} Setfive - Talking to the World

Being a services business, we’ve always been lured by the forbidden fruit of developing a SaaS product, selling it to a bunch of users, and then sitting back and watching the revenue pour in every month. Over the last few years, we’ve been approached a couple of times by people looking to have us serve as the engineering team of a company in exchange for equity which would eventually begin generating revenue. Despite this situation being relatively common, there are relatively few guidelines on how to approach receiving equity in exchange for work as a services company. With that in mind, here are some guidelines we use in these situations. Also, these suggestions are probably also equally applicable if you’re a services company looking to develop a product in house.

Treat the project or company like a billable client

An issue that we’ve repeatedly noticed is that equity or internal projects are often treated as “second class” citizens within service companies. Since they aren’t billable, companies end up doing things like leaving them off the planning schedule, pushing the work off until Fridays, or only assigning interns to the project.

One strategy to help combat these issues is to on-board the project like you would any billable project. Depending on your process, this might mean doing things like creating a Basecamp project, adding the project to your time tracking software, and holding a “kickoff meeting”. Whatever your process may be, the takeaway is to treat the non-billable project like a normal one throughout your organization.

Set a budget and stick to it

Budgets are important for any project but they’re especially important when equity is involved or it’s an internal project. When dealing with a non-billable project, you’ll want to avoid the “equity guilt” where you’re guilted into “doing just a little more” since you own a measurable % of the company as well as eventually be able to calculate an ROI for your investment. A proper budget will help you do both since you’ll be able to know when you’ve contributed your fair share and hopefully one day calculate your ROI against the budget.

Developing a budget in these situations is relatively easy, just take how you’d normally bill and decide on a number for the version one of your buildout. If you bill hourly, pick a number of hours, if you bill by the week then pick a number of weeks. Since the project is already set up as a “first class” project you should be able to just add a budget against it.

Someone needs to “own it”

One of the problems that arises in equity deals and internal project is that there isn’t really a client and subsequently there often isn’t a single person responsible for making key decisions. Having a single person that ultimately “owns” the project will mitigate “design by committee” issues and also help keep the momentum of the project going.

Fair warning though, “owning” a failed project carries a heavy emotional and psychological toll so as an executive you’ll have to be ready to support an employee that accepts this responsibility.

Clearly define responsibilities

Clearly spelling out who is responsible for what is important when a services company is being brought in for equity. Detailing responsibilities will help you avoid a situation where your team started off as the marketing team but then ended up fielding support issues and ultimately resenting the project.

Agree upon KPIs and know when to quit

Knowing what you want to track and how you’ll measure success is important when money isn’t being exchanged because it helps keep everyone accountable and prevents the project from slowly stagnating. Having a good handle on your KPIs also helps motivate the team if things are going well and they’ll ultimately be a primary factor in deciding if you should continue the project.

Unfortunately, one of the hardest aspects of any project is knowing when to quit. This decision is usually harder in equity only or internal projects since there’s no pressure of burning capital and there won’t be the finality of the money running out. Despite this, knowing when to pull the plug will help you facilitate an orderly shutdown of the project and also give everyone involved the chance to debrief.

So should you do an equity only project? Well it depends. Given the the reality of startups, chances are you’ll not going to enjoy an eight figure exit and retire a millionaire. But chances are, if your team gets involved with an interesting project they’ll get a chance to learn a lot, experiment outside their comfort zone, and maybe even leverage the project into new business. So my answer would be a “maybe” depending on where your business is and what sorts of opportunities you’re being presented with.

The other day, I was hacking away on the PHP backend for the “Startup Institute” visualization and I realized it was going to need a good deal of array manipulation. Figuring it was as good a time as any, I decided to try and leverage PHP 5.3+ new closures along with the array_* functions to manipulate the arrays. I’m not well versed with functional programming but I’ve used Underscore.js’s array/collection functions so this is mostly in comparison to that.

The Array

The entire shebang is on GitHub but here is the gist of what we’re intersted in:

There is a CSV file that looks like ssdata.csv.sample except with more entries that is read into a list ($data) where every object has keys cooresponding to the values in the header. Thinking in JSON, the array ends up looking like:

Ok great, but now what can we do with it?

Sorting:

Using the usort function is particularly natural with closures. Compare the following:

It’s pretty clear the version with closures is much shorter, more conscience, and ultimately easier to follow. Being able to “capture” the local $sortKey variable is also a key feature on the closure version since with the static version there’s no easy way to introduce variables into the sorting function.

Mapping:

In the linked example, I used array_map to basically convert an array of characters into an array of ASCII values for those characters.

With such a small map function, it’s hard to see or appreciate the benefits of using the closure along with array_map. With the closure though, you’ll get a couple of benefits including isolated scope so that you won’t inadvertently rely on the value of a variable that isn’t directly related to transforming the array values.

Using the closure would also “look” much cleaner if the array had non-numeric keys, since without being able to use integer indexes the for(…) loop would be more confusing.

Filter it:

This isn’t used but it could have been to return only the elements that were selected.

Looking at the the version with the closure, its a bit easier to follow and since it’ll enforce scope isolation if the “truth test” was a bit more complicated you’d only have to debug what’s actually inside the closure. Also, not having to “skip” some elements leaves the code with a nicer feel and overall I’d argue its just better looking.

Overall Thoughts:

Overall, using closures with the array_* functions will definitely lead to cleaner, more concise, and easier to follow code. Unfortunately, there are a few rough spots. Like with most of the standard library, the argument order is inconsistent which is always a constant irritation. For example, for no apparent reason array_map is “callback, array” but array_filter is “array, callback”. Also, another irritation is that the “index” isn’t available inside several of the callbacks like on array_reduce or array_map.

Personally though, the biggest limitation is that none of the array_* functions will work with classes that implement the Traversable or Iterator interfaces. That means if you have a Doctrine_Collection and you want to reduce down to a single result you’re still stuck with a foreach(…).

Anyway, as always I’d love to hear other opinions in the comments.

Most of our clients are using Amazon Web Services for most, if not all, of their infastructure needs. They’re doing things like using EC2 for servers, S3 for storage and backups, Route53 for DNS, and SES for sending transactional email. For the most part, everything works pretty well and the overall experience is pretty solid. One issue that does come up is that with this strong reliance on Amazon, a lot of people within an organization end up needing to login to the AWS Console. Doing things like pulling data off S3, managing EC2 instances, and creating email addresses all ultimately require logging in to Amazon. Unfortunately, as an organization grows they’ll usually end up passing around a single “master password” for their single Amazon account. Passing around a password like this poses a huge operational risk but AWS actually has built in functionality to mitigate this called Amazon IAM which helps you administer rights access on your account.

What is it?

Amazon IAM is AWS’s identty and access management solution. What it does is allows you to add additional authorized users to your Amazon account, organize them in groups, and then grant the individual groups various permissions on your account. IAM would allow you to do something like setup a group called “access backup only”, add 3 users to it, and then only allow them to download files from S3. From an operational perspective, IAM will allow every user that needs access to have their own account with its own set of permissions which can be revoked at any time.

Why you should use it

The biggest direct benefit to using IAM is that you’ll be able to give every authorized user a separate account which they can access AWS with. This means if you have to terminate an employee or stop working with an agency you won’t have to do a “fire drill” and change your AWS password or worry about which access keys they have. On top of this, since each group has limited permissions you can be confident that inexperienced users won’t accidentally do something inappropriate.

The other big benefit to implementing IAM is that you’ll be able to take advantage of multi-factor authentication. Multi-factor authentication basically means that instead of *just* needing a password to login, you’ll also need a one-time use secure token. MFA tokens can be generated in several ways, from an RSA token to a smartphone app. If you’re already using Google’s Authenticator app for your Google Account (and you should) you can just link it in with your IAM account.

Anyway, enable Amazon IAM and you’ll sleep better at night.

One of the most interesting companies in the ad:tech space right now is AppNexus. What AppNexus provides is basically the infrastructure necessary to build and run an internet display advertising business. In addition, they also provide a REST API to access the majority of the platform’s capabilities. This post will walk through how to use the AppNexus platform to setup audience retargeting.

What is retargeting?

With the rise of “real time bidding” in the display advertising space, it’s now possible for advertising choices to be made in real time at the individual user level. Basically, what that translates to is that as a web user every time you see a display ad an algorithm is transparently deciding how much to pay to serve you that ad. Using this technology then, its possible to “retarget” visitors that had been on your site as they see ads across the Internet. So with AppNexus, you’d basically be using their platform to “tag” your users and then leverage their RTB connections to show those users ads as they browse the internet.

The setup

Using the AppNexus platform to set up retargeting is relatively easy. First, you’ll need to leverage the “Get UID” call to retrieve the AppNexus id for your user. The URL is structured like:

http://ib.adnxs.com/getuid?http://www.yourdomain.com/getId?id=%24UID

The /getuid service will generate a 301 redirect to the URL you specify and replace the $UID placeholder with the user’s Appnexus id. If you’re planning to process users with a batch process, you’d want to store the id that gets returned from AppNexus so that you can target those users.

The next step is adding users to AppNexus segments which will allow you to target them across RTB exchanges. There are two ways to achieve this, you can either add users to segments in real time using an AJAX call or you can add them in bulk by uploading a file to AppNexus. Adding users in real time is straightforward, the AJAX endpoint is:

http://ib.adnxs.com/seg?member=USER_ID&add=SEGMENT_ID

Using the batch process is a bit more involved, you’ll have to generate a file with AppNexus ids and segment ids and then use the batch service to process the file.

Great, but what can I do with it?

Plugging into the AppNexus infrastructure like this opens up a lot potential applications and use cases. Some potential use cases are:

Users that are viewing handbags on your site could get added to an AppNexus in real time to re-target them with handbag advertising.
Using the batch service, you could dynamically add users to opt-in for promotions to a specific segment.
In real time, you could monitor user behavior and add users that complete specific actions to a segment so they receive targeted advertising.

Anyway, if you’re interested in building solutions on the AppNexus API we’d love to work with you so drop us a line.

Last week, we got our hands on the class list for the Spring ’13 Startup Institute class. I had some time to burn so I decided to throw together a visualization using the names and email addresses of the members of the class. You can check it out at http://symf.setfive.com/d3_startup_school/

How it works

Basically, the visualization represents every student with a 3×3 color grid by using various attributes of their names and email addresses. The various squares are calculated with the following formulas:

Top left: Calculated by taking the first letter of the first name (say C) and then converting it to a % for how far down the alphabet the letter is. So C would come out to 3 / 25 = 12% Then, this percentage value is applied to the “lightness” component of a HSL color tuple for “hsl(40,100%,92%)”
Top middle: Calculated by taking the length of the first name and then calculating a % for how long it is compared to the other names in the list. So basically, it finds the length of the longest name and then divides the current student’s name by that value for a %. The % is then used in the lightness component of “hsl(340,100%,73%)”
Top right: A color generated using the metaphone of the first name. The metaphone is generated, then split up into 3 pieces, and then the ASCII values of those 3 components are summed. Then, the 3 parts are mapped to HSL values depending on the % maximum they are for the entire sample size.
The second row is identical to the first except using the last name.
Bottom left: Calculated depending on the “track” that the user is in.
Bottom middle and right: These use the same metaphone algorithm except using the email address and email domain name respectively.

Technically, the squares are drawn using the d3 library and the page layout is done with Bootstrap.

Anyway, as always comments and feedback are welcome.

Author: Ashish Datta

Tips: Five guidlines for exchanging services for equity