Freelancers, Contractors, and Agencies, Oh My!

Lets go over some basics when working with software freelancers, contractors, and agencies. If you’re not new to software or these kinds of groups, this is probably going to be pretty pointless.

The Portfolio

When you’re shopping around you’ll likely bump into a client list or portfolio of work. It should be obvious that the portfolio and client list is there to show the best side possible. While that doesn’t mean that what they are showing is a lie, it also doesn’t mean that those results are typical.

Software is as much art as it is mechanics, and while we all tend to think of it in terms of what software ought to do we also wouldn’t hesitate to stop using it if it was grotesque and unusable. So if you see something that piques your interest, ask about how they built it that time. Ask them how their relationship was. Ask them about the team that built it. Thats right, ask about the specific group of people that built it. Don’t believe for a second that everyone is equal in their abilities, so find out who did the work you liked and ask for them or people like them.

Stroking the Ego

After you’ve found someone you want to work with you’ll have a chat. During this conversation they’ll ask all about you and your business and what you want built. Then, through the conversation you can imagine yourself being guided pleasantly along a path to a cliff that is beautiful. Then they’ll push you over the edge.

This moment occurs when brainstorming happens during this conversation. You’ll hear phrases like, “It’d be really neat if…,” and, “You know what else we could do…” These parts of the conversation are actually innocent, but have the tragic side effect of making you, the client, feel like you’re really lucking out with these people because they get it, and they will do a better job because they care.

Guess what, this conversation has been just talk.

Scope & Contracts

There are two basic agreements: Fixed price and time and materials. Fixed price sounds like exactly what it is, you will pay a fixed price for something. Time and materials means that you’ll usually pay a fee per hour worked. Both have pros and cons, but all of it will be pointless unless you consider a couple of things.

First, lets talk scope. At the time you’re going through these conversations you’ll very likely think you have a pretty good idea of almost everything your software needs to do. You probably know less than 60% of what all you will actually need to successfully finish your product. If you don’t believe me, lets briefly discuss logging in to your product. Of course you have to login, you have to login to everything, so you do here too. Here are the things you’ll have to deal with before you have login finished.

1. Do you login with username and password?
2. If so, what can people use as a username, can they use an email address?
3. Also, what constitutes a safe password, knowing that if it’s too easy it can be broken, and too hard nobody will remember?
4. Do passwords expire, if so, how often?
5. Can I reset my password?
6. If so, will it email me a link that expires?
7. Can I login with facebook, google, twitter, etc?
8. Can I login with those and username and password?
9. How do I register for an account?
10. Do we want users to get a registration email so they have to confirm who they are and prevent bots?
11. What information do we collect during registration?
12. What if a user logs in twice?
13. What if a user who is logged in sits idle for 1 hour, do we log them out?
14. If a user fails to login multiple times what do we do? Do we lock them out?

Easy right? Believe me, there are more questions than this to answer. This is just login. So, hopefully, this little tangent has at least surfaced the idea that you don’t know nearly as much as you thought you do to have your project scoped correctly in a contract. So bring this up. Not only do you not no now everything you need, but conditions will change and you’ll want to react. Find a way to make your scope somewhat flexible, and barring that, keep it small so you aren’t locked in to a poor decision for too long.

Deliverables are next. You’re getting a mobile app/web page/internal application right? Ever hired a photographer that doesn’t give you the photos? If not, they will do this, and if so, you now also know a pretty important question to ask. Who actually owns and has the software that is built. You’ll be surprised at how many groups retain all software. Also along these lines is if you’re building something on the web, where will it be kept and served up from? Do you have a plan for this? Your contractor will. Be sure to keep the hosting of your web page in something you can access and control, otherwise you will have bought a web page that you don’t own.

Almost done, but lets talk about bugs and defects. All software has bugs. All software has bugs! Including whatever you want built. As it is built you will discover them. What does your hired gun do when that happens? Usually contracts only cover the scope you discussed and there is a vague clause about reasonable efforts to fix bugs. Nail that down. A bug that is horrible to you, may not be to them, and they have no reason or desire to fix it.

Lastly, handoffs and invoices. Be crystal clear about the terms of payment and when you receive whatever deliverables you expect. By crystal clear, I mean put it in writing. I cannot tell you how many horror stories I’ve heard of projects being held hostage because of invoicing confusion and other disputes.

By the way, who is testing your software? Are you actually going to pay for something that was never tested?

The Day to Day

Welcome to the land of jargon. Don’t feel trapped by this and don’t let yourself be trapped. Ask for explanations. Realize that most of the time this is all common language to them, and a reminder will bring it back.

Ask for updates. Ask to see screenshots, wireframes, designs, slices, and demonstrations of code that isn’t working yet. More than a few people will shy away from this because they don’t want to have to explain why things are broken, or in an imperfect state. This like finding something in your garage. You know the whole place is a disaster, but right now you only need one thing. Asking for update is important because it sets the expectation of continual progress. Also, allowing you to see how things are going will give you the chance to realize those 14 and more questions as they build login.

Wrapping Up

Your engagement is coming to a close, you’ve gotten the project that you asked for, you have a reasonably fair relationship with your vendor. Now all you have to do is release it and you can call it a day.

Except you can’t just do that though. I’d put money down that before your product is released you will have a list of the next things to add and fix. You can just call your rockstar contractors up and get started, but then you’ll be juggling two things.

First, you’ll be working with your vendor getting that list knocked out. It’ll feel good. The realization that you’ve fallen into a trap of being dependent on a vendor won’t hit for some time yet.

Second, you’ll be confronting the very high chance that your internal app, web page, mobile app, etc doesn’t have enough users, revenue, social impact, or any of the other dreams you had.

There are ways out of this situation and there are people who can help, but that isn’t who you hired.