Limited Paying Customers

If your building a niche product and using either the Freemium or the Freegrade business model, this might be an interesting strategy to quickly convert your non-paying users into paying customers and charge a premium while your at it.

The idea is to limit the number of paying customers you will accept for your niche product. For example, if your targeting a very small niche, you could limit the number of paying customers to something like 99.

That way:

• The non-paying users feel a sense of urgency to convert into paying customers, and
• making it exclusive means that you might be able to charge a premium and maybe in return also customize the software for the paying customers.

If your familiar with the psychology of persuasion, then you'll recognize this as an applications of the principle of scarcity .

I came up with this a few days ago and haven't come across anyone doing this yet, but I have a feeling it will work because:

• I think you can make more money by doing less, and
• doing less per product, frees you up to build more niche product to improve your odds of success.

Think it'll work?


Some References:

• Available for a Limited Time Only:
  
  

  The Long Tail world is built on scarcity. If you have valuable niche information, charge more for it and offer it to only a certain number of buyers. When you hit the number you set, pull it off the market. You might just find you made more money than if you had offered the same product to all takers for a cheaper price.

• Overcoming Bias: Scarcity
• In short supply: 5 ways to use scarcity and exclusivity to fuel sales and boost your bottom line
• Book: Maximum Influence By Kurt W. Mortensen
• Book: Influence: The Psychology of Persuasion by Robert B. Cialdini

The Freegrade Business Model

Provide free accounts with limits (on the number of things like photos, emails, users, etc. or on storage) with an option to upgrade to a paid monthly subscription account without or relaxed limits and maybe even additional features. Once you upgrade to the paid account, you must either pay to continue or stop using the application.

Works best if you have a product that users get hooked to and will pay to continue using once they have exhausted the limits. Interestingly, the exhausted limits are a good indicator that the user is hooked.

This is different from the Freemium Business Model, in that the differences between the free and paid accounts are in the limits and not necessarily in features alone. It is also different from the Free Trial Period Model that usually has a limit on time, which might result in prompting the user to upgrade to a paid account before they are hooked. I coined this term primarily to differentiate it from these models.

Examples: Wufoo, Flickr, Basecamp

The word freegrade is a portmanteau created by combining the two aspects of the business model: free and upgrade.

Being explicit about "unsafe" function

Update: I've dropped most of the ideas mentioned here.

I'm toying with the idea of prefixing unsafe functions in swx with unsafe_ (example: unsafe_swx_mapper_match). I like how this makes explicit the fact that I'm testing unsafe functions (example: test_unsafe_swx_mapper_match). This is similar to the use of the exclamation (!) suffix in Scheme and Ruby. If this works well, I might do the same in inertia.

Couple of other things you might notice if you haven't done much programming in PHP are the swx in the function names that acts like a namespace for swx and the underscore (_) prefix in some function names (example: _unsafe_swx_mapper_pattern) that marks them as private functions for internal use only.

Continuous Software Maintenance aka Agile Software Development

Its widely accepted that about 40-90% of the total cost of an application is incured after it goes into production, the phase that is traditionally called maintenance.

When I'm doing Agile, not the practice-oriented farce kind, but the values-principles-oriented real kind, I don't build software in phases. I develop software in a continuous flow of activities. When I'm doing this, it feels like I'm continuously maintaining the software instead of only maintaining it after its done, and that makes all the difference.

Procedural Programming is NOT a Bad Thing!

For way too long now, I've heard proponents of object-oriented programming describe badly written programs as "procedural", as if to imply that procedural programming is a Bad Thing.

Good design is possible using any programming paradigm, just as bad design is. Stop using procedural programming as a derogatory term!

I personally prefer multi-paradigm programming, so that I can use the paradigm that feels right for the job at hand.

We Don't Need No Version Number

When your delivering working software in a continuous flow, versioned in a DVCS, do you really need version numbers?

Rules-First Programming

From Just Ship, Baby by Kent Beck:

I’ve sneering dubbed this philosophy “Rules-First Programming.” I hope by naming this demon I’ll have power over him the next time he comes to sit on my shoulder. When doing things right becomes more important than doing things at all, I hope to recognize his peculiar smell, an acrid mixture of frustration, sanctimony, cowardice. “Rules First Programming,” I will say, “you better go sit on some other fool’s shoulder today because today I am going to ship.”

Right on!!

You Get What You Ask For (YGWYAF)!

From Lean Software Development: An Agile Toolkit by Mary Poppendieck, Tom Poppendieck:

People respond to the expectations of their management. Software development leaders will not flourish in an organization that values process, documentation, and conformance to plan above all else. An organization will get what it values, ...

Software Craftsmanships

From Lean Software Development: An Agile Toolkit by Mary Poppendieck, Tom Poppendieck:

New programmers start as apprentices to master craftsmen. As they become skilled, they teach other apprentices and eventually journey to work with other master craftsmen. Journeymen disseminate ideas and develop broad skills, eventually becoming master craftsmen themselves.

Intrinsic Motivation

From Lean Software Development: An Agile Toolkit by Mary Poppendieck, Tom Poppendieck:

Intrinsic motivation requires a feeling of belonging, a feeling of safety, a sense of competence, and sense of progress.

Failure is Inevitable

Failure is inevitable if you are part of something that you believe will not work.
Failure is inevitable if you are made to believe that you are not capable of doing a good job.

Don't Expect Perfection

There is a difference between setting high standards vs. requiring perfection down to the smallest detail (zero tolerance for mistakes). The former pushes people to do better. The latter kills initiative.

Encourage, don't nitpick.