Business Models

edit topic

Agile consulting - hours or tasks?

Published October 21st, 2005 edit replace rm!

Now I am starting back doing consulting on a freelance basis, I really want to reexamine the business model of consulting.

I have always felt that the hourly charging is a pain. I don’t think it is fair for neither the client nor the consultant. The agencies of course like it as that is their main way of making money.

Let say there is a task. Build up a simple CRUD web page to go into a database. If you put a inexperienced guy on it you will probably end up paying less of an hourly rate, but more hours.

If you put an experienced guy on it he will charge you more per hour, but do it in fewer hours.

So who is cheaper? An inexperienced guy is at probably at the maximum going to be 1/3 the hourly price of the experienced guy. If you are talking the same regional area probably its more like half the price.

An inexperienced guy though may not know the short cuts or may have to spend an awful lot of time in google, where the experienced guy can do it quicker.

With something simple like a CRUD system like we mentioned above, an experienced guy can probably do it around 5 times faster than the inexperienced guy if we are talking something like Java.

With Rails the difference on CRUD wont be as much (can you spell scaffold ??), but in other areas the 5 times faster is probably also true.

So in other words the client ends up paying more if the client choses the inexperienced programmer and the experienced programmer probably is not paid his worth if he gets picked.

Iterative development to the rescue

My idea is that if you are developing using agile methods anyway you have a nice iterative process you can use.

An iteration is such a small complete task that a developer should be able to estimate how long it would take him. How about if one or more developers bid on each iteration? If accepted he has to do the iteration for that price.

This gives the client a certainty and makes it easier to budget. It also lets the experienced consultant push himself and do the work quicker.

It’s obviously not everything that can be done this way. There are certain more traditional consulting tasks that are better suited to hourly rates.

I would like to work with a client with maybe a couple of other developers on a rails project using this method. Have a look at my Bio for more info about me. You can also email me at [email protected] for more.

Also if you would like to be part of a small team of rogue agile coders with Rails, Ajax, CSS or other applicable skills that could work on projects together, send me a shout out as well.

The business of being a Solo ISV

Published October 17th, 2005 edit replace rm!

John over at Daring Fireball has an interesting piece called The Life, where he talks about the economic realities of being a successfull one man ISV in the Mac world.

It is based around the NewsGator’s recent purchase of Ranchero Software, which apparently has caused a bit of frustration amongst Ranchero Software users.

He mentions many of the hard realities of being an ISV. Like support costs:

But selling software isn’t like selling books. When a book takes off and climbs the best-seller charts, that’s just money in the author’s pocket. Each software sale, on the other hand, comes with incremental support costs.

Read the full story. I think it’s still a worthy business to be in, besides the fact that it does include a lot of work. I also have to add that I think that most of the best software in the mac world comes from Solo ISV’s and I hope they keep coming up with all the great innovative software that we all know and love.

$5M for fraud proof mobile credit card authorization?

Published August 29th, 2005 edit replace rm!

In Business 2.0 John Occhipinti from the Woodside fund wants to pay $5M in venture capital for a fraudproof credit card authorization via cell phones and PDAs. I found this via Nathan’s hilarious Elevator Pitch generator.

Lets first look at why John wants this from us:

Credit card fraud is more rampant than ever, and consumers aren’t the only ones feeling the pain. Last year banks and merchants lost more than $2 billion to fraud. Most of that could be eliminated if they offered two-part authentication with credit and debit purchases — something akin to using a SecureID code as well as a password to access e-mail. Occhipinti thinks the cell phone, packaged with the right software, presents an ideal solution. Imagine getting a text message on your phone from a merchant, prompting you for a password or code to approve the $100 purchase you just made on your home PC or at the mall. It’s an extra step, but one that most consumers would be happy to take to safeguard their privacy. More important, Occhipinti says, big banks would pay dearly to be able to offer the service. “It’s a killer app no one’s touched yet,” Occhipinti says, “but the technology’s within reach.”

Let’s identify the problems with what John wants:

His ideas as he says is that the merchant sends a SMS with a payment request to your phone. You then perform some sort of digital signature to authorize it and the payment goes through.

This is already very doable and I have seen lots of similar applications from either smaller entrepreneurs (eg. Luup) in Europe or from various kinds of mobile operator funded initiatives (these always fail though for a variety of political reasons). For the full lowdown on all of these just take a stroll over to Scott’s Payments News Mobile Payment page.

While reading through the latest on Scott’s site I came across UPaid, which looks fairly interesting. They have just got the deal for a massive roll out for Visa CMEA (that is middle eastern region). I’m sure there a loads of startups doing this as the technical side of this is not particular hard. PayPal actually even was originally founded as a similar style application for Palm.

About Credit Cards. Now in the US and arguably for international cross border e-commerce the CC is king. In regional or national markets outside North American and the UK it is arguably not the only horse though.

The CC was a brilliant 1950’s style design, which just is not compatible with open networks in a secure way. This is why lots of contractual padding is necessary around it. Did you every wonder why you need a credit check for a merchant account or for a debit card? Well this is the banks who well understand the risk embedded in an unauthenticated payment device and they need to place the risk somewhere. All the rules about who is liable for what in case of fraud are also based on this.

The CC networks are basically multi party electronic networks, where the only thing circulating are account numbers and amounts. There is no digital signatures or anything like that. When you sign a cc slip, the merchants bank keeps it on file in case of fraud. It never gets sent to the card holders bank or anything like that. What all of this means is that every link in the CC network is insecure and open to fraud. Just because you secure the link between cardholder and the merchant doesn’t secure all the other links in the system, just see the whole CardSystems case as the most extreme case.

The problem with all of these rules and legal safeguards around the card is that the end user has so little liability with the card and is happy with that. All of the attempts by the credit card operators to move more liability on to the card holder by using improved technology have so far failed. See MasterCard SecureCode and Verified by Visa.

If these massive programs have failed, why would a $5M startup offering the same thing but in a mobile package succeed? They are up against the exact same forces.

The only that will improve the security of credit cards is to get rid of the non authenticated credit card completely. This does not mean getting rid of the credit card, but it does mean that you couldn’t just enter your credit card on a web form and over the phone. This could not just be a regional or an optional initiative it would have to be international and compulsory. If this was made John’s company could provide an ideal system for authenticating credit cards for phone orders.

Now the merchants and their banks (the acquiring banks) would love this to happen and have been pushing for it. Currently they are the only ones who have been affected on a large scale by CC fraud. The other side of the transaction are the card holders and their banks (the issuing banks), who until recently have had very little incentive to change anything. The reason for this is as mentioned above, the card holder has little risk with credit cards and likes the convenience. The issuers are in a very convenient business and none of them want to rock the boat by say requiring Verified by VISA for internet transactions. So nothing will happen until the cardholders and issuers get part of the liability of the insecure system.

I believe that there really is no good way to fight this essentially internal politics within the card associations. The only people who can change these rules are the associations themselves.

It’s much more interesting to work outside of the credit card system and in reality outside the banking system as they really have no incentive to give you what they perceive to be their own business.

The traditional abstraction away from the banks is the electronic money system, which has it’s own money (or gold) backing the funds in circulation. This is relatively simple to create. You have a bank account, a Ledger, a web front end and customer service staff. I was personally involved with one of these. The big problem here is lack of convenience for the end users, who have to “load money” into the system somehow, before they can use it. With roughly $37 Million in circulation E-Gold is pretty large now, but it’s still no where near as big as PayPal for these same reasons.

Many mobile payment systems have wanted to get rid of the reliance on banks by linking into the mobile operators billing system. This has almost always failed as for some reason the European and (even worse) the US operators have shown to be almost more conservative than the banks. It seems like South Korea and Japan have some interesting mobile operator led payment systems that are taking off. But seriously can you imagine Vodafone or T-Mobile do anything like that?

The only large player that is on the market today that could be used to bootstrap a new system is PayPal. I am sure they have their own plans in this area, but this is where I would see something interesting. For a smaller but growing player I would look at Skype as a very possible player. They have a very widely deployed PKI system and a currently untradeable currency of their own called SkypeOut balance.

I’ve written about payment systems before and have strong opinions on it. The last startup I was in was payment related and I’m more than likely going back there at some point, once I’ve cleared my mind a bit with StakeItOut.

I have some ideas that may or may not work to get past the idea of a stored value electronic money system. However I’m not quite ready to spread them out yet ;-). Probably in the new year if I can find someone with equally large hairy cojones who also has an interest in disrupting things a bit.

Flickr on changing directions

Published August 8th, 2005 edit replace rm!

Interesting inteview at Adaptive Path with Flickr’s Eric Costello about how Flickr ended up going down the photo sharing path and away from their original idea for an online game.

The first early version was really a chat site…

It wasn’t a photo sharing site, so much as it was a place where you could go to chat and talk about photos. But none of that activity was stored in any asynchronous way – there were no Web pages that hosted the conversations people were having about photos, it was all just real-time.

Later on they started adding asynchronous featureas as he call it like web pages, comments and tagging…

As we started adding features to the site itself, like pages that hosted the photos so that people could visit them at a unique URL, we had a lot more success with that. People responded to it, and the site began to grow. So our energies tended to be dedicated toward enhancing that aspect of the site.

It’s a great lesson that sometimes it’s important to follow the users. PayPal started like this as well. The original protype as demonstrated to me on a beach in Anguilla by Max Levchin in 98 or was it 99 (can’t remember which) was a Palm application, where you could beam money to each other for say splitting a restaurant tab. Within a year they had moved to what we now know and love as PayPal.

I have done this myself on many projects. I started doing CaribWeb as a Caribbean tourist portal back in 94, however the discussion forums TravelTalk took a life of themselves and lived on for a good 5 years after I shut the rest down. Making me a fair bit in advertising revenue throughout the years.

If I was to create a new payment system...

Published June 22nd, 2005 edit replace rm!

There is a lot of buzz going on right now about payment systems. First with the huge credit card theft which was seriously just waiting to happen (and will happen again), secondly with Google’s new Payment System which could have the potential to be interesting.

This subject is dear to me as I have spent more than my fair share of time in the payment system business.

So if I was to do it again (and I probably cant stay out of it completely) I have some ideas about it.

First of all these are the things I and google should do:

Google have an opportunity to do many of these things. In particular the first point about the banking system.

The banks will do anything they can to kill your business as a payment system. Afterall they have had a near monopoly for years in handling payments electronically.

Even though they do NOT handle the majority of payments in the world. Most payments are still cash and are handled easily and simply without the interference of banks.

Google cashflows

Google has the advantage of a large source of revenue through Adwords as well as a major group of small business Adsense partners.

This means they have two huge internal sources of cashflow that aren’t currently integrated.

Step 1. Linking the cashflows together to create GoogleBux

Linking those together would be the first step in the puzzle. That would simplify their operation and costs greatly. All they would have to do is to add a simple book entry system to their Google Account system.

Step 2. Allowing transfers between members.

How to turn this into a payment system then? Simply allow people to transfer parts of their GoogleBux balance to other users.

Now we have a payment system with probably a huge circulation of funds within the system.

Step 3. Cutting the cord to the banks

They currently use the banks to receive payments via credit cards to pay for Adwords. They Adsense members using antiquated paper checks or electronic fund transfer if you are lucky enough to have a US bank account.

Personally I would rather be able to spend my adsense money on adwords or other services than wait a year for $100 check that my Danish bank will then charge me $30 do clear.

Also what if I could go transfer my 67 GoogleBux to a friend in exchange for 400 dkk cash.

Someone might even make a business out of it and charge a 2% markup on exchanges to the banking system. Thus outsourcing the integration with each countries banking system to the free market. Google would save tons of moneys, headaches and legal problems.

At Reboot I talked with Malthe Sigurdsson from Skype about this as a solution for them allowing people to buy Skype credits in strange places where people don’t have credit cards. He said that they would like to do something like this, but fraud is a huge issue.

I think though that the clever people at Skype and Google could probably come up with some clever technological solutions for this. Such as not mixing hard and soft money

Join my Blockchain newsletter

Receive all my latest articles on Bitcoin, Ethereum and building businesses using Blockchain technologies.

I will never send you spam. Unsubscribe at any time.

About me

Pelle gravatar 160

My name is Pelle Braendgaard. Pronounce it like Pelé the footballer (no relation). I live in wonderful Managua, Nicaragua. I work with Clojure, Bitcoin and Ethereum.

More about me:

Other under Business Models

Popular articles