My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Most online developer API services that I've used are set up as if the customer is also the software developer.

That should change.

As the software developer, I don't want to be the owner of my customer's accounts, and I don't want to worry about trying to figure out how to transfer ownership (if your service allows it, that is). Because of that, theres a lot of waste that goes on: wastes of my time, which wastes my customer's or my company's money.

I'm saying "customer" here, but you might substitute that with "the person who really needs / cares about the account," because that person, in my estimation, is rarely the software developer. Unless I'm developing an app for myself, I only care about that API because someone else needs me to. And even when I'm developing for myself, I hope it gets to a point where I need to hire someone to care about it on my behalf, so I can focus on more important things.

The typical signup process for me goes like this:

Typical API signup process, described in list below.

  1. Me: If I already have an account, sign out.
  2. Me: Sign up for the service. Find what I need to integrate with the API. Note the steps I perform.
  3. Customer: Signs up for the service, with me providing the steps they'll need to take.
  4. Me: Ask my customer to give me the info I need, or grant me access if that option is available.
  5. Customer: "I can't figure it out, here's my login info, find it please."
  6. Me: I find the info, and tell the customer to reset their password. I doubt they ever do.

You're offering the service, yet there's no "you" in that process.

Here's the process I'd like to see:

A better API signup process, described in list below.

  1. You: Tell me I can easily transfer the account (or project or access keys) before I bother to sign up
  2. Me: Sign up for an account for myself.
  3. Me: Get everything working.
  4. Me and You: If I know my customer already has an account, provide a place for me to enter my customer's email address. If you offer more than one thing I'll need access to, let me indicate what I need for this project.
    • You: Send detailed instructions of to grant access to my needs.
  5. You: If my customer does not have an account, you send them detailed instructions for how to sign up and what they'll need to know to get value from your service.
    • Customer: signs up for their account, indicating they are actually working with me.
  6. You: Hook up our accounts, with me transferring ownership of that "project" to my customer.

There's a lot less of me and my customer in that process, and a lot more of you. It's certainly more complex, but it's simpler for the people who matter: your users.

Remember, the software developer is often the one who makes recommendations as to which products to use. Make it easier for me, and I'll be more likely to choose your service over a competing one.

post scriptum side note: I used Lucid Chart to do the flow charts. I really like it, but given how rarely I've wanted to diagram online, I don't see myself becoming a paid subscriber. What do you use?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

Hi Sam,

we're completely with you!

I'm working on an API marketplace called "Mashape" which will have permissions for each API (like github does) so that you can manage multiple access.

Will love to get your feedbacks on this, once ready.

cheers,
aghi

Posted by sinzone on Jan 27, 2012 at 06:53 AM UTC - 6 hrs

Cool! In fact I was wondering to myself if there's a business to be made out of helping you manage this stuff, but I didn't put enough thought behind it to get anywhere.

http://www.mashape.com/ looks pretty cool. Now that I think about it, I wonder if this is related to what http://apigee.com/ does? I haven't looked into it aside from their home page, which isn't all that helpful in explaining to me what they do.

Anyway, I'd like to explore when you guys are ready (and when I make some time).

If you don't mind my asking -- do you have plans to monetize it already? And if so, are you thinking on the publisher or consumer side? (or both?)

Posted by Sammy Larbi on Jan 27, 2012 at 07:27 AM UTC - 6 hrs

This is definitely how it ought to be everywhere. Well said.

Posted by Jim Gay on Jan 27, 2012 at 08:21 AM UTC - 6 hrs

Yes.

Do you have an email, where I can explain you these stuff privately?

thx
a

Posted by sinzone on Jan 27, 2012 at 08:54 AM UTC - 6 hrs

Tell me about it!

The easiest thing, which I try to do, is to set up a generic email address at the client's end do I can sign them up away from anyone named individual, either with my company or theirs.

Posted by Adrian Lynch on Feb 16, 2012 at 09:21 AM UTC - 6 hrs

I do the same thing if there's a bunch of new accounts to do, like right now I've been working on supporting a bunch of different payment gateways, so I asked them to set me up an accounts@example.com address to use for all of them, which they can just change the password on when we're done.

Posted by Sammy Larbi on Feb 16, 2012 at 10:35 AM UTC - 6 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and C++ (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (75)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (7)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner