SiteMap
Page Bottom  QKW Business Plan

This is a menu of the topics on this page (click on any):
The Product   
The Market   
The User Interface   
Who Gets the Value We Create   
Trust that must be achieved for our proposed vecture to work The Premises    Trust needed by all involved    Trust needed by the geniae    Trust needed by the steward    Trust needed by the angel(s) ?    How the agreement might work   .

This is to provide an introduction to this business opportunity in much the same way I would do it if I could guide you through this CD myself. But this is actually easier because you can click on the links. I can explain more when we get to talk and I'll be able to hear your thoughts. (Please understand that the information on this CD has evolved over the last couple of years, so much is out of date, and there will be broken links where I've reorganized things. (In fact, Bill Parke's TruLink says there are 859 pages with 12598 links of which 91 are broken. With a little effort, we can eliminate all broken links.)

The Product

Let's define this business opportunity as providing software for the real estate development industry. Specifically, that means the sorts of projects illustrated in the following two pages: ProCash and Landev.

I should also emphasize that there are other software products that serve operating properties better than we will (in the near term). Our focus is on real estate development as opposed to operations. I don't think there are any really good products that serve the entire real estate development industry. Excel is the software that is most frequently used, and it is used because many projects have idiosyncracies that require a great deal of flexibility. Excel provides the flexibility needed and it does so in a highly acceptable user friendly format. The difficulty with Excel is that one must develop the logic and that is rarely done in a way that is flexible, adaptable and error free.

We have that flexibility because from 1969 thru 1990 I consulted to a broad range of the most sophisticated projects in America and accumulated all that logic in two computer models. I never bothered with a user interface, but whenever a project presented something I hadn't encountered before, I took the time to build it into the generic model rather than build a little adaptation on the side as many people would have done. The projects for which I built models included shopping centers, office buildings, industrial buildings, market level housing, subsidized housing, homebuilding, cable TV ventures, ski resorts and large scale community development projects like Columbia, Maryland.

The Market

This is a very big market. Such projects totalled about $300 billion in 1998. In determining our market, we might like to pull out of that number total expenditures for development services for which we can help. That will include some of the financing and syndication fees, feasibility study expense, and developer overhead. If we look at total construction in 1998 and put it into equivalent terms by adding an estimate of land and development fees, we get the $300 billion per year. Taking 1% of that, then taking just a third to be cautious, we get to a market wherein we can directly help of $1 billion per year. That's a rough estimate of the annual cost of MBA type persons sitting at desks and doing analysis to justify, plan and manage real estate development.

The User Interface

Some say that "today it's all about the user interface". The success of Excel certainly affirms that. But I believe that we have tools now that enable us to build a compelling user interface that is far more flexible than Excel and where it will be far easier to get new projects up and running.

I've had many conversations with systems people smarter than I am about how to create an appropriate user interface. All such conversations are about our challenge to integrate three things.

The problem is that inevitably I am invited to "map" the relationships between data and report or grid formats. I don't think a pervasive cell mapping approach is going to work, though cell-by-cell mapping will sometimes be needed. I think we need an approach that is natural to APL and to the way we think rather than a rigid approach. We need to think in terms of arrays. (And, borrowing language from Chris Lee, we need to think in terms of self-describing data which he calls PVP's -- property value pairs.)

Let's create some more language.

  1. A "project" is a real estate development opportunity that is being considered for investment.
  2. A "model" is an "economic model" by which that investment opportunity can be evaluated and/or managed. A model can be used to produce many "runs" or "projections" using different financing, cost or revenue assumptions.
  3. A "generic model" is a tool like ProCash or Landev that can be used for a wide variety of projects. Sometimes I call these "black boxes".
  4. "Inputs" are APL arrays (never more than rank 2) in which "assumptions" can be expressed. ProCash and Landev use 56 input arrays; ProCash uses 29 of them; Landev uses 34 of them.
  5. "Outputs" are APL arrays (never more than rank 2) in which one of our 2 black boxes has projected the implications of the input arrays.
  6. "User Defined Formats" are very important, and they also never need to be more than rank 2.
  7. Inputs, Outputs and User Defined Formats can all be expressed as PVP's.

I think you can see where this is going. We need a user interface that is defined by PVP's and not by the mapping of cells. Cell by cell mapping will be done under program control. This should be natural for us since we come from APL. I have defined what I think is a standard format for a PVP (in the context of ProCash & Landev). While I'm sure it will get redefined as people smarter than I am get involved, but for the moment I'm calling it an M1M. Sometimes we will want to string together a bunch of M1M objects and then I call it an M3M. An M3M can be quite a complicated document with many headings, tables, charts, paragraphs, etc. Both are PVP's. Either of these data formats can be rendered in several modes of interactivity and all can be helped with high level objects (Lescasse or other).

This CD has examples of the use of M1M and M3M rendered in HTML and in NewLeaf.

Who Gets the Value We Create

While this is not a good time to be looking for venture capital money, let assume we'd be successful in seeking it. Here's why I don't want to seek it. Let's divide the financing of a successful business into several stages (this illustration is greatly oversimplified; it is meant only to be descriptive).
  1. First somebody has an idea (or some technology) on which to build a business, but he doesn't have clients or a believable business plan. If he needs money at this point, it is from an "angel". If the business really looks promising and he really likes and trusts the entrepreneur, the "angel" might put up $100,000 to develop a business plan and for that he might ask for up to 50% of the company.
  2. If the entrepreneur has a credible business plan and some clients where he can show that his approach works, the investor is still probably called an "angel", but he might put up $500,000, still asking for up to 50% of the business.
  3. If the entrepreneur has clients being well served by well qualified staff and revenue somewhere in the hundreds of thousands of dollars, he might ask for $2 million from a venture capitalist, still giving away up to 50% of the business.
  4. Oracle skipped all those steps and didn't seek venture capital until it could ask for very large sums of money for which it gave away relatively small shares of the business. Thus the talent that really built the business got most of the value created in the business.

I want the talent that creates this business to get most of the value created in it. I think there is a lot of work to do and I know very well that I am not qualified to take the technical lead. I'm hoping my having created the black boxes, my knowledge of the industry, and my total commitment to business development and marketing preserves a good part of the value for me, but I'll be happy if the technical, administrative and marketing people who really make this happen get 50% of the value we create. I'd like to postpone our inviting people in as investors as long as we can, and if or when investment is needed, I'd really like for it to be insider investment, not outsiders.

I think this is a good time to develop the sort of technical platform that this software needs. We have Eric Lescasse's Objects, a new APL2000 grid control with printing and superb report writing and charting software from Adrian Smith. The function "PhoenixDemos" in ProCash shows how I've starting using some of these. I think Windows is where we'll start, but the WWW should never be far from our thoughts. Everything we do in Windows should be done with an eye to how we can translate it to the web.

Trust that must be achieved for our proposed vecture to work

The Premises

Trust needed by all involved

Trust needed by the geniae

 (The geniae are the people who have talent I don't have and who are essential to making this business work.)

Trust needed by the steward

Trust needed by the angel(s) ?

 (if we need angels)

How the agreement might work

If this interests you, I'd like to talk with you more.

Site Map
Customers
Market Assessment per New York Times
Our First Niche Market - family income by block
Our Second Niche Market
Product Development Priorities
The Beginning of a Business Plan
Other

horizontal line
e-mail Page Top