Don't contract as a contractor to businesses that are programming themselves. Build things for businesses that will be the end user. Most of these types of businesses have less of a notion of how to go about getting tools that will help their business in the first place and it can be a hard sell unless they have an immediate need. Sometimes you have to really learn about the specifics of how the business functions and this can be a pain. But once you build a few small accounting apps that export to CSV or inventory management tools specific to the business...stuff of that nature, you have a good point to take off from and examples to show. You do have to deliver though... a finished product, not just code. But I stay pretty busy like this.
Just to expand a bit... here are a few things I have built over the past several years (part time now... I have a full time job)...
-A load builder, temporary placement scheme creator, and shipping router for a large cattle feedlot in the Midwest (my brother got me this job, while I was working on it a building maintenance man came by, asked about it, told his wife who did data entry for a crop harvesting company and I got the gig below)...
-A ticket management and payment system for a crop harvesting company. The original application was in Access, and was slow and clumsy and full of bugs leading to bad payments at times. I re-wrote it using SQL, python and web interface, and host it for the company. Now they can use the application when they are out doing remote harvests (they harvest grains etc. in 4 or 5 states). The owner was pleased and recommended me to a milk producing co-op (below).
-Milk production and payment calculation for a 15 dairy co-op. Working on this right now weekends and evenings (I have a full time job). This is a complicated application that takes a number of factors (amount of Butterfat, government fuel prices, amount of bacteria etc.) and calculates payment due to individual dairies. The original app is in Lotus Approach and it's been a struggle getting everything out and finding how it all fits together (the person who made the original application passed away). In fact, I should be working on it right now instead of playing on HN. But Lotus Approach is no fun. At all.
Not sexy.. but good side work that fills a real need. There are lots of companies that could use an update, or have very specific needs they can't fill with off the shelf software. And they generally don't have a clue about how to fill that need.
I agree with what you say and in the long run one should be looking to work directly for end user
but a balance should be maintained b/w the two. It is easier to convince the software businesses of your usefulness
while convincing the end user will take much more effort.
One other benifit of working for the end user is that in many cases you end up being paid for maintaining (for example being a server admin for a web app) the application you wrote for them. This can be a nice source of recurring income.
A lot of businesses that do programming don't have expertise in certain areas and sometimes projects need to be rescued. It really depends on what kind of work you want, but I find dealing with businesses that employ programmers nice because you can get to work more quickly and the work tends to be more interesting & challenging.
