Tomorrow is a big day for me. As you may or may not know, I’ve built a system for a school here in Bolivia. It’s the whole shebang, CRUD, reports, stats and more.
Tomorrow I head out to two different schools and pitch my software to them. The great thing is, since the application is already in production in another school, it’ll feel more ‘tested’ and ‘reliable’. Plus I look good in casual business. 🙂
When I look at it done, from a birds eye view, it seems it’s not that complex. But then I remember some of the things that contributed to the effort I had to make to finish it.
- It was my first ever freelance project that I had to finish from top to bottom. That’s a lot of pressure.
- I didn’t fully appreciate the scope of the project when I first took it.
- I didn’t quite understand what the client wanted, and it seems in retrospect nether did the client!
- I had to learn certain things hitting the ground running.
- I had to design the applications GUI. I made a conscious effort to make it pretty.
I’ve learned a lot in these past 4 months. So I’ve decided to try to write them up here and share some of the things that they don’t tell you in college.
Clients don’t know what they want half the time.
It’s your job as a developer to identify the problems a client faces on a daily basis and identify your role in solving that problem. Remember, they’re buying your code, your software, because they think it’ll help them work faster. They couldn’t care less if you use IoC.
Try to ask the right questions that will get them to think your way and see things in your light. A good developer follows orders, a great developer injects orders into the clients subconscious. Give them the illusion of choice. 🙂 After all, would you tell your doctor what to do? No, they’re the professional and they need to do their job.
Identify where your application is going to run.
If your software is meant to be a client server application, does the business have a local area network in place. Does it have infrastructure or do you have to provide it via a third party? How about current IT policies? Take into account what the ecosystem is like where you’re heading and make sure your application is ready to fit right in.
Target OS’s – do they run Windows XP or Windows 7? Are the machines slow or new generation?
Take these into account from the get go, or trust me, they’ll bite you right in the ass.
Learn to say ‘no’.
“Sergio, can you change the size of this font?” “Sergio, can you make these textboxes a bit higher?” These little changes add up, and time is money.
One solution you can attempt is to take note of all these requested changes and when they get a certain amount offer to sell them an update. Don’t try to get too much juice out of it, it would be dumb to sell a 400$ update to a 1200$ application.
Also offer a grace period of 30 days where they can request reasonable changes, but learn to say ‘No, that is a major change’. Done.
Always use a contract!
I made the mistake of making a ‘verbal contract’ with my first school. Since it was the place of business where an aunt works, they seemed to trust me. I’ll never do this again though, and you shouldn’t either.
Contracts, contracts, contracts. Hire a lawyer, invest. If you don’t have a lawyer or can’t afford one, hit your local law school and ask for legal aid. One of the students will gladly help you for free because it might count for extra credit.
But why do you need a contract?
- It protects both parties. You and them.
- You are able to clearly define when the project beings and ends. No more scope creep.
- You define milestones and payment options.
Protect yourself and your sanity, get a contract. Always!