You might look at Spreedly and think, “Wow, they’re going up against some big competitors! How will they ever survive?” But we have a secret weapon that the big companies just can’t match: we’re small and lean and can respond to our clients at a rapid rate. For instance, we’re paying close attention to the feedback we’re getting from our latest round of invitees, and while we’ve queued some requests for later, in two cases we’ve rolled out an enhancement within 24 hours of receiving the request. To give you a peek in to the process, lets walk through the timeline of one of those…
We get the following request:
I looked around the site to see if there was a way to delete the subscribers we have on test and don't seem to find a way. We are running into issues with it because we are working on different dev environments hitting the test spreedly account. Is there a way to delete the test users we have created?
I post the request in to our Basecamp project, and an internal discussion ensues.
We quickly determine that we need a few more details to make sure we're solving the right problem. One of the challenges when building a turn-key product is to make sure you‚Äôre providing general solutions and not one-off hacks, so I send back this reply:
Can you give us a bit more detail on the difficulty the multiple dev environments is giving you and/or how deleting a subscriber will help? We're just trying to make sure we solve the problem in the best way.
We get back the following reply, which is a textbook example of useful clarification. It sure is nice having developers as clients!
Description: Jim creates user amy on his dev system who has id 3 and then creates a subscription with amy against the test spreedly account. Then I come along and create user bob on my dev machine who has id 3. When I go to create a subscription for bob, spreedly gives me information for amy, because user id 3 is already there. We just figured if we could delete the subscribers we could write a rake task to clear spreedly out before running acceptance tests against it. We only want to delete subscribers from our test site.. not production.
I post this back in to Basecamp, and we quickly agree amongst ourselves that it‚Äôs a legitimate need. We decide to go with a more generic solution, though: for now we‚Äôre going to provide the ability to wipe out all the test subscribers, rather than messing with individual ones. We also agree that this should cascade and also delete their transactions.
We rapidly add support for the new feature, and have several informal conversations along the way about how to design the API and UI. Part of writing the feature is also adding tests for it, and we‚Äôre extra special careful this time since we‚Äôre going to be irrevocably deleting data (don‚Äôt want that to happen in production!)
The deployment message goes out to the team via our Basecamp project, and the new feature is live!
We let the client know:
We just deployed this you can find it in the UI at the bottom of the Subscribers page. There's also an API call to do it (only in test!) which is laid out in the integration overview under "API Access using Rails". Let us know if you have any trouble getting it to work, and thanks so much for the feedback! It's been excellent so far!
We hear back from the client:
We like the lack of surprise and the fact that they just expect quick turnaround from us: keeps us on our toes! Of course, we can't and wouldn't want to do this with every request: our goal is to grow and enhance the platform intelligently, and sometimes that means saying "not yet" or "no" to requests. That said, can you imagine getting this kind of service from a company with 100+ employees? It's a bit ironic that more people means less responsiveness, but at least in the software industry that's exactly the way it seems to work. That brings us to the final question: do you want to tap in to the high energy of a small team like Spreedly for your subscription business? If so, head on over to spreedly.com and sign up for our invite list!