As database consultants (or software developers in general), one of the best choices you can make is to avoid billing your clients by the hour or by the line of code. For new projects, charging by the project or using milestone-based pricing is almost always a better approach. It focuses on outcomes and results rather than time spent, providing clearer expectations for both you and your clients.

Hourly billing often turns your work into a commodity, where clients compare rates and choose the lowest bidder. It reduces your expertise to just a dollar amount per hour, which puts constant downward pressure on your income. This is especially dangerous in a market filled with freelance developers offering similar services at lower prices. Pro tip: there are folks in other countries who will charge a lot less than you.

Charging by the line of code is even worse. It incentivizes quantity over quality, leading to bloated, inefficient code that serves no one's interests. Clean and efficient code will always win out over more lines. You wouldn't pay a painter by the brush-stroke, or a writer by the word, would you?*

When I was in my twenties, I worked for a company as a contract programmer. I was paid by the hour of course (not very well, I might add). On Monday mornings, we would have our meeting to discuss what needed to be done for the week. They'd give me my list of tasks, and by noon on Monday, I had everything completed. I spent the rest of the week playing solitaire at my desk. I was in a small room with no windows, all by myself, and no one could see what I was doing. And of course, I had my code editor ready for a quick ALT-TAB switch if someone did come in the room. Sometimes, channeling my inner Scotty the Miracle Worker, I'd casually tell them halfway through Friday that I had finished early and ask if I could go home. They were amazed. "Oh yeah, great job! Go ahead, take off early!"

So, never pay a programmer by the hour. However...

As a consultant, there are times when hourly billing is necessary. When you are troubleshooting a client's existing database or fixing something built by someone else, it is impossible to know how long the job will take until you get in there. It is just like when you hear that rattling sound, so you bring your car into the shop, and the auto mechanic says "welp, could be this, or could be that. Won't know for sure until we get in there." Diagnosing a problem might take five minutes or five hours, depending on how complex it is.

When you charge by the hour, you are putting all the risk on the client. They are paying for your time without any guarantee of an outcome. Think of it like going to Starbucks and having the barista charge you by the minute for making your coffee. You would wonder why they could not just give you a flat price based on experience. They know the costs and time involved with making your Iced Triple Venti Caramel Mocha Latte with Extra Whipped Cream, Two Pumps Hazelnut, One Pump Vanilla, Light Ice, Half-Soy Half-Almond Milk, and a Cinnamon Sprinkle on Top.

Charging by the project puts some risk on you, but it forces you to think like a business owner rather than a technician. Over time, you will get better at estimating your time and pricing your work appropriately, making it easier to manage projects and keep your clients happy.

As Spock said in The Wrath of Khan, "The needs of the many outweigh the needs of the few." This applies perfectly to project-based pricing. The developer and the client both benefit when the focus is on delivering results rather than tracking hours. In this scenario, the "many" are both parties, working together for the best solution. Focus on delivering results, not tracking hours or counting lines of code, and you will see both your business and your clients thrive.

For more tips on being a software consultant, see my page Advice for Consultants.

LLAP
RR

* A classic example often cited is Charles Dickens, who published his novels in serial form. While it's a myth that he was paid by the word, he was compensated per installment, which some argue led to longer narratives. Critics have suggested that this structure contributed to the length and detailed nature of his works.