The short answer
Choose an in-house team when software is a continuing core capability that needs long-term product context. Choose a freelancer for one bounded task when your organisation can define, review and integrate the work. Choose an agency when a defined release needs coordinated product, design and engineering responsibility that you do not already have. Compare the three against the same scope, acceptance criteria, ownership rules and operating duties—not salary, day rate or project quote alone.
When does each software delivery model fit?
An in-house team fits recurring product decisions and continuous delivery. A freelancer fits a specific discipline or deliverable inside a system your company already manages. An agency fits a bounded outcome that needs several disciplines and one party responsible for coordinating them. None is automatically cheaper or safer: the result depends on which responsibilities are included and which remain with the buyer.
| Buyer situation | Likely fit | Responsibility the buyer keeps |
|---|---|---|
| Software is a permanent source of product advantage | Build and retain an in-house core | Hiring, management, standards, release and operations |
| One specialist task has a clear definition of done | Engage a qualified freelancer | Product direction, technical review, integration and continuity |
| One release spans product, UX and engineering | Compare accountable agency teams | Business decisions, access control and supplier governance |
| The problem or buyer is still uncertain | Run discovery or a bounded Product Blueprint first | Evidence, priorities and the decision to build |
How should you compare the real cost of each option?
Use one release boundary and one time horizon. An employee salary, a freelancer estimate and an agency proposal measure different things, so placing them in adjacent spreadsheet cells creates a false comparison. Add every cost and responsibility required to reach the same accepted, deployed and supportable outcome.
| Cost or responsibility | Question to answer | Evidence to request |
|---|---|---|
| Product and scope | Who turns the business goal into testable release behaviour? | Named owner, scope assumptions and acceptance criteria |
| Delivery capacity | Which roles and availability are included for this release? | Named roles, allocation and substitution terms |
| Review and quality | Who reviews changes and verifies the agreed behaviour? | Review workflow, test plan and release gate |
| Tools and infrastructure | Which licences, environments and services are additional? | Itemised exclusions and account ownership map |
| Management | Who resolves dependencies, priorities and blocked decisions? | Decision cadence and escalation owner |
| Handover and operation | Who deploys, observes, supports and transfers the system? | Runbook, access-removal plan and handover acceptance test |
For an in-house option, use your organisation's actual payroll, benefits, recruitment, equipment, management and availability assumptions. For a freelancer or agency, use the written proposal and list the work your own team must still perform. Do not rely on generic salary multipliers, regional rate cards or promised start dates as if they were quotations for your project.
What should remain under your company's control?
Your company should normally control the source repository, domain, cloud tenancy, database, payment account and other essential production services. Give each contributor only the access required for the assigned work. GitHub documents granular repository roles from read through admin, which lets an organisation match access to a person's function rather than granting blanket control.
- Create production accounts in the buyer's organisation, not a supplier's personal account.
- Record who can administer code, hosting, data, DNS and third-party integrations.
- Require reviewable changes and keep important decisions with the code or operating documentation.
- Test that another authorised person can build, deploy and recover the system.
- Remove access at the end of a task and verify that the company retains every required asset.
Account ownership does not replace intellectual-property, confidentiality or data-processing terms. Have appropriate advisers review the agreement for the countries, data and relationship involved. Technical access and contractual rights are separate controls, and both need an accountable owner.
How do you compare engineering and security discipline?
Ask every option to demonstrate the same development controls. NIST's Secure Software Development Framework is designed as a common vocabulary for software producers and purchasers; it covers practices that can be integrated into a software development lifecycle. Use relevant controls to frame supplier questions rather than treating a company label as proof of secure delivery.
- How are requirements and security expectations recorded before implementation?
- Who reviews code, dependencies and infrastructure changes before release?
- Which automated and manual checks support the acceptance decision?
- How are findings recorded, prioritised, fixed and retested?
- Who can deploy, observe production and execute the recovery path?
- What documentation and operating evidence must pass before handover?
A freelancer can work inside a strong buyer-owned system, an agency can have weak controls, and an in-house team can accumulate undocumented practices. Evaluate the visible workflow and evidence. The delivery model tells you how responsibility is organised; it does not certify the quality of the work.
Does contractor status change the decision?
Yes, because calling someone a freelancer does not by itself determine their legal or tax status. The US Internal Revenue Service says businesses must consider the whole relationship, including behavioural control, financial control and the type of relationship; it states that no single factor decides the classification. In the UK, GOV.UK explains that employment status affects rights and employer responsibilities, and that tax-law status can differ from employment-law status.
Before designing a long-running individual engagement, obtain jurisdiction-specific advice and document the working arrangement. This article is a product-delivery framework, not employment or tax advice. An agency contract may change the commercial relationship, but it does not remove the need to check access, data, intellectual property and supplier obligations.
What should a paid comparison exercise include?
Give shortlisted options the same bounded release brief. Include the user outcome, current assets, important failure states, constraints, acceptance evidence and responsibilities that must be covered. A short paid discovery or representative task can expose assumptions without granting production access or asking candidates to perform unpaid product work.
- Define one user outcome and the conditions that count as accepted.
- List the product, design, engineering, security and operating roles the release needs.
- Mark which roles already exist internally and which the proposal must supply.
- Ask each option to state assumptions, exclusions, dependencies and required buyer time.
- Compare the route from brief to reviewed change, deployment, operation and handover.
- Select the model whose responsibility boundary matches the work—not the proposal with the fewest visible lines.
Which ApexStack starting point fits this decision?
A Product Blueprint starts from US$1,000 for a bounded planning and de-risking engagement. For this decision, it can define the release boundary, responsibility map, acceptance criteria and comparison brief. It is not a production-ready MVP and does not replace legal, employment or tax advice.
A Launch Sprint starts from US$2,500 and covers planning, UX direction, implementation, testing and deployment for one tightly scoped first release or core workflow. Authentication, billing, mobile apps, advanced AI, multiple integrations, data migration, compliance and extensive administration can increase the quote. Review the current pricing and send the same brief you plan to use for other options so ApexStack can respond against a comparable scope.
Sources
- Independent contractor (self-employed) or employee? — Internal Revenue Service
- Employment status: overview — GOV.UK
- Repository roles for an organisation — GitHub
- Secure Software Development Framework Version 1.1 — National Institute of Standards and Technology
Frequently asked questions
- Is an in-house developer cheaper than a development agency?
- Not necessarily for the same delivered outcome. Compare your actual employment, management, tooling and availability costs with the agency's proposal, then add the product, review, deployment and support work excluded from either option. A salary and a project quote are not like-for-like measures.
- When should a startup hire a freelancer instead of an agency?
- Use a freelancer when the task is bounded, one discipline can complete it, your team can judge the result and your company can integrate and operate the change. Compare an agency when the release needs coordinated responsibility across several disciplines or those buyer-side capabilities are absent.
- Should a startup eventually build an in-house product team?
- An in-house core is a strong fit when software is a continuing source of product advantage and the company needs to retain product context and delivery capability. External specialists or teams can still support bounded releases, reviews or temporary capability gaps around that core.
- Who should own the code when an agency or freelancer builds it?
- The buyer should normally control the repository and essential production accounts, grant role-appropriate access and test that access can be removed without losing the build or deployment path. Contractual ownership and licensing also need explicit review for the specific engagement.
- Can an agency build the first release and hand it to an in-house team?
- Yes, if the transition is designed into the engagement. Define buyer-owned accounts, documentation, review participation, operating runbooks and a handover acceptance test before delivery starts. Do not assume a final archive or walkthrough creates an operable transfer.
How can ApexStack help you compare the three delivery models?
Send ApexStack one release brief, the capabilities already available inside your company and the responsibilities you need covered. We can map the same scope across an in-house hire, individual specialist and accountable product team so the proposals become comparable.