When a business decides to build custom software, one of the first questions is not how to build it, but who should build it.

There are three common choices:

Freelancer → Software Development Company → In-House Team

There is also a fourth option:

Hybrid Team

The right choice depends less on the job title of the people writing the code and more on the complexity, business criticality, required capabilities, ownership expectations, continuity requirements and long-term direction of the product.

Start Here: Which Model Is Right for You?

Use this decision path before comparing the options in detail.

Choose a Freelancer If

The project is:

• Small
• Clearly defined
• Relatively straightforward
• Limited in technical scope
• Dependent on one or two primary skills

Typical examples include:

• Corporate website
• CMS customization
• Small internal tool
• Single API integration
• Frontend implementation
• Automation script
• Focused bug-fixing project

A freelancer can be an excellent choice when the company already has product, technical or QA leadership and mainly needs implementation capacity.

Do not automatically choose a freelancer when the project requires architecture, UX, multiple engineering disciplines, DevOps, security, complex integrations or long-term production support.

---

Choose a Software Development Company If

The project requires a cross-functional delivery team.

This may include:

• Product management
• Business analysis
• UX/UI
• Architecture
• Frontend development
• Backend development
• Mobile development
• QA
• DevOps
• Cloud engineering
• Security
• Data engineering
• AI engineering

A development company is especially useful when the business needs several capabilities quickly without first building an entire engineering organization.

---

Choose an In-House Team If

Software is becoming a long-term strategic capability rather than a one-time project.

An internal team becomes more attractive when:

• Software is the product.
• Technology is a competitive advantage.
• Development will continue for years.
• Requirements change continuously.
• Deep business knowledge needs to stay inside the organization.
• Engineering is itself a strategic capability.

---

Choose a Hybrid Model If

The business wants internal ownership but lacks some of the skills or capacity required to deliver the product.

For example:

Internal: Product Management + Technical Ownership

External: Engineering + QA + DevOps + Specialist Expertise

This can work particularly well when a company is building its first engineering organization, modernizing legacy systems or needs temporary specialist capacity.

---

The 60-Second Decision Test

Question	If Yes, Consider
Is the project small and narrowly defined?	Freelancer
Does it require several technical disciplines?	Development Company
Is the product strategically important?	In-House / Hybrid
Will development continue for years?	In-House / Hybrid
Do you lack specialist technical skills?	Development Company / Hybrid
Do you want internal ownership with external capacity?	Hybrid
Is the software business-critical?	Development Company / In-House / Hybrid
Can one person safely own the architecture and delivery?	Freelancer may work
Will the team need to scale up or down during delivery?	Development Company / Hybrid

A useful shorthand is:

Small + simple → Freelancer Complex + project-based → Development Company Strategic + continuous → In-House Strategic + capability gap → Hybrid

These are starting points, not automatic answers.

---

TL;DR

Choose a freelancer when:

• The project is relatively small.
• Scope is clearly defined.
• Technology is straightforward.
• One or two primary skills are sufficient.
• The business can manage the project closely.
• Business continuity risk is low.

Choose a software development company when:

• The project requires multiple disciplines.
• Architecture, UX/UI, development, QA and DevOps must work together.
• You need a complete delivery team quickly.
• The product is too complex for one developer.
• You need structured project management.
• You do not want to build an engineering organization immediately.

Choose an in-house team when:

• Software is strategically central to the business.
• Product development is continuous.
• The company needs deep, long-term product ownership.
• Requirements and priorities change frequently.
• Building internal engineering capability is itself a strategic objective.

Choose a hybrid model when:

• Product ownership should remain internal.
• External expertise is required.
• Specialist skills are missing internally.
• Temporary engineering capacity is needed.
• The company is gradually building its own engineering organization.

---

What This Decision Is Really About

The common way to compare these models is:

Freelancer vs agency vs employees.

That is too narrow.

A better question is:

Which delivery model gives this project the capabilities, ownership, continuity and operating discipline it requires?

A serious software project may require:

• Product management
• Business analysis
• UX/UI
• Solution architecture
• Frontend development
• Backend development
• Mobile development
• QA
• DevOps
• Cloud engineering
• Security
• Data engineering
• AI engineering
• Project management
• Technical documentation

One person may cover several of these roles.

A development company may provide them as a team.

An internal organization may build them over time.

The decision is therefore fundamentally a capability and ownership decision. It's the same ownership question that comes up when deciding whether to build custom software at all or buy an existing SaaS product — both ask what the business actually needs to own versus consume.

---

What Actually Determines Software Delivery Performance?

The number of developers on a project does not, by itself, tell you whether the project is positioned to deliver successfully.

Ortem evaluates software delivery readiness using the Ortem Software Delivery Performance Index (OSDPI).

OSDPI evaluates ten factors that influence the ability of a software team to move from requirements to production:

Delivery Dimension	Weight	What Ortem Evaluates
Product Clarity	15%	Requirements, priorities, business rules and decision readiness
Architecture Readiness	10%	Architecture, technical decisions and system boundaries
Team Capability	15%	Required skills, seniority and role coverage
Execution Flow	10%	Work breakdown, dependencies between tasks and delivery coordination
Quality & Testing	10%	Test coverage, QA capability and defect prevention
Deployment Readiness	10%	Environments, CI/CD, release process and rollback capability
Feedback Speed	10%	Speed of discovering and resolving incorrect assumptions or defects
Dependency Readiness	5%	APIs, credentials, data, infrastructure and third-party dependencies
Operational Readiness	10%	Monitoring, security, backups and production support
Ownership & Continuity	5%	Documentation, knowledge distribution and ability to transfer responsibility
Total	100%

Each dimension is scored from 0 to 5.

The overall score is:

OSDPI = Σ (Dimension Score ÷ 5 × Dimension Weight)

This produces a score between 0 and 100.

OSDPI Interpretation

Score	Interpretation
85–100	Highly prepared delivery environment
70–84	Strong delivery readiness
55–69	Moderate delivery risk
40–54	High delivery risk
0–39	Significant readiness gaps

However, the overall score should not hide a critical weakness.

If any of the following dimensions scores below 2/5, the project should be treated as constrained until the issue is addressed:

• Product Clarity
• Architecture Readiness
• Team Capability
• Dependency Readiness
• Operational Readiness

For example, a project could achieve a reasonable overall score while having no access to a critical third-party API.

The average score would not remove that dependency.

This is why OSDPI uses both an overall score and critical-factor checks.

---

Why OSDPI Matters When Choosing a Delivery Model

The same project can produce very different OSDPI profiles under different delivery models.

A freelancer may score highly on:

Specialist capability

but lower on:

Role coverage, continuity and operational support

A development company may score highly on:

Team breadth, delivery capacity and specialist coverage

while requiring stronger client-side:

Product ownership and decision-making

An internal team may score highly on:

Domain knowledge and long-term ownership

while initially scoring lower on:

Team completeness and specialist availability

A hybrid model can potentially improve those gaps by combining internal ownership with external capabilities.

This gives a business a more useful question than:

"Which type of developer should we hire?"

The better question is:

"Which delivery model produces the strongest delivery system for this particular project?"

---

OSDPI Is an Ortem Framework

OSDPI is an Ortem Technologies analytical framework, not a claim that these weights or thresholds are an industry-wide standard.

The framework can be used immediately as a structured decision tool.

As Ortem accumulates anonymized project data, the methodology can be expanded into an empirical benchmark showing how OSDPI scores correlate with outcomes such as:

• Schedule variance
• Budget variance
• Defect rates
• Post-launch incidents
• Rework
• Project changes
• Delivery predictability

That future dataset could allow Ortem to publish:

Ortem Software Delivery Benchmark Report

Ortem Development Team Cost Benchmark

Ortem Project Delivery Dataset

Ortem Software Delivery Model Index

The distinction matters.

A methodology should not be presented as empirical research until it has been tested against a documented dataset.

---

1. When a Freelancer Makes Sense

A freelancer can be an excellent choice for the right type of project.

Freelancers are often effective when the work is:

• Small
• Well-defined
• Technically straightforward
• Narrowly scoped
• Independently deliverable

Examples include:

• Corporate website
• CMS customization
• Small internal tool
• Specific API integration
• Bug-fixing project
• Frontend implementation
• Automation
• Specialized technical work

A freelancer can also work extremely well as part of an existing internal engineering organization.

For example, a company may already have a technical lead and QA team but need a specialist for:

• React development
• Mobile development
• AI integration
• Cloud migration
• Performance optimization

In that situation, the freelancer fills a defined capability gap rather than becoming the entire delivery organization.

---

2. Where Freelancer Models Become Riskier

Risk increases as project complexity grows.

Consider a system requiring:

• Multi-tenant architecture
• Mobile applications
• Payment integration
• SSO
• Cloud infrastructure
• Data migration
• Security controls
• Automated testing
• Production monitoring

One freelancer may have excellent programming skills.

But the project may require more than programming.

The client may suddenly become responsible for coordinating:

Designer

Developer

QA

DevOps

Security

Product decisions

The coordination itself becomes a delivery responsibility.

The question is therefore not:

"Is the freelancer good enough?"

It is:

"Does the delivery system around the freelancer provide everything the project requires?"

---

3. Advantages of Hiring a Freelancer

Lower initial organizational overhead

The business can access technical capability without creating a full engineering organization.

Direct communication

Clients often communicate directly with the person doing the work.

Flexibility

A freelancer can be useful for narrowly defined assignments.

Specialized expertise

An experienced specialist can be extremely valuable for a specific technical problem.

Good fit for existing teams

Freelancers can increase implementation capacity without replacing internal ownership.

---

4. Risks of a Freelancer Model

Potential risks include:

Single-person dependency

What happens if the freelancer becomes unavailable?

Limited specialization

One person may not cover architecture, security, QA and DevOps equally well.

Continuity risk

Knowledge may become concentrated in one person.

Capacity constraints

A freelancer has limited bandwidth.

Management burden

The client may need to coordinate requirements, testing, deployment and priorities.

Documentation risk

Documentation quality depends heavily on the individual and the agreement.

These risks can be managed through:

• Client-owned repositories
• Documentation requirements
• Testing standards
• Individual access controls
• Clear handover requirements

---

5. When a Software Development Company Makes Sense

A software development company is often appropriate when the project requires a cross-functional delivery team.

For example:

Product

Defines priorities and requirements.

UX/UI

Designs user journeys and interfaces.

Architecture

Defines the technical system.

Engineering

Builds the application.

QA

Tests workflows and integrations.

DevOps

Manages infrastructure and deployment.

Project management

Coordinates scope, schedule, risks and communication.

A development company can provide these capabilities without requiring the client to hire each role individually.

However, hiring a company does not automatically solve delivery risk.

The actual team, experience, engineering discipline and ownership model still matter.

---

6. The Real Advantage of a Development Company

The strongest reason to hire a development company is not simply that it has "more developers."

It is that it can provide complementary capabilities as a coordinated team.

Consider an enterprise SaaS platform.

The project may require:

• Senior architect
• Backend engineer
• Frontend engineer
• Product designer
• QA engineer
• DevOps specialist
• Project manager

Hiring every role permanently may not make sense for a business building one new product.

A development company can assemble an appropriate team around the project.

---

7. A Development Company Does Not Automatically Mean Better Quality

An agency can still fail because of:

• Weak project management
• Inexperienced engineers
• Poor architecture
• High staff turnover
• Misaligned incentives
• Sales promises that exceed delivery capability
• Weak QA
• Poor documentation
• Undisclosed subcontracting
• Insufficient technical leadership

External sourcing therefore requires its own evaluation process.

The client should evaluate the actual delivery team rather than selecting a company solely because its website or portfolio looks impressive.

---

8. What to Verify When Hiring a Development Company

Ask:

Who will actually build the product?

Do not evaluate only the sales team.

Who is the technical lead?

Who owns architecture?

Who performs QA?

Who handles production infrastructure?

Who manages security?

Who remains after launch?

How much of the work is subcontracted?

Have they delivered systems with similar complexity?

Can you speak to previous clients?

Can they explain how they estimate risk?

Can they explain what happens when scope changes?

These questions turn vendor selection into an evidence-based evaluation rather than a branding exercise. For the complete set, see what questions to ask before hiring a software development company — and once you have proposals in hand, how to compare them fairly.

---

9. When an In-House Team Makes Sense

An internal engineering organization becomes attractive when software is not simply a project.

It is a long-term capability of the business.

Examples include companies where:

• Software is the primary product.
• Technology is a major competitive advantage.
• Product requirements change continuously.
• Engineering decisions directly affect business strategy.
• The company expects years of continuous development.
• Deep domain knowledge needs to remain inside the company.

In these situations, engineering capability itself becomes an organizational asset.

---

10. Advantages of an In-House Team

Deep domain knowledge

Engineers become familiar with the business.

Product proximity

Engineering can work closely with users and business teams.

Long-term ownership

Knowledge stays inside the organization.

Rapid iteration

Product and engineering can operate as one continuous function.

Strategic control

Technology decisions remain directly within the business.

Institutional knowledge

Technical and business knowledge accumulates over time.

These advantages can be especially significant for software companies and digital-first businesses.

---

11. The Hidden Cost of Building an In-House Team

Hiring developers is not the same as creating an engineering organization.

An internal team may require:

• Recruiting
• Salaries
• Benefits
• Management
• Engineering leadership
• QA
• DevOps
• Security
• Product management
• Development tools
• Infrastructure
• Training
• Retention
• Replacement hiring

A company may hire three developers and still lack:

• Architecture leadership
• Product management
• QA
• Cloud expertise
• Security expertise

The result can be a team that is large enough to create software but not mature enough to operate it reliably.

---

12. In-House Does Not Automatically Mean Faster

An internal team can still move slowly.

The key factors are not simply headcount.

Consider:

• Product decision speed
• Architecture quality
• Team composition
• Communication
• Testing
• Deployment
• Feedback cycles
• Dependencies
• Operational readiness

A six-person team with clear ownership and strong delivery practices can outperform a larger team that constantly waits for decisions, works around dependencies or discovers defects late.

This is one reason Ortem evaluates the complete delivery system through OSDPI rather than using team size as a proxy for delivery capability.

---

13. The Hybrid Model

The hybrid model is often overlooked.

It can look like:

Internal team

Owns:

• Product strategy
• Business knowledge
• Priorities
• Technical ownership
• Architecture decisions

External team

Provides:

• Additional engineers
• Specialized expertise
• QA
• UX
• DevOps
• Temporary capacity

This can provide internal ownership without requiring the company to build every specialist capability immediately.

---

14. When Hybrid Is Particularly Useful

Hybrid teams can make sense when:

You are building your first product team

External engineering capacity accelerates development while internal capability grows.

You need specialist expertise

For example:

• AI
• Cybersecurity
• Cloud architecture
• Data engineering
• Mobile development

You have a temporary workload spike

External capacity can be added without permanent hiring.

You need modernization

An external team can help modernize legacy systems while internal teams retain knowledge.

You want knowledge transfer

The external team can develop, document and train the internal team.

---

15. Freelancer vs Development Company vs In-House: Cost

Cost comparisons can be misleading.

Freelancer

You may pay directly for engineering capacity.

But may also need:

• Design
• QA
• DevOps
• Project management
• Security
• Additional specialists

Development company

The quoted price may include several disciplines.

The price can therefore be higher than a single developer's rate while requiring less client-side coordination.

In-house

You pay for the complete employment relationship and organizational capability.

The cost includes much more than salary.

A better comparison is:

Total delivery cost = people + management + tools + infrastructure + coordination + risk + continuity

---

16. Do Not Compare Hourly Rates Alone

Suppose:

Freelancer

$40/hour

Development company

$90/hour

It is tempting to conclude that the freelancer is more than twice as cost-effective.

But this assumes both are providing the same output.

If the company rate includes:

• Project management
• QA
• Architecture
• DevOps
• Security
• Documentation

while the freelancer rate covers only development, the comparison is not equivalent.

Compare delivered capability, not hourly rate.

---

17. Complexity Should Influence the Delivery Model

A useful starting point is:

Low complexity

Freelancer can often work well.

Moderate complexity

Freelancer, development company or hybrid can work depending on internal capability.

High complexity

Development company, internal team or hybrid is usually more appropriate.

But complexity alone is not enough.

A small application containing sensitive data or a business-critical workflow may require a more mature delivery model than its screen count suggests.

---

18. Business Criticality Matters More Than Project Size

Consider two applications.

Application A

A simple internal calculator.

If it goes offline for a day, little happens.

Application B

A small payment-processing service.

It may contain fewer screens, but a failure can directly affect revenue.

Application B may require:

• Monitoring
• Incident response
• Security
• Backups
• Disaster recovery
• Strong testing

Therefore:

Choose the delivery model based on both technical complexity and business criticality.

---

19. Security and Regulatory Requirements

Security-sensitive systems may require broader organizational capability.

Consider:

• Authentication
• Access controls
• Audit logging
• Encryption
• Security testing
• Data retention
• Incident response
• Compliance reporting

A single freelancer may be technically capable of building part of such a system.

The question is whether the overall delivery and operational model provides enough assurance.

---

20. Continuity and Key-Person Risk

Ask:

What happens if the person or organization responsible for this software becomes unavailable tomorrow?

For a freelancer:

• Is the source code in a client-controlled repository?
• Is documentation current?
• Can another developer understand the system?
• Are infrastructure accounts client-owned?

For an agency:

• What happens if the lead engineer leaves?
• Is knowledge distributed?
• Is the project documented?
• Can another team member take over?

For an internal team:

• What happens if the engineering lead resigns?
• Is there sufficient organizational knowledge?

Continuity should therefore be designed into the project regardless of delivery model.

---

21. Intellectual Property and Ownership

Before starting work, clarify:

• Source-code ownership
• Documentation ownership
• Design ownership
• Data ownership
• Infrastructure ownership
• Third-party libraries
• Reusable components
• AI prompts and configurations
• Model-related assets

Ownership should align with the contract and SOW — this is exactly what a properly scoped Statement of Work is meant to pin down before work starts, regardless of which delivery model you choose.

The client should also know whether the software can be transferred to another development team.

---

22. Communication and Time-Zone Considerations

Communication overhead becomes more important as a project becomes more complex.

Consider:

• Time-zone overlap
• Response expectations
• Meeting cadence
• Documentation practices
• Decision-making process
• Language
• Escalation

A distributed team can work extremely well when these processes are designed deliberately.

---

23. The Ortem Delivery Model Decision Matrix

A comparison table is useful, but it should produce a decision rather than just provide information.

Use the following scoring system.

Step 1: Score Each Model

Score each model from 1 to 5:

Score	Meaning
1	Poor fit
2	Weak fit
3	Acceptable
4	Strong fit
5	Excellent fit

Score Freelancer, Development Company and In-House separately.

---

Step 2: Apply the Weights

Start with these weights:

Decision Factor	Weight
Project complexity	15
Business criticality	15
Required technical breadth	15
Speed to assemble capability	10
Long-term product ownership	10
Internal technical capability	10
Scalability of delivery capacity	5
Security / compliance capability	5
Continuity / key-person risk	5
Budget flexibility	5
Specialized expertise required	5
Total	100

Calculate:

Weighted Points = Score × Weight

Each model receives a score between 100 and 500.

The highest-scoring model becomes the initial recommendation, not the automatic final decision.

---

24. How to Score the Matrix

Use evidence from the actual project.

Project complexity

Freelancer

Score high when the project is small and technically narrow.

Development company

Score high when multiple disciplines are required.

In-house

Score high when the product will become a long-term engineering capability.

Business criticality

Score models higher when they can provide the operational redundancy and support the business actually requires.

Technical breadth

Score higher when the model can realistically provide:

• Architecture
• Engineering
• QA
• DevOps
• Security
• Data
• AI

Speed to assemble capability

A mature development company may score highly when the business needs a complete team immediately.

An in-house model generally scores lower initially because recruiting takes time.

Long-term ownership

In-house usually scores highest when the product will be continuously developed for years.

Internal technical capability

If strong technical leadership already exists internally, an external engineering team may integrate effectively.

---

25. Example Decision

Imagine a company is building a medium-complexity B2B SaaS platform.

It requires:

• Web application
• Backend API
• Database
• Multiple user roles
• Payment integration
• Admin portal
• QA
• Cloud infrastructure
• Ongoing development

The company currently has:

• One founder
• One product manager
• No engineering team

A possible scoring could look like:

Factor	Weight	Freelancer	Development Company	In-House
Project complexity	15	2	5	4
Business criticality	15	2	5	5
Technical breadth	15	2	5	5
Speed to assemble	10	4	5	1
Long-term ownership	10	2	3	5
Internal capability	10	1	5	1
Delivery scalability	5	2	4	5
Security / compliance	5	2	4	5
Continuity	5	2	4	5
Budget flexibility	5	5	3	2
Specialist expertise	5	3	5	3

Calculate:

Weighted Score = Score × Weight

The result provides a directional comparison:

Freelancer: weak fit

Development company: strongest immediate fit

In-house: potentially strongest long-term ownership model but expensive and slower to establish initially

The practical answer may therefore be:

Start with a development company or hybrid model, while building internal product and technical ownership over time.

---

26. Critical Risk Overrides

A weighted score should not automatically decide the engagement model.

Run these tests before signing.

Override 1 — Missing Capability

If the chosen model cannot provide a capability essential to delivery, stop and reassess.

Override 2 — Key-Person Dependency

If one person leaving would seriously jeopardize the project, introduce redundancy.

Override 3 — Business-Critical Operation

If the software directly affects revenue, customers or core operations, require an appropriate production support model.

Override 4 — Security Requirement

If the chosen model cannot provide the required security capability, the score is irrelevant.

Override 5 — Long-Term Ownership

If the product will become a permanent strategic asset, decide explicitly who will own the product and technical knowledge after the initial build.

---

27. When a Freelancer Is the Better Choice

A freelancer is often appropriate when most of these are true:

• The scope is relatively small.
• Requirements are clear.
• Technology is familiar.
• One primary specialization is sufficient.
• The business can manage delivery.
• QA and deployment are relatively simple.
• Business continuity risk is low.

---

28. When a Development Company Is the Better Choice

A development company is often appropriate when:

• Multiple disciplines are required.
• The business needs a complete team quickly.
• The project is more complex than one developer can safely own.
• The client lacks technical leadership.
• External specialist expertise is required.
• The project has a defined beginning and end.
• The company does not yet want to establish a full engineering organization.

---

29. When In-House Is the Better Choice

An internal team becomes more compelling when:

• Software is the core product.
• Product development will continue indefinitely.
• Deep domain expertise is strategically important.
• Product and engineering need constant interaction.
• The company expects significant technical investment.
• Engineering itself is a strategic capability.

---

30. When Hybrid Is the Better Choice

Hybrid is particularly attractive when:

• The company has product leadership but limited engineering capacity.
• External specialists are required.
• Internal employees should retain ownership.
• Workload is temporarily higher than internal capacity.
• The organization is building its first engineering team.

For example:

Internal product manager + internal technical owner + external engineering team + internal QA.

This allows strategic ownership to remain internal while delivery capacity scales externally.

---

31. Why the Cheapest Delivery Model Can Be the Most Expensive

Consider:

Freelancer

$35,000

Development company

$70,000

In-house team for six months

$150,000+

The freelancer may appear to be the obvious choice.

But the project may later require:

• Additional QA
• Architecture consulting
• DevOps support
• Security testing
• Project management
• Rework

The original price is no longer comparable.

The correct comparison is:

Total cost to achieve the required outcome

rather than:

Lowest developer rate

---

32. A Better Way to Compare the Models

For each option, calculate:

Delivery cost

People and services.

Management cost

Internal time required to coordinate the model.

Infrastructure cost

Cloud and tooling.

Specialist cost

Additional expertise.

Risk cost

Potential cost of failure, rework or delay.

Continuity cost

Potential cost of knowledge loss or replacement.

Long-term cost

Maintenance and support.

This produces a more realistic Total Delivery Cost.

---

33. Questions to Ask Before Choosing

Ask:

What happens if the lead developer leaves?

Who owns the architecture?

Who tests the product?

Who handles production incidents?

Who makes technical decisions?

Who manages changing requirements?

Who owns the repository?

Who controls production infrastructure?

Who documents the system?

Can another team take over?

What happens after launch?

The more important the application, the more important these questions become.

---

34. Delivery Model Decision Checklist

Project

• Is the scope clearly defined?
• How complex are the workflows?
• How many technical disciplines are required?
• Is the software business-critical?

Freelancer

• Can one person realistically deliver the work?
• Is specialist support available if required?
• Is continuity protected?
• Can the client manage delivery?

Development Company

• Is the actual delivery team identified?
• Are architecture and QA included?
• Is DevOps covered?
• Are relevant references available?
• Is subcontracting disclosed?

In-House

• Is technical leadership available?
• Is QA covered?
• Is DevOps covered?
• Is security covered?
• Can the organization recruit and retain the required skills?

Hybrid

• Is ownership clearly defined?
• Who makes technical decisions?
• Who manages priorities?
• How will knowledge transfer work?
• What work remains internal?

Ownership

• Source-code ownership is clear.
• Repository ownership is clear.
• Infrastructure ownership is clear.
• Data ownership is clear.
• Documentation ownership is clear.
• Exit and handover obligations are defined.

---

Common Mistakes When Choosing a Software Development Team

1. Choosing on Hourly Rate

Cost per hour is not equivalent to cost per outcome.

2. Choosing on Portfolio Appearance

A polished portfolio does not prove delivery capability.

3. Talking Only to Sales

The people selling the project may not be the people delivering it.

4. Hiring Developers Without Technical Leadership

A team can write code without having a coherent architecture.

5. Ignoring QA

Development and quality assurance are different responsibilities.

6. Ignoring Production

Someone must own deployment, monitoring, backups and incidents.

7. Ignoring Continuity

The project should survive personnel changes.

8. Assuming In-House Means Lower Risk

Internal teams can still suffer from skill gaps, turnover and slow decisions.

9. Assuming Agencies Are Automatically Safer

Vendor selection and management still matter.

10. Ignoring the Post-Launch Model

The team that builds the software may not be the right long-term maintenance model.

---

A Practical Rule of Thumb

Small + simple + clearly defined

→ Freelancer or specialist.

Medium + cross-functional + project-based

→ Development company or hybrid.

Complex + business-critical + continuously evolving

→ In-house or hybrid, potentially with an external development company providing additional capacity.

Strategic software product

→ Build internal product ownership regardless of whether engineering execution is partly outsourced.

---

Ortem Delivery Model Framework

At Ortem Technologies, we recommend evaluating five layers before selecting a software delivery model:

1. Complexity

How difficult is the software to build and operate?

2. Capability

How many different skills are required?

3. Ownership

How deeply should the business own the product and technical knowledge?

4. Continuity

What happens if people or providers change?

5. Economics

What is the total cost of achieving and maintaining the required outcome?

The strongest delivery model is the one that balances all five.

---

Building an Ortem Evidence Base

The decision framework above is an Ortem methodology.

It should not be called empirical research until Ortem has collected and analyzed its own documented dataset.

A future Ortem research program could collect anonymized information across:

• Project type
• Project complexity
• Delivery model
• Team composition
• Initial estimates
• Actual delivery duration
• Budget
• Scope changes
• Defect rates
• Post-launch incidents
• Maintenance requirements
• Client approval delays
• Technical dependencies
• Delivery outcomes

With sufficient data, Ortem could publish industry benchmarks such as:

Ortem Software Delivery Benchmark Report

Ortem Development Team Cost Benchmark

Ortem Project Delivery Dataset

Ortem Software Delivery Model Index

That would allow Ortem to progress from an expert methodology to genuine, evidence-backed industry research.

Until such a dataset exists, the accurate terminology is:

Ortem Delivery Model Decision Framework

rather than:

Ortem research proves...

That distinction strengthens credibility.

---

Final Takeaway

There is no universally best way to build software.

A freelancer can be ideal for a focused project and unsuitable for a complex enterprise platform.

A development company can provide architecture, engineering, QA, DevOps and project-management capabilities, but the provider still needs to be evaluated carefully.

An in-house team provides deep long-term ownership and domain knowledge but requires investment in hiring, leadership and engineering operations.

A hybrid model can combine internal ownership with external expertise and capacity.

The most important question is therefore not:

"Which option is cheapest?"

It is:

"Which delivery model provides the capabilities, ownership, continuity and operating discipline this software requires?"

The Ortem Software Delivery Performance Index (OSDPI) provides one way to make that decision more explicit by evaluating product clarity, architecture, team capability, execution, quality, deployment, feedback, dependencies, operations and continuity rather than focusing only on developer count.

Need Help Choosing the Right Software Development Model?

Before hiring a freelancer, signing an agency contract or committing to an internal engineering organization, evaluate your project across:

Complexity

Business criticality

Technical breadth

Security

Required ownership

Continuity

Delivery speed

Total cost

Ortem Technologies can help assess those factors and determine whether your project is better suited to:

A specialist freelancer

A complete software development team

An internal engineering organization

A hybrid delivery model

Or a combination that changes as the product matures.

Talk to Ortem Technologies before choosing your software delivery model. We can help you evaluate the project, define the capabilities required and design a delivery structure around the actual needs of your business.

Discuss Your Software Development Team Requirements →

Methodology note: The OSDPI scoring framework, decision matrices and thresholds in this article are Ortem Technologies' analytical tools, not universal industry standards. They should be treated as structured planning aids until validated against a sufficiently large Ortem project dataset. External research should be used as supporting context rather than presented as Ortem's own research.