When developing in rails it cuts up to 50% of the time vs building it in PHP with no pre built framework. The client looks at this as saving time and money, and also offering status as it’s now become a status symbol to use Rails. You are still able to charge your hourly rate and plus some for offering the latest and the greatest. Most clients will not even blink when you hand them the bill/quote, as you have met three major needs (saving time, saving money, and status).

But the question comes up. Do i offer rails and get paid more per hour and get done quickly, or do i get paid the same rate and take longer to do so? Well this is how i look at it, if you can fit more projects in and get paid more hourly why not? If it takes me two weeks to finish a project vs one month, that means i can stick two projects in the time of one and that equals more money and happy clients.

So do i offer rails over PHP? If the project is open to it then yes, i will offer Rails over PHP. I would rather have a happy client and be able to move on to a new project after a short time to keep the cash flow coming in.

I feel public beta for a public product is key in making a really great application for the public. That is exactly the way I work, currently the June To-Do system is up for public beta and is doing great because of it! The public has killed some very small bugs along with some huge ones! I feel if I did not release the system under public beta for free, I would be ripping people off by making them pay to find bugs.

If we as developers think that public beta is crap then how can we truly build an application for the public? Real users give real results in the end; closed testing is great if the project will not be going public. Your application my look different to a 50-year-old person then it does to a 20-year-old person. By allowing your app to go public beat this will give you a better understanding of how people see your application in a real world setting.

I have done many updates to June thanks to many public beta testers! I would have never seen some of the problems if I did not have people test or beta this product. I agree with some of the things said such as saying no to your customer or beta tester. I can’t add every feature known to man in my applications, and many times this is what you may get. Your testers may ask for a million different features to add, but you do need to keep it to the goal by asking yourself a few questions. What will this do for my application? Will this aid in the main gold of this application? Would you use it? If you answer in a positive way to the three questions then it would be a good time to think about adding that feature.

But back to public beat testing, as I have always told my clients that want online applications; testing is the key, then test some more. So what do I do if the application is not a public app? That’s an easy one to answer! After building the application, send it off to the people or office that will be using it. Setup a form for them to submit bugs and requests, that’s easy to do! Collect all the emails and start working on the fixes, once done send it for testing again! You should repeat this process for as long as it takes. Remember, some bugs will not show them self’s right away. Some take days, weeks or even months to show up, so time is your good buddy.

Our client is our life, they pay the bills that help me pay my bills, and they are your money. So why do we sometimes get so mad over them creeping on scope and such? Well from our point of view they are trying to get all they can without paying for it, and from our point of view that is bugging us because they are making us work twice as hard for less pay. But take a look at this, what do you expect? They are a business owner and they got there by doing what needs to be done. That’s what makes the world go around! So how do we stop the dreaded scope creep, or even better how do I stop it?

Every client of mine receives a bill for every hour I work of the project, nothing goes unbilled. After meeting with the client and finding there needs I began work on a requirements document. The client will sign off on this document after reviewing it. Nothing out side of this document will be built, so per say the client calls asking for something that is not in the document. I handle this by looking over the document and seeing what category it will fit in with such as back-end, front-end and such. After that I will add this to the document, re quote the project with the added feature and send it off to the client. Once the client sends the ok, I will continue with the project. Something you will learn with most business owners is that they don’t mind paying for something as long as they know the cost upfront. You will run across some exceptions but for the most part you will have no big deals. As I said, nothing goes unbilled and the client knows the cost of the project the whole time.

Your client will then thank you in the end and know exactly what they are getting, with no questions about how long it will take and why it will take that long and what is the price? Also keeping an open dialog with your client, don’t shut them out after the first meeting! Offer suggestions on how thing could be done, why not? It’s your paycheck! Keeping in contact with your client will help with trust and letting you make the call in the end. Educate your client on the web, and how things move today. Listen to what your client is asking for, they may just want something simple that sounds hard to them. Did I say listen to your client? That part is key, in keeping a good business going. Your client will tell the truth about you, just ask them “How am I doing?”. Most will tell you, and you may be shocked!

Like I said educate your client keep in close contact with them, they will love the work you do for them and in turn you will have much more business by referral. One good client could land you a very big job. Like I said, your clients are your life, without them you have no money or a job for that matter!