- Don’t agree to a fixed-price/fixed-scope contract. Instead, insist on an Agile Contract.
- Do insist that all changes are instantly available to test using Continuous Deployment.
- Do ensure you have a direct line of communication with Engineers.
- Do act as the Product Owner and set the priorities.
- Do ensure all technical resources are under your control e.g. GitHub, AWS.
- Do use an external expert to validate the technical decisions.
Suppose you have a fantastic idea for software but lack the necessary technical skills to build it yourself. In that case, finding an agency or freelancer to develop it for you is your only option.
No-code solutions are available; however, if you’re solving a complex problem or innovating, you will likely need to consider a custom build.
I’ve built SaaS products every which way, including outsourcing to a third party, and I’ve compiled this list of what you must do when using a third party, all of these need to be negotiated upfront.
1. Don’t agree to a fixed-price/fixed-scope contract. Instead, insist on an Agile Contract.
Agile contracts are where you pay for a fixed timeframe (2 weeks is best) and receive everything created in that timeframe with the option to continue or cancel. When building out an idea having the ability to change the product dramatically in two-week increments is essential. How you thought the product would work initially versus what it will become are usually drastically different. Only once you start using the software will you realise this.
Insisting on an agile contract will automatically exclude many agencies from taking the job. Many agencies hate this way of working as it makes them fully accountable for the deliverables.
Fixed-price/fixed-scope contracts seem less risky, but they start from the incorrect assumption that all requirements are known upfront when nothing could be further from the truth.
From an agency point of view, the game of a fixed-price contract is to deliver the software as fast as possible with as few resources.
2. Do insist that all changes are automatically available to test using Continuous Deployment
When a software engineer changes the source code and pushes it, it should automatically update the software, and you should be able to test the change.
Technically this is called Continuous Deployment and is a must for assessing progress.
Agencies prefer daily, weekly or bi-weekly updates, but this delays the feedback loop and your ability to course correct.
It should only take a competent team 1-2 days to set this up, so there is no excuse not to do it. Suck up the upfront cost and
3. Do ensure you have a direct line of communication with the Engineers
You should be able to talk directly with the Engineers via Slack, Email, and Zoom.
The engineers should also be able to ask you questions at any time, so be prepared to make yourself available when the Engineers are working.
Agencies hate this and love to put an unnecessary buffer (project manager) in between, which inevitably adds a layer of misdirection. The engineers’ understanding of requirements will be based entirely on what the project manager tells them, which is very risky.
If the agency refuses, then find another agency. Good agencies will be happy with this arrangement. If the engineers don’t speak your native language, the Project Manager can act as a translator.
Having engineers gain their understanding of requirements directly from the domain expert (you) is the most effective way to build great software and avoid costly misunderstandings.
4. Do act as the Product Owner and set the priorities.
A Product Owner is a person that understands the requirements best and can set the priority of work based on the business objectives. It’s not a technical role.
You must play this role or find an external expert to act as your proxy. If you use a proxy, ensure that it is someone outside the agency doing the software development.
Agencies will have a way of working and will recommend a sequence of work that suits them. Only you know what is most important and should be worked on first.
5. Do ensure all technical resources are under your control e.g. GitHub, AWS
When building software, there are several services required. GitHub is used for storing the source code, and AWS or other cloud platforms are used for running and hosting the software.
If you don’t have access to the source code, then the agency can & will hold your code hostage in any contract dispute. It would be best if you assumed there will be a contract dispute.
You want to ensure that the source code and the software’s hosting are under accounts in your or your business’s name if you’ve incorporated already.
Agencies will prefer they keep the source code under their control and use their existing hosting infrastructure.
6. Do use an external expert to validate the technical decisions
Technology decisions can often be arbitrary, and despite what an agency might tell you, they have preferred technologies they use. Using the agency’s preferred technologies can help things move faster in the short term but could cause severe problems in the future.
Leveraging an external expert to validate the technology decisions is critical to the project’s success.
Ideally, the technology decisions happen before you engage a third party. This way, you can choose the most appropriate agency to take the job. The last thing you want to do is pay for an agency to learn new technologies, which increases risk and delays the project.
Managing a software project is difficult, even for seasoned professionals. If you follow these Dos and Don’ts, you’ll have a better chance of success and save valuable time and money.
If you have an idea for software, I’d love to help you bring it to life.