The COCOMO system has within it a model for estimating the time to write software. As time is money, you then also get the value of the software from the perspective of “how much would it cost to have someone write it”. The current formulation of this model is the COCOMO II which has a rather nice web tool.

With this web tool, one can go from an estimation of size (you don’t have an estimation, you’ve got actual numbers of how big the code is…) and get the estimated planning, testing, and development costs.

Assuming 20k sloc (source lines of code) and a value of $10k/month for developer (and all other things being nominal) you get an estimated time of 79.3 person months to do it (remember, this is planning, construction and testing) for a value of $793k.

This value should be considered to be the minimum of the worth of the code. The actual value would be higher because it generates revenue and is the core intellectual property of the potential company.

Don’t confuse your time spent on it for what it’s worth. You also had the idea, designed and risked your time in order to built it. This is way beyond the cost of a hired programmer.

As of now, you should own 100% of the startup. It’s up to the rest of the potential partners to show what they’re worth. I would make those share contingent on producing something as well (sales, marketing, industry contacts, additional coding, etc.).

Starting Value, Ending Value, Selling Fairness

You may save yourself time and heartache over this negotiation if you consider the code in relation to what will be needed for your MVP (minimum viable product). If the code is half the MVP, for fairness you need something for it. If the code is 10%, 5%, or even as little as 1% of the effort, it will matter a lot less.

If you do demand money or greater equity (hmm, that sounds like an oxymoron), be sure you can do a good job selling it from the fairness perspective in a way that can endure through what may be many challenges along the way to selling the product.

Also, consider things symmetrically. Will your partners also write code and can they or will they catch up to or exceed your contribution? How much will you pay your partners for their interest in the resulting code if the business ends? The tone and expectations you set now will in large part set the tone and expectations later.

Software Engineering Economics

I consider Dr. Barry Boehm to be the father of software engineering economics. Among his accomplishments was to invent COCOMO, to propose the Theory-W method of managing projects, and to create a model of software development models called MBASE. His models discuss product models that describe what is or has been built (like UML diagrams), process models (like Scrum, waterfall, etc), property models that describe attributes of the product or organization (cost, schedule, dependability) and success models.

Success Model and Potential Exit Strategy

You should certainly be thinking about whether your success is based on something formal like Theory-W or something informal like IKIWISI (I’ll know it when I see it). The success model might also help you set expectations for how much time and effort will go into your start up, what criteria you use for go/no go, needing to pivot, selling or closing the business, and the distribution of assets both in event of success or failure. My grandfather was pitched some securities years ago that had a name like “Silver Screen Limited Partnership 7” that were essentially funding for a Hollywood movie that began before the movie, then ended after the movie had it run in theaters (this was pre-DVD days). If I were you, I would make sure my start up was not a lifelong commitment before it started.

A Prototype Is Not a Product

One of the first Boehm papers I read included a diagram that graphically compared a prototype to a product. It used a square for the prototype and a grid of squares three high and three wide for the product. Depending on your sense of confidence vs. realism, you might either dismiss this notion or start recollecting past projects where the dimensions of the product were 25 or 81 or 100 times the cost and effort of the prototypes.

Valuing Your Unique Contribution

To value your code in the context of the start up, you should probably also value your role and its uniqueness to the start up. If you are the developer and your partners are the financial backers or salesmen, you are kind of like the proverbial pig and they are the chickens going into business for a restaurant that serves breakfast. They risk little until they write a check, and may perhaps work comparatively little until there is something to sell. If you are each developers, potentially if they have no code to put in the pot at the start, it might turn out to be a very lopsided venture. To the extent the movie “The Social Network” portrays things correctly, there is a hugely successful start up that had partners who did very little who put in very little effort as the product was being made.

Starting Up with Start Ups

Be really careful how you bind yourself to partners for a start up. Work up an operating agreement that covers as much of what might happen during the life of the start up as possible. Consider scoping very narrowly, and following a lean start up model. Find safe ways to try out team projects. School is a great way. Some universities and other sponsors have created things like Rapid Start Up School. A very widespread method of getting a taste of the what a start up might be like is to participate in a Start Up Weekend. There are community and commercially sponsored incubators and coworking spaces. My limited experience occurred at places like Gangplank (I enjoyed their very inexpensive program for Start Up Weekend) and Cohoots.

Use Protection

You should always protect your self legally, financially, and physically. Criminal and civil liability can happen in connection with a start up. If the business borrows money or hires someone who cuts their finger off, you could be stuck with some bills that are hard to pay. You need to use sound accounting procedures and may need some insurance, and you must protect yourself and your partners from finding themselves on a slippery slope.

A Few Cautionary Stories

While it was not a start up, I knew an organization that permitted a person who was out of work and was under financial stresses to be their treasurer. He co-mingled the funds from ticket sales for a banquet for about five hundred people with his own bank account. He may not have thought he was stealing, but he definitely used poor judgement. When it was clear the money was gone, there were ugly problems with the person being prosecuted for embezzlement. The organization had insurance that permitted the banquet to be held, but if they didn’t those 500 ticket buyers would have been left holding the bag.

Another case I know had a casually begun Limited Liability Corporation turn into big hassles. There was a judgement against one of the partners and when it was hard to collect, attorneys sent a process server to the home of the partner who had forgotten they signed on for the company. There were claims against the partner and legal responses were required. After visits to the court and seeking legal advice, the partner took care of it, but these headaches often don’t go away until real money comes out of someone’s pocket.

Work Diligently, and Do Due Diligence

Team building and finding the proper partners is extremely important. Larry Page talks about spending a long time looking for partners to found Google.

Value it the same you would a “real” product:

What is the replacement cost?:
If there’s no comparable product – what would be a cost to hire someone to re-do it from scratch? What would be the cost of working around some IP/patent contained within?
If there is a comparable product – in what ways is your product better, in what ways is it worse – what is that difference worth?

The “sunk” cost – the time you’ve already spent and can not “un-spend” should be irrelevant to your decision.
Even future “costs” are not that relevant to the price/value – things can be worth more than what they cost to build(e.g. Mona Lisa is worth more than labor+paint+frame+canvas+30% margin)

Ohloh have a wiki article on how they calculate cost for the projects they track. It links to a Wikipedia article that seems thorough enough.

Ohloh wiki

I hope that this helps.

If these are friends, why don’t you just split the worth of the company evenly? Statistically speaking your startup will fail so it won’t matter. And if you are wildly successful, well, you’ll still have lots of money so it won’t matter either.