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 or jump to specific parts:
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…
IT project development checklist
Go through this list while planning your project, it will save you a lot of time and disappointment.
1. Before you start
The first thing you want to do is have a budget in mind. This outlines your possibilities and boundaries.
You want to get acquainted with regulations. Make sure your application doesn’t break any laws or regulations. Make sure it doesn’t violate the terms of service of your potential partners or third parties you wish to integrate with.
Then you must examine the potential market. Identify your customers (hint: everyone isn’t an answer). What are their needs, and how will you make their lives easier?
Look at your competition. What are they doing? Where are they failing or lacking? What will YOUR solution bring that others’ cannot?
After all this, you should have a pretty clear image on the direction you should be heading, so you can dive into all the technical stuff.
2. Look and feel
Though it may not seem a big thing at the beginning, it has a huge impact on development.
A little button here, an extra function there, and a messed up flowchart can lengthen the dev process by months, and that’s a pain for everyone.
First of all, walk through your concept with an experienced UX designer, who will do interviews with members of your target audience, do research on similar apps and craft a prototype. This does not only point out your audience’s pain points, but it makes development smoother by having a core concept to work with.
The other point here would be having a design, preferably with finished concepts for pages. Having a style guide to your app makes it much more coherent and smooth and your brand will seem much more dependable and trustworthy. This also makes it much easier for developers to build your app.
If you don't have a dedicated designer for this job, here is a list of some easy to use mockup tools.
3. Coding
The topic might be a bit misleading, because this part has very little to do with coding. Let’s leave that to all the devs out there.
But in order to have a streamlined development process, you need to keep some things in mind.
Is it a new project, a modernisation of an existing one, or perhaps an expansion?
Determine your platform: Am I thinking web, mobile, data analysis, CRM, etc.? This can steer the technology requirements in a certain direction. Do some research on technologies, and look for the ones best suited to you needs. You should be looking at frontend, backend, databases, and compatibility.
If you’re not familiar with the technologies, we recommend involving developers who can help you select the appropriate technology for your application.
After you’ve made decisions on all this, you’ll need a good specification.
Having all the features written down makes planning easier and delivery more reliable.
First, break your project down to big milestones, then into epics and finally stories.
Milestones should be big delivery dates, where certain parts and functions are in place; epics are the bigger features and stories are small increments of work usually determined by the scrum master/project lead/developer.
If you want to learn more about user stories and see some templates, check out our comprehensive guide here.
A few other things that should be taken into account are scaling (the amount of data it should handle), encryption, testing (who does it and how) and maintenance (warranty and monitoring).
👉 Further reading: Backlog vs. Specification
4. Dependencies
By now, you should see what the app will look like and what functionality it will have. In this part, you’ll want to consider if the application will be working together with other systems.
Think email/notification/SMS messaging, payment, social media, localization (translations), maps and/or location services (GPS), communication and/or integration with legacy systems, other ERP or CRM systems, operating systems and the list goes on.
These might need some research or even inside contact to help with the integration (think huge systems like SAP).
Conclusion
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
_ We’re a full-stack web development agency, building web applications from design to delivery with Angular, React, and Node.js
