Fog Creek Software
Discussion Board

Software Startup Books

Could anyone recommend some good reads on starting up your own software firm?

I'm interested in ones that describe the problems and issues commonly encountered, and suggestions of what to do to. Really, a "How To" book as opposed to a touchy feely warm fuzzy one.


Anthony W.
Sunday, April 27, 2003

This website might help

Sunday, April 27, 2003

Try "Hard Drive" it goes in-depth into the start of Microsoft in the late 70s.

Another piece of advise for start-ups is work out straight away how you are going to find customers.

It's more important to find customers than make your software perfect. I know that sounds bad, and I'm not advocating bad software, but so many start-ups die due to lack of income. If you don't like the idea of marketing, cold calling, and advertising then I would re-think becoming a start-up.

Matthew Lock
Monday, April 28, 2003

Here's some advice right here. It was prompted by the reference to cold calling above.

Cold calling is not a way to start a software business.

The way to start is to have some experience in some sector, and along with that expertise, and to switch over from contracting to selling your service as a product. This leverages all your knowledge, capabilities and contacts.

Where you start is that the next time you start a contract job, you cross out the clauses about the recruiter owning your work.

Be firm about it. They will bluff and tell you there's no option. But there is. The employer will have selected you, and we're presuming you are actually pretty good. So be prepared to walk away, make sure the recruiter signs your changed contract, and insist that this is passed on to the employer.

That's how you start a business. From then on, the value of your work accumulates to your benefit and you start charging annual licencing fees, taking charge of quality and updates, and you're away.

Monday, April 28, 2003

I'm surprised this has actually worked for you. I would never hire a consultant who refused to let me own the work I paid for.
What *is* up for negotiation is allowing the consultant to retain a license in the software and perhaps negotiate a royalty for his selling it in the future.

At this stage the wise consultant will retain experienced counsel to advise on the contract negotiations that follow.

But if I pay for the work, I own the result.


Monday, April 28, 2003

I just recently listened to a tape of "The 10-Minute Internet Manager", and highly recommended.  The author was the VP of Sales at and CEO of, so he knows what he's talking about.

Brent P. Newhall
Monday, April 28, 2003

I agree cold calling is not a good way to sell most software, but you do have to sell it. I was consulting, and wanted to make the move into selling products rather than my time, but I knew that I had no intention of (nor the ability to) be a one-to-one salesman type.

My solution was to find a way I could sell enough of my product to make the company work, without having to make personal sales. I did this by advertising and selling it online. I strongly recommend you also figure out realistically how you will sell your software and to whom before worrying about anything else.

Figure out who your customer is, how you will reach them, and what you will say to convince them to buy from you, and then buy a book about the details of starting a business.

Best of luck- it is definitely worth it in the end!

Monday, April 28, 2003

"But if I pay for the work, I own the result. "

Sure boss, you the boss. What sort a code you want me to write today boss? You think I stould start with a line? What sort of line should I write boss?

(The point of this is that the common law is that if someone is not an employee but a contractor or consultant, working without detailed direction as to what to do, they own the results. In the case of software, since you paid for it, you are the one who gets a license, but the creator is the owner.)

Ed the Millwright
Monday, April 28, 2003

Re: Ed the Millwright and Philo's comments on code ownership...

Generally, in software contracting, *all* clients will ask that you sign a contract conveying all IP rights to them. True enough, the common law would allow the contractor to retain ownership. But in practice the vast majority of clients want to own anything that you do on hours that you bill to them.

This may have not been the case years ago. I know some lucky (and cluelessly spoiled) shits that parlayed contract jobs (where the client had no interest in the IP) into product companies. There may have been opportunities around like this 10+ years ago. But today,  post-internet gold rush, I doubt that even the smallest and least sophisticated client will fail to have you assign all rights to them in exchange for payment.

As a practical matter, the only way I could see to get around this would be to charge the client such an attractively low price that they can rationalize that your work is coming to them at almost product level pricing, and therefore they would handle it more like a product acquisition.  However, no matter how good a deal it is for them, the client may decide otherwise.

I know contractors who did this sort of thing 10+ years ago - they built "practices" upon recycling of code developing during custom work and would carry the same business application around (with tweaks) to new clients.  I have mixed feelings about this. The guys I knew that did this as a matter of course *never* released source code to the client either. And these guys were small time operators, so concepts such as "source code escrow" were 5 levels of abstraction above their thinking. If something happened to the consultant, there goes the client's entire investment.

Bored Bystander
Monday, April 28, 2003

> Cold calling is not a way to start a software business.

Have you ever actually tried it? Do you know how many leads you get from it?

Sure it might not be the most tasteful way to market, but you have to sell you product and there's no better way to get some leads in a single day than a round of cold calling.

Anywho my original point was that marketing is a lot bigger part of running a software company that many people who want to start "start-ups" think. I learned this myself the hard way.

Matthew Lock
Tuesday, April 29, 2003

I have been including the following in my most recent contracts without any objections from clients:

Mr X. retains ownership of his software library files and
modifications made to those files while carrying out work for the Company Y.

Mr X. grants Company Y a non-exclusive license to use the
Mr X's software library files as they wish.

Matthew Lock
Tuesday, April 29, 2003

I think it was Larry Ellison who said that:

"It is better to have average software and a great marketing team, than a great product and an average marketing team"

Prakash S
Tuesday, April 29, 2003

As in Microsoft versus Borland? ;-)

Frederik Slijkerman
Tuesday, April 29, 2003

"There may have been opportunities around like this 10+ years ago. But today,  post-internet gold rush, I doubt that even the smallest and least sophisticated client will fail to have you assign all rights to them in exchange for payment. "

I don't know what you are doing but I know at least 5 people  (myself included) who keep all rights to source code and then incorporate changes back into a common library of code, then shop the improved application around to other clients. I plan on tightening things up and selling a product license with support contracts in the future. I don't know why this seems distasteful or bad business practice to you. This is pretty much how any successful software company (microsoft / oracle) started out.

Tuesday, April 29, 2003

If you are interested in building a real, lasting business, this is the book:

Gordon Bell was the VAX guy at Digital in the 70's and has done a lot since then.  The latest edition is from 1991 (so all the hype of the 90's is not in there). There is a fair amont of hokeyness (if that is a word) in the business pseudocode and things like that in the book and maybe it is a little focused on hardware businesses. Having said that, if you are willing to go beyond recipe, "Building SW Business for Dummies," type books, you will learn so much from this book.

I don't recommend following his format for business plans though. There are better options out there.

Tuesday, April 29, 2003

While there are *some* good books out there, there really isn't any *great* books on how to start your own company.  Starting a company is sort of like learning how to ride a bike or drive a car.

While you can glean some information on how to ride a bike or drive a car from reading a book, the task is better suited to learning by doing.  And the same goes for starting your own company.

What I would recommend doing is to concentrate more on finding and utilizing information from people instead of books.  Find experienced business mentors (emphasis on the plural) who have started and ran successful companies, and then bond with them.  There's lots of retired executives that are happy to help someone out and give some free advice.  If you don't know of anyone off hand then initially try to start out.

And finally, if you still insist on finding books, then probably the best types of books to read are ones that are based on a sort of story, history, or case study about companies.  ie. there are several books written about the trials and tribulations of startups like eBay and Amazon.  I usually find nuggets of information in those types of books more than in the regular "teach yourself how to create your own in 24 days" type of books.

Thursday, May 1, 2003

This may be helpful:

  Business Basics for Engineers - Topics List 

Rick Tang
Friday, May 2, 2003

*  Recent Topics

*  Fog Creek Home