Ask HN: How to price a website I'm building for a friend's company

Determine the demand for your product and price your solution right below the point where people will think you're charging too much, such that they would continue to use the old way of doing things.

The finding of that price is hard. So try to find it pragmatically. Ask questions like how much do you pay your employees to do this task? How many employees do this task, what is their hourly cost? How much time will the new software/website save those employees? How will revenue or profits be increased?

Your price should be what the market is willing to pay, not what you think your software is worth or how long it will take you to build the solution. If you're going to price the solution as a service with recurring revenue, make sure you can continually justify your value to your customers on an ongoing basis. If you want to build this solution as a one time custom project, price it accordingly to the value delivered, the cost of your time, your opportunity costs, and establish a rate for ongoing care and feeding of the code base before agreeing to build the solution.

First off, read tptacek's excellent answer over and over until you can recite it from memory. I have been doing freelance consulting for years and I know I'm going to steal a number of his ideas.

Second, here are some additional thoughts, based on my experience doing similarly-sized gigs for similar clients.

1) To start with, just to encourage you, this is a very doable project that can be very lucrative to you (>$10k), helpful to the client, and can open the door to a lot of fun side gigs. This is the best part of consulting.

2) When looking at your first side job, the temptation will be to come up with a price based on your day job's equivalent hourly rate. Do not do this. This is easily $100+/hr work. For a real estate firm, your app may be generating millions in revenue/cost savings over a few years, and although it's a simple little project to you, building a webapp is deep magick to a business user. Try to pitch and charge based on value.

You should know your costs/equivalent hourly rate, but only as a bare minimum so you are never working at a loss.

3) Based on the fact that this project is mostly rebuilding an existing Excel spreadsheet (Pro Tip: you can get a lot of business from simply "rebuilding Excel worksheets!"), it seems like you could spec it out enough where you could offer a fixed price. You can use tptacek's approach of quoting X days at $YYYY per day, or a total fixed price.

You always have the option of going hourly though. Some clients will prefer this, but it can limit your total compensation. You can charge $X0,000 - $X00,000 for a given app (remember: deep magick) but you can't charge $X000 per hour. Do quote high though. My favorite advice is "pick the most ridiculous semi-realistic number you can think of, then double it." You can always offer a discount for Friends & Family, New Customer, Summer Sale, whatever.

4) Be vague about delivery times if you cannot take 1-2 weeks off work to complete the project. But plan to have regular deliverables/signs of life to keep them on board. Think about mockups/wireframes you can deliver.

5) Ask for at least some of the payment up-front. This will ensure they are serious, and motivate you to deliver once you receive money. :)

Home these ramblings are helpful. Welcome to the world of Real Consulting!

> the temptation will be to come up with a price based on your day job's equivalent hourly rate. Do not do this.

To expand, remember that regular employment comes with way more 'compensation' than just the salary that a freelacing gig doesn't come with. As a regular employee, you get paid regularly, on time, based on hours, you get paid holidays, taxes paid, etc. A freelancer/contractor has much less certaintly and much more risk. Hence freelancers should be paid more per hour/day/week than a regular employee.

> Think about mockups/wireframes you can deliver.

Hint: Don't make the mockup look done. Use a mockup style that looks like drawing on a napkin (or even draw it on paper and send a photo of that paper). Non-techies think the amount of work depends on the amount of UI changes. If they see a pixel perfect photoshop image of a done web page, they could think that all the work is done.

Second the mockup point. Even mid-fidelity mockups have caused me all kinds of headaches. Perhaps that uncanny valley effect, but no one ever asks you to move buttons 5px to the left, or change the title bar colour from dark blue to a slightly darker blue with a paper sketch!

Balsamiq does a nice job for mockups, but doesn't constrain you to a certain style. I don't have any connections to the company, just have used it on a number of projects.

The bill rate for serious end-to-end web application development in a modern language, where the customer provides a loose spec and the outcome is "working, usable application" is somewhere in between 100-200/hr on the very conservative (low) end.

So, take your outside estimate of how much time the project is going to take (you think 40 hours; maybe make it 48), and pick a bill rate in the spectrum of 100-200/hr. Work that into a daily rate.

Provide proposal under the following terms:

* You offer to build the project on a time & materials basis, 6 days at a daily rate of ((100..200)x8).

* Prior to starting the engagement, you will complete a proposal with detailed acceptance criteria (app MUST do this, app MUST NOT do that, app MAY do this, &c). You'll interview your client (gratis, because you're a professional) to work out that acceptance criteria in advance.

* Should any of the requirements or acceptance criteria change once contracts have been signed, you'll accommodate by adding additional billable days to the project (subject to whatever scheduling constraints you may have at the time).

* Should they want to lock in additional billable days in anticipation of changing requirements out from under you, they can buy those billable days on a retainer (use-it-or-lose-it) basis at a small (~10%) discount to your daily rate. This (or some clause like it) allows them to pay you extra (ie, for days they buy but you don't work) to guarantee that if they change their mind about some goofy feature, you'll be available immediately to accommodate, and they don't have to wait 6 months.

* Your contract will specify a class of critical bugs (security, things that potentially lose previously-stored data) and a class of major bugs (things that make the system unusable). For a period of N months (maybe 12) after delivery, you'll commit to fixing critical bugs within N days, for free if they take less than N hours to fix, and at your daily rate otherwise; repeat (but with more favorable terms for you) for major bugs.

* For an annual fee of 20% of the price of the contract, you'll provide maintenance, which (a) continues the critical/major bug fix window past the N months specified above and (b) provides an annual bucket of K billable days with which you will fix non-major bugs; this is provided on a retainer (use-it-or-lose-it) basis.

The idea is simple: you want to:

(a) Give the client something that looks as close as possible to a fixed-price project cost.

(b) Not actually commit to a fixed-price project cost more than you have to.

(c) Turn the downside of long-term bugfix support into an upside of recurring revenue.

This is just a sketch, you'd want to tune these terms. You'll also want to pay a lawyer ~$100-$200 to sanity check the contract. (Your contract will look like a boilerplate consulting contract, ending in a "Statement of Work" that is a series of "Exhibits" [contract-ese for appendix] that spells out most of the details I listed above). Pay special attention to the acceptance criteria.

Remember also that you're liable for self-employment tax, which is due quarterly, not on April 15. You might also consider registering a Delaware LLC (~$100, online) and getting a tax ID, because liability gets sticky with software you deliver to make someone else's business work. You probably do not need to consult a lawyer about LLC formation; most of the trickiness of company formation is with partnership terms and equity, which isn't your problem.

Any reason for the Delaware LLC vs a (your resident state) LLC? I thought Delaware was really only requested for S and C corp structures accepting outside investment.

There are a bunch of little reasons that Delaware LLCs are easier to deal with; for instance, your home state may have a little dance you have to go through with running advertisements in the newspaper, or have weird rules about SMLLCs. Mostly, though, I just know that you can get a Delaware LLC and a TIN online in a couple days by filling out a couple forms.

Won't it be necessary to register your LLC as a foreign LLC in whatever state you are actually operating and be subjected to your states regulations anyway?

You certainly have to register as a foreign corporation in my state (NC), but state rules vary, so there may be less hoops to jump through for you.

I actually respectfully disagree with this advice. Delaware LLC's are expensive compared to most states (I believe mine was over $300 when I filed plus have high dissolution fees should you need to dissolve it or transfer it to another state plus annual taxes) and don't really offer that much compared to other states with much lower filing fees for a business just starting out.

The main reason Delaware LLC's are so popular is that the laws in Delaware are very business-friendly. However much of this doesn't realistically apply to a business just starting out. If you're Facebook it makes sense. If you're a one-man consultancy with potential liability in the less than $1,000,000 range maybe not so much. As always, this depends on many factors.

I know the counter to this is that if you are billing $X00/hour, filing fees for an LLC aren't a significant cost of doing business. I'm just offering this opinion up because if you are just starting out you don't really want to waste any money you don't have to. I'd talk to an attorney in your state before filing.

>> Your contract will specify a class of critical bugs (security, things that potentially lose previously-stored data) and a class of major bugs (things that make the system unusable). For a period of N months (maybe 12) after delivery, you'll commit to fixing critical bugs within N days, for free if they take less than N hours to fix, and at your daily rate otherwise; repeat (but with more favorable terms for you) for major bugs.

>> Turn the downside of long-term bugfix support into an upside of recurring revenue.

Excellent advice in general, but these recommendations are pure gold. Most people get this horribly wrong with their first few freelancing gigs and end up in bad situations when bugs keep coming for years after they collected funds. Be clear about how any future work gets paid and make it clear that you fully expect that future work will come.

Great piece, @tptacek It's also important how you position & present this to the client. Say: "I am going send over our statement of work. This details exactly what you are going to get, and by when. It'll be an attachment to our standard contract. The contract has some legalese in it that my (or our) lawyer had us include, but I don't want that to stand in the way of us doing business, ok? If you have any questions about the terms, just highlight and we'll talk about it." With this positioning you don't suck the enthusiasm and the optimism out the project.

Just as curiosity, what tool will you use? Rails?

Yes I will be using Rails!