I have now worked for my own company logicLAB for about 3 months, it has been quite an experience - and I have really gotten to program more than I had dared to hope for.
But running a company or being a freelancer is not only about programming. There are plenty of other tasks in the areas of:
Accounting and finances
Sales and networking
Project management and estimation
These areas have proven to be quite interesting, but at the same time they offer plenty of pitfalls and challenges.
I have tried to be very structured with my accounting and I even went to an introductory course with the tax authorities here in Copenhagen, it proved to be a good investment and I can see that I need to polish my existing procedures and organization of accounting data.
I have tried to keep my own salary at an absolute minimum and I have not bought or ordered anything for the company without knowing that I had the money. This has succeeded so far, but my salary has been VERY low and hope this will only be for the remainder of this year.
Another thing, which have proven quite stressfull is awaiting the clients to pay their bills. I did not have any savings or buffer as such when I started logicLAB (I had no start expenses either) - so every invoice I send out is really necessary for my success - so this is quite a stress factor, especially if you are tightly bound to one client. My advice here is to bet on more than one horse if you have the opportunity and are in the same situation as me.
For the sales and networking part, this has been the most successful and the reason why I have clients and assignments at all is all due to network, so this is one of the primary driving forces in logicLAB and selling some thing you like (programming) is not so difficult, setting the price is much more difficult.
This leads me to estimation. My clients are quite small and they all want the price to be VERY low. So in order to make the sale I have to push the price a lot. This is hard especially when you are on you own. One thing is lowering your hourly rate, but at the same time you often work more hours than you expected meaning you get into a situation with your client where either they are paying a fixed price or you simply do not charge them for all hours, dropping your salary even further.
In this area I really need to practice a lot. Both my estimation skills and my business skills are not especially impressive. I know how to estimate software development, but combined with being a salesperson, I tend to be too positive and therefor things either take longer than expected, jeopardizing the relationship with the client or I have to work many hours at a very low rate to get things done...
I find it very difficult to run a business, but I hope logicLAB will survive its first year and that I will become a better businessman, so I can get to do what I want - which is to code Perl.
Any words on advice will be appreciated...
Don't do a fixed fee contract
autarch on 2004-05-24T19:34:07
If clients ask for a fixed fee up front, I tell them that I can only do that if they're willing to pay me my hourly rate to work with them on an extremely detailed spec (about 10-20 hours). With that much detail, I can give a reasonably firm fixed price.
But not surprisingly, no one wants to do that work
;) So they just pay me hourly, and I give very rough estimates, and always qualify them with "but I don't have a detailed spec so it could be longer."
This has actually worked out fairly well, as clients see that in the end, I don't gouge them, and they get a good value for the hours worked.
So my advice to you is to avoid fixed fee contracts, because as you've noticed you end up working on them more than you want.
Also, if you have some clients for whom you do hourly work, you can use them as references to vouch for the fact that you provide a good value.
Re:Don't do a fixed fee contract
jonasbn on 2004-05-25T07:08:30
Thanks for the advice,
I have all the time had a bad feeling with fixed fee projects. Eric Sink who writes for MSDN, has written a good article on making mistakes and he mentions this too.
Again thanks for the advice,
jonasbn
