In-house or outsourced software development.

Outsourced here means hiring a development company or freelancers, wherever they work. The choice is not permanent. A business can outsource the first build, keep the product decisions in its own hands and hire developers later, once the system has proved its value and the workload is steady.

If you have not yet settled whether to build at all, start with build vs buy. The sections below assume you have chosen custom software and compare the three ways of getting it built, then cover what goes wrong and how to prevent it.

No column wins every row. Decide which rows matter most for your project first, then see which option fits those. A team that must start soon and has no developers to manage cares most about the first two rows. A product you expect to run for years cares most about continuity and ownership.

• Recruiting time: finding, interviewing and hiring each developer takes your time or a recruiter's, and the seat stays empty until someone starts.
• Benefits and payroll costs: an employer pays benefits, taxes and payroll administration on top of pay.
• Tools and cloud: licenses, test devices, hosting and monitoring are yours to buy and maintain.
• Management time: someone must plan the work, review it and handle people matters. If that someone is you, it comes out of your own week.
• Turnover: when a developer leaves, you pay to recruit again, and knowledge of the system leaves too.

Costs on the outsourcing side are different, not absent: a contract, your own management time and the work of reviewing what is delivered. What drives the cost of custom software lists the factors to price on either route.

The risks are the same few each time:

• One person: illness, other clients or a change of job can stop your project.
• Thin testing and support: a single freelancer rarely has a second person to review code or to cover after launch.
• Ownership: the contract must assign the code and designs to you in writing, or you may not own what you paid for.
• Process: with no one reviewing the work, quality depends on the person alone.

If a freelancer's work will become part of a system your team depends on, treat the engagement like any vendor engagement: write a brief, agree on what done means and keep the repository in your own account.

• Unclear scope: write a brief covering the problem, users, workflows, data and constraints before you ask for quotes. The software project brief template shows how.
• No decision-maker: name one person on your side who can answer questions and approve work within the week. Questions that wait for a committee stall a project.
• Weak ownership terms: make sure the contract states who owns the code, the designs and the data, and read it before work begins.
• Code you can't access: hold the repository yourself. Create it in your own account and give the developers access, rather than the other way around.
• Communication gaps: agree on overlapping working hours, written updates and a decision log, so a decision made on a call is recorded where everyone can read it. Working with a remote software team across time zones covers how.
• Red flags when choosing: vague answers about who does the work, no questions about your process and pressure to sign quickly are warning signs. The red flags section of the vendor guide lists more.

• Priorities and decisions: a product owner who ranks the work and says yes or no.
• Domain knowledge: how your sales, service or operations really run. The vendor learns it from you.
• Acceptance testing: your own users try each release against what you agreed before you accept it.
• Access control: you decide who gets accounts, repositories and credentials, and you remove them when the work ends.
• Vendor management: one person owns the relationship, reviews progress and raises problems early.

Plan for it from the start. Ask the vendor to write documentation as the work goes on, not at the end. Keep a list of every account the system relies on, such as hosting, domains and third-party services, and keep the logins with someone on your team. Have your first in-house hire read the code and documentation while the vendor is still working, so questions get answered before the handover.

Foxefy works remotely, with discovery, reviews and check-ins over video calls. It holds regular check-ins and sends progress updates, so you see the work as it moves instead of at the end. Every project is scoped and quoted after a discovery call.

Foxefy also provides dedicated teams for work that continues after the first release. For what Foxefy builds, see custom software development.

To see how a project runs from first call to support, read how we work. To compare companies before you choose, use the guide to choosing a software development company. When you know what you want built, book a discovery call.