Winn.ws

Why Clients Dig Rails

Offering rails is a great option for clients in todays market, offering rails usually means that you can offer a quick turn around time and a solid product production ready. When explaining how long it will take vs PHP the client will always lean to Rails. The client wants the product and wants it now. They hate waiting or months and months to get a project done. The waiting will also allow more time for your client to back out of the project mid way.

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.

posted in: Development 02.01.08

Public beta for a public product

Why not? Some developers call public beta “Bullshit”, they say that you are afraid to release a full version and put the blame out of your hands. They go on to also say that this is a “if it does not work don’t blame us” type of attitude.

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.

posted in: Design & Layout, Development, June Project, web standards 01.13.08

Educating your client

Something we as a designer or developer will come across many times, educate your client but don’t insult them! Now I am lucky I have a teacher for a wife so I have seen a few things that she does when talking to students or parents. First we must understand our client, most don’t know the web like we do. They may not spend every day and every hour online looking at new things and finding ways to make the web better. If they do then you will not have this problem!

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?

Read more

posted in: Design & Layout, Development, web standards 01.11.08