If you want to build a product by hiring a software development agency, then read this post first before doing anything.
I have been running Coding Sans, a software development agency, for 5 years.
During this time, I’ve overseen 70 projects, which undoubtedly has gained me a ton of experience.
I see a few patterns I would like to address that could shape the model of IT outsourcing in people's mind, and make all involved party's life easier.
In this post, I will cover the most crucial parts of software outsourcing from the client and agency point of view. These can make or break your projects.
Check out the high-level summary of this post by clicking through the slides:
Software outsourcing models
There are two models: you can hire teams with a “fixed price and a fixed scope,” or you can hire “people by time (hour/day/week/months).” The ideal choice depends on the situation but boils down to risks.
For you to be able to demand fixed-price and fixed-scope projects, you should eliminate all the risks involved in this model and deliver the project with all the necessary requirements predetermined. In this case, most of the risk is handled by the software development agency.
With the “people by time” model, the project management-related risks are handled by the client. The software development agency only provides the requested number of developers.
Here is a table comparing the two software outsourcing models:
Where to start
You have THE IDEA, you get some designers who have experience with digital products, and you convince them to work with you.
Ideally, you should get to us with a final UX/UI. I know that there are firms taking care of the design and development, but it’s rare to have world-class talent of both under one roof, simply because design and development demand very different kinds of creativity.
Designers are creating something from nothing and building solutions within given constraints. Designers are creators; developers are problem solvers.
We sharply focus on being world-class developers.
UX/UI and end-user validation
UX/UI is fundamentally different from developing a project, so it should be handled separately.
As a rule of thumb, if your UI designs haven’t been seen by at least 10 end-users who were trying to accomplish something on your high fidelity mockup - called user testing - you are setting yourself up for failure.
There are countless tools out there you can use to easily create a clickable mockup that works like a real app.
You can’t think with your user's mind. If you skip user testing with a high-fidelity prototype, then chances are that after the initial release, your users will have no idea how to use your product. You might just build something no one needs. Rewriting the code demands way more resource then redesigning it.
It’s a different story if you can force people to use your product (you’re their boss). In this case, you simply lose efficiency, while your users (your employees!) are wasting time.
Another aspect is when you say you can’t get 10 end-users to test your mockup. Then how will you get them to use it once your product is ready?
Thorough research and planning
Software architects design your solution based on what they receive from the designers.
Yes, it costs you money, because it takes time to design your solution. A lot of research has to go into it about the services you would like to connect to and technical decisions have to be weighed about databases, cloud providers, and dataflows. Then, the whole project has to be divided into tasks that follow each other in a logical order.
If a provider skips this part in the name of AGILE, they just want to get the most hours out of the project with constant rewrites, or they are simply dumb. Agile means agile delivery, not the lack of planning. You absolutely have to have detailed knowledge of the big picture before starting development.
Set the priorities
You have to be conscious of what your priorities are about your project, such as time, quality, and cost, but like all the best things in life, you can only choose two.
If you want it cheap, then it will be a backburner project, meaning if there are available resources, then we will work on it. But this rarely happens nowadays.
If you want it really fast, then you have to overstaff the project where every additional developer is worth less than 1.0.
The ideal project size is somewhere between 5 and 7 developers. If the ideal number is 6 but you want 12 to work on the project, then trust me, they won't deliver in half the time. Just like 9 women can't deliver a baby in one month.
The number of devs that is ideal on a project follows a Gauss curve. It’s better to start with a few at the beginning, then increase it up to the ideal number, then decrease it back down to a few at the end for bug fixing.
Quality is something we’re not compromising on. Sometimes clients approach us with projects in a very poor state. Usually, they have a halfway-done product and they need our help to finish it. Typically, these products don’t have any tests set up, which makes them an absolute no-go for us.
And this brings us to...
Tests are must-haves
A test is the only formal proof that a system is working as it was intended. You should demand a test suite for your system in the contract. Your project will take 30%-40% more time, and most of the devs hate to do it, but it is the only thing that ensures long-term maintainability and extensibility.
Without tests, only the person who wrote it will be able to touch your system. Some agencies take advantage of this and use it as weird vendor lock-in, forcing the client to keep working with them, since they’re the only ones who know the code.
No sane dev touches even a moderately complex system without tests. It is like running on a minefield: a single step can have overwhelming unintended consequences, but while on a minefield, you know it instantly, with a system, an unintended bug can linger around for a long while before even getting noticed. Imagine if this system deals with money…
Turning your idea into a shipped product can be a rocky road, but you can smooth it out by being mindful about the trade-offs you are willing to make, or have to make.
Ideally, try to divide the design and the implementation part sharply.
Make sure you run end-user tests with your UI designs, where the users are trying to accomplish something. If you skip this part, you are setting yourself up for failure.
Your project should be researched thoroughly by the software development agency. You have to have a detailed knowledge of the big picture before starting the development.
And here is one more thing: never skip the tests!
Photo by Dogancan Ozturan, Unsplash