Try developing code for your application and use a well tried out program for the "burning" part - this will atleast reduce the variables when you debug your application code - atleast you are sure there are no bugs to search in the programmer part.

NOPE, the fact that code is "burned" into the EE/Flash does not guarantee that it is there tomorrow. The famous "fast programming method" that is still popping up now and then was based on "the programming pulses does not 'need' to be as long as the datasheet states, the thing program very well with 1/5 the width" had the little drawback that the programs vaporized in a few days/weeks/months.

The fact that a kitchen table programmer actually program the chip is not a proof that it works.

Erik

PS.: why do I come out every time against kitchen table programmers.
1) I have wasted so much time trying to support people with '51 problems that claimed 'it is not the programmer' when it was. These problems would not have existed if the chip was properly programmed - or the programmer maker would have admitted the non-adherence to the specifications. It always was "it works!"
2) With ISP chips abundantly available there is no excuse adding a 5 mile high question mark to the functionality of a design by building a programmer.
3) If you can not handle the cost of an ISP chip because of your volume, your volume is big enough to buy a programmer from a reputable manufacturer (BP micro, Needhams)