I’ve just completed a contract app project. And although I’ve completed and shipped projects to app stores previously, there are significant differences in the workflow and processes that make these types of jobs more complex.
For starters I’m working with other people so expectations to deliver are higher, working builds are essential and completing to the agreed deadline goes without saying.
Here are some of the things that I have learned over this recent contract project and what I’m planning on implementing in my development practices going forward to improve my skills and workflow.
The Contract (or Client Agreement)
After discussing ideas with external clients, contracts, client agreements and non-disclosure agreements usually come into play.
This is a standard part of working with any client as they want to ensure their work/idea is protected and you want to make sure the work agreed is scoped correctly, all deliverables are defined and clear to both sides, and if this keeps the client happy all the better.
I’m not a professional working in the legal sector so I must state that you should consult a legal professional in your area to make sure any contract you sign is acceptable.
While most standard contracts should be sufficient and simple, it’s important to make sure the contract covers all details. For example, you may want to make sure that the payment date is determined by the work being delivered and not when the project is being used or released.
Freelance Jumpstart had a great podcast episode for this topic. I would encourage you to watch or listen to this to make sure you include any additional points into the contract you sign.
Project Scope
The project scope should be laid out in detail before the work begins. I provide a quote to the client before hand detailing all features requests and the cost of each. So when it comes to the contract, you can reference this document or include it’s contents to the project scope section.
Handling Feature Creep
Feature creep may come from a client trying to build a better product, or it may be it you getting excited about the project and adding in lots of additional bells and whistles that weren’t even necessary (believe me we’ve all been there). Another way feature creep can occur is from reviews.
To ensure you stay on track with development, after every meeting, write a summary email with the meeting outcome. It’s important to detail here any changes to the project scope or deadlines that will be incurred due to these late feature requests. But the best thing to do is to state that although these would improve the project, they will also add additional time to the project length and may mean the project deadline will have to be extended.
Depending on the client and their deadline will depend on whether you add these changes in or not. Remember to get acceptance to deadline changes in writing.
Supporting Documentation
You may not have factored in writing these documents when doing your initial quote but be wary that these documents are essential for your client so they need to be done.
So if you add in a feature for e.g. analytics don’t forget to include a charge for the report creation into the cost.
Project Management
Whenever you begin a new project, it’s important to outline your development process so that both you and the client are in the same page going forward.
If your project is across a few months, I would recommend setting up weekly milestones in the form of calls, emails or in-person meetings with the client to show progress. State this in the development process mentioned above so that all parties know when to expect these.
Verify at the beginning of the project to find out if the client thinks this is too frequent and adjust accordingly. A weekly meeting will also help you as the developer to ensure progress early and often.
Release Candidate Build
A release candidate (RC) build is what I call the build that you have produced which you have implemented all of the features and are ready for user acceptance testing. This may not be but free, but it’s feature complete. Any bugs found in this build should be fixed and a new build created.
Put in a RC deadline into your calendar a week or two before the contract deadline. This will make sure you deliver on time and factor in working on bugs during the contract length.
Project Support
This is something you’ll have to negotiate with your client. After handover (or whenever the client begins using your project) is the time when they may need the most support. Be prepared to support the project for about two weeks after handover, but make sure you have this as an optional additional cost in the contract. If you’re planning to be away during this time, bring a machine to debug and build on in case unexpected bugs arise.
Images
When working with artists, request images in the correct sizes for each dpi folder. Or, if you’re willing to invest in some additional tools, you can also use mfractor’s Import Image Wizard feature.
For Android projects, these are the recommended sizes. For iOS projects, these are the recommended sizes.
Make sure that the images are also named in the correct naming convention for the platform or they’ll get rejected at compile or build time e.g. Android shouldn’t have uppercase characters or symbols other than underscores and can’t end in a number.
New Tools and Software
Working on a contract project instead of my own personal projects is a great way for me to stretch my own skills. For example, in this project the client had certain features that they wanted to implement, so this made me investigate using new tools and software that I maybe wouldn’t have chosen to use for my own projects. Doing this stretched my knowledge and has definitely helped me and my confidence grow.
The Good That Comes From Pushing Your Limits
I encourage everyone to work on a paid contract every now and again. It forces you to bring a higher level of professionalism to your work and when you’re at that level, you don’t want to go back to “anything will do to get this out”.
Lastly, I would advise you to try and accurately estimate the work you need to spend on implementing your features. If you find that a feature has taken half an hour to implement rather than the two that you estimated, move onto the next task and do something daily. Doing this early in the project will lead to more productivity and hopefully no crunch at the end.
Never crunch!
[wordable-io]
