There is no single number of weeks or months that applies to every custom software project.

A simple internal application can sometimes be delivered in a matter of weeks. A medium-sized business platform may take several months. A complex SaaS, enterprise platform, marketplace or AI system can require substantially longer.

The difficulty is that software timelines are often presented as if they were simple feature-count calculations:

"There are 50 features, so the project will take X months."

That approach is unreliable.

Software delivery time depends not only on what needs to be built, but also on how clearly it is defined, how complex the workflows are, what systems it must integrate with, what data must be migrated, how much testing is required, how quickly decisions are made, and how ready the project is for production.

Project-estimation guidance from PMI emphasizes that credible estimates require defined scope, a structured work breakdown, resources, assumptions and schedule considerations rather than simply selecting a target date.

DORA's current software-delivery research also makes an important distinction: delivery performance is not simply about going faster. It looks at both throughput and instability, including change lead time, deployment frequency, failed-deployment recovery time, change-failure rate and deployment rework rate.

So the better question is:

How much calendar time does this particular software project require to become genuinely production-ready?

---

Quick Answer: How Long Does Custom Software Development Take?

The following are Ortem Technologies planning ranges, not universal industry standards.

They assume a professionally managed project with defined scope, an appropriately staffed team, reasonable client availability and no major unresolved external dependencies.

Project Profile	Typical Planning Range
Small internal application	6–12 weeks
Small business web application	8–16 weeks
Medium custom business platform	3–6 months
SaaS MVP	3–6 months
More complete SaaS platform	6–12+ months
Marketplace or multi-sided platform	6–15+ months
Enterprise business platform	9–18+ months
AI-enabled application	3–9+ months
Large enterprise or AI platform	9–18+ months

These ranges should not be treated as promises.

Two projects that appear to belong to the same category can have dramatically different timelines.

For example, a customer portal with authentication and five workflows may be relatively straightforward.

A customer portal with the same number of workflows may become significantly more complex if it also requires:

• SSO
• Role-based permissions
• Legacy data migration
• Multiple external APIs
• Audit logging
• Complex approval rules
• High availability
• Security testing
• AI functionality

The feature count may look similar.

The engineering problem is not.

---

The Most Important Distinction: Effort vs Calendar Time

One of the most common mistakes in software estimation is confusing engineering effort with elapsed project time.

Suppose a project requires 1,200 hours of engineering work.

That does not automatically mean:

1,200 ÷ 40 = 30 weeks.

Real projects contain:

• Design
• Architecture
• Code review
• Testing
• Deployment
• Meetings
• Dependencies
• Approvals
• Rework
• Parallel work
• Waiting time

PMI guidance similarly distinguishes the work required, the resources available and the schedule in which that work can realistically be delivered.

A useful conceptual model is:

Calendar Time ≠ Total Engineering Hours ÷ Number of Developers

A better model is:

Calendar Time ≈ Work + Dependencies + Validation + Coordination + Uncertainty

Some of those activities can happen in parallel.

Others cannot.

That is why simply adding more developers does not always reduce a six-month project to three months.

---

A Better Way to Think About Software Timeline

A software project has at least five different clocks running at the same time.

1. Discovery Time

Time required to understand the problem, users, workflows, requirements and constraints.

2. Engineering Time

Time spent designing, coding, integrating and configuring the product.

3. Validation Time

Time required for QA, security testing, performance testing, UAT and stabilization.

4. Dependency Time

Time spent waiting for:

• Client decisions
• API access
• Data
• Third-party approvals
• Infrastructure
• Content
• External systems

5. Production Readiness Time

Time required to make the application operationally ready, including:

• Deployment
• Monitoring
• Backup
• Security configuration
• Documentation
• Handover

A timeline that only counts coding time is therefore incomplete.

---

How Ortem Estimates Software Timelines

Ortem's approach is based on separating the factors that make a project larger, more uncertain or more difficult to validate.

We call this the:

Ortem Software Timeline Complexity Framework

A project is evaluated across nine dimensions:

Dimension	What Is Being Evaluated?
Scope	Number and breadth of business capabilities
Workflow Complexity	Rules, approvals and business logic
User Complexity	Roles, permissions and user types
Integration Complexity	APIs, third-party systems and webhooks
Data Complexity	Existing data, migration and transformation
Technical Complexity	Architecture, infrastructure and technology constraints
Security	Access, audit, encryption and security requirements
Validation	QA, performance, security and acceptance testing
Dependency Complexity	Client, vendor and external-system dependencies

The framework is not an industry standard.

It is an Ortem planning framework designed to make timeline assumptions more visible.

That distinction is important.

A good estimation methodology should expose the variables behind the number rather than simply produce a number.

PMI's estimating guidance similarly emphasizes defining work, scope metrics, resources, assumptions and formulas rather than relying purely on a top-down date.

---

1. Scope Complexity

Scope is more than the number of features.

Consider:

User can create an account.

versus:

Organization administrators can invite employees, assign roles, enforce permissions, configure authentication policies and manage account status.

Both may appear as one feature.

The second contains substantially more business and technical work.

When estimating scope, look at:

• Modules
• Workflows
• Business rules
• Reports
• Notifications
• Roles
• Settings
• Administrative functions
• Edge cases

A useful estimate breaks the product into work packages, not just a list of feature names.

PMI describes work breakdown structures as a way of defining the lowest-level work packages that contain scope, assumptions, resources, schedules and completion criteria. This is the same discipline behind a well-built Statement of Work — a SOW that only lists feature names, without a work breakdown underneath, is a common source of the estimate being wrong later.

---

2. Workflow Complexity

Business workflows often determine the real difficulty of a product.

For example:

Simple

Customer submits a contact form.

More complex

Customer submits a service request → request is validated → assigned to a team → manager approves → customer is notified → technician updates status → completion is verified → invoice is generated → finance reconciles the transaction.

The second workflow may involve:

• Multiple roles
• State transitions
• Notifications
• Permissions
• Integrations
• Financial logic
• Audit history
• Error handling

That can require significantly more engineering even though it is technically "one workflow."

---

3. User and Permission Complexity

A product with a single user type is generally simpler than one with many permission levels.

For example:

Customer

Can view own records.

Employee

Can create and update records.

Manager

Can approve records.

Finance

Can access financial information.

Administrator

Can configure the platform.

Super Administrator

Can manage the entire system.

Every additional role can introduce:

• Permission logic
• UI variations
• Security testing
• Workflow exceptions
• Audit requirements

This is why a role matrix should be considered during estimation.

---

4. Integration Complexity

Integrations are among the most common causes of underestimated timelines.

Examples include:

• Payment systems
• CRM
• ERP
• Accounting software
• Identity providers
• Email
• SMS
• Shipping
• Analytics
• AI APIs

An integration should not be estimated as simply:

"Connect API."

A production integration may require:

Authentication → Data mapping → Request → Response → Webhook → Validation → Retry → Failure handling → Reconciliation → Logging → Monitoring

For example, connecting a payment gateway may require handling:

• Successful payments
• Failed payments
• Duplicate requests
• Timeouts
• Webhook delays
• Refunds
• Chargebacks
• Reconciliation

The integration timeline therefore depends on the complete business workflow, not just API connectivity.

---

5. Data Migration Complexity

Data migration can materially change a project schedule.

A migration may involve:

1. Extracting existing data
2. Understanding its structure
3. Cleaning invalid records
4. Mapping fields
5. Deduplicating records
6. Transforming data
7. Importing test data
8. Validating results
9. Performing production migration
10. Planning rollback

A company migrating ten years of customer and transaction records from several legacy systems may spend substantial engineering effort on migration even if the new application's user interface is relatively simple.

The migration should therefore be estimated as its own workstream.

---

6. Technical and Architectural Complexity

A simple application may look like:

Web → Backend → Database

A more complex platform may involve:

Web Application

↓

API Gateway / Application Layer

↓

Business Services

↓

Database + Cache + Object Storage + Background Workers

with additional connections to:

Payments

Email

Analytics

Search

Authentication

AI Services

Monitoring

Each additional technical component introduces possible dependencies, configuration, testing and operational work.

Enterprise environments can add:

• SSO
• Private networking
• Multiple production regions
• Disaster recovery
• Legacy systems
• Corporate security controls
• Environment segregation

---

7. Security and Compliance Complexity

Security requirements can significantly affect schedule.

Examples include:

• Role-based access
• SSO
• MFA
• Encryption
• Audit trails
• Data retention
• Security scanning
• Penetration testing
• Compliance evidence

A public marketing website and an enterprise application containing sensitive business data should not have the same security assumptions.

Security is not a separate task that can always be "added at the end."

Authentication, authorization, data handling and audit requirements often affect architecture and development from the beginning.

---

8. Testing and Validation Complexity

A project is not production-ready when development stops.

Testing may include:

• Functional testing
• Integration testing
• Regression testing
• Browser testing
• Mobile testing
• Performance testing
• Security testing
• User acceptance testing
• Production smoke testing

A payment platform, for example, may need testing across:

• Successful checkout
• Failed payment
• Retry
• Refund
• Duplicate payment
• Webhook failure
• Order creation
• Inventory update
• Notification

Every important workflow adds validation work. This is also where a clearly written set of acceptance criteria earns its keep — without it, "done" and "tested" become a negotiation instead of a checklist.

---

9. Client and External Dependencies

A development team cannot complete everything independently.

Projects may depend on the client for:

• Requirements
• Business rules
• Content
• Credentials
• Data
• Design approvals
• UAT
• Production approval

They may depend on third parties for:

• API access
• Sandbox accounts
• Technical documentation
• Certifications
• App-store approval
• Infrastructure provisioning

This produces an important distinction:

Engineering duration is not always the same as project calendar duration.

A team may complete its assigned work while the project remains blocked by an external dependency.

PMI research on estimation specifically notes the difficulty of producing reliable estimates when requirements are unclear or significant unknowns remain. This is exactly what a well-scoped pre-development information checklist is meant to close before the clock starts.

---

How Accurate Is a Software Estimate at the Beginning?

An early estimate should normally be treated as an estimate range, not a guaranteed completion date.

Early in a project, many variables remain unresolved.

As the team learns more about:

• Requirements
• Architecture
• Integrations
• Data
• Technical constraints
• User behaviour

the estimate can become more precise.

This is one reason a mature planning process progressively refines estimates rather than pretending that a rough discovery-stage estimate has the same confidence as a detailed engineering estimate.

PMI's estimating guidance emphasizes refinement and the use of defined scope, assumptions and historical information to improve estimates.

---

Use a Range, Not a False-Precision Date

Compare:

Launch on September 17.

with:

Estimated production readiness: 18–22 weeks, assuming the current scope, third-party API availability and client approvals within two business days.

The second statement is more useful because it exposes the assumptions.

A responsible timeline should ideally contain:

Optimistic case

What happens if major risks do not materialize?

Expected case

What should happen under normal project conditions?

Constrained case

What happens if known dependencies or risks take longer?

The exact terminology can vary.

The principle is what matters:

Uncertainty should be represented rather than hidden.

---

A Practical Timeline Estimation Formula

A useful planning model is:

Estimated Calendar Time = Core Delivery Work + Dependencies + Validation + Launch Work + Uncertainty Allowance

Where:

Core Delivery Work

Design, architecture, development and integration.

Dependencies

Client decisions, third-party systems, data and external approvals.

Validation

QA, security, performance, UAT and stabilization.

Launch Work

Infrastructure, deployment, monitoring, documentation and handover.

Uncertainty Allowance

Reasonable allowance for known risk and unresolved assumptions.

This is a planning model, not a mathematical law.

Its purpose is to force the estimate to account for work that is often forgotten.

---

Why Adding More Developers Does Not Automatically Make a Project Faster

Suppose a project has:

• One architect
• Four developers
• Two QA engineers

Adding four more developers does not necessarily cut the duration in half.

Why?

Because some work is sequential.

Examples include:

• Architecture decisions
• Database design
• Core technical setup
• Product decisions
• Integration dependencies
• Code reviews
• Release approvals

Larger teams can also create additional coordination overhead.

The goal should therefore be to build the right team for the critical path, not simply the largest possible team.

---

How the Critical Path Affects the Timeline

The critical path consists of work that directly affects the earliest possible completion date.

For example:

Architecture

↓

Database foundation

↓

Core backend

↓

Payment integration

↓

End-to-end checkout testing

↓

Production deployment

Even if other work progresses in parallel, delays in these dependencies can delay the launch.

A timeline should therefore identify:

• Critical dependencies
• Sequential work
• Parallel work
• External blockers
• Approval points

---

Example: Small Internal Application

Consider an internal operations application with:

• Three user roles
• Ten core workflows
• Basic reporting
• Email notifications
• One external integration
• Web interface
• No complex migration

A reasonable planning model could be:

Phase	Example Duration
Discovery	1–2 weeks
UX/UI	1–3 weeks
Architecture/setup	1–2 weeks
Development	5–8 weeks
Integration	1–2 weeks
QA/UAT	2–3 weeks
Deployment/handover	1–2 weeks

Some phases overlap, so the total calendar duration is not the arithmetic sum.

A project of this type may fit within roughly 6–12 weeks, depending on the actual scope and dependencies.

---

Example: SaaS MVP

Consider a SaaS product with:

• Multi-tenant architecture
• Registration
• Authentication
• Subscription billing
• Customer onboarding
• Core workflows
• Admin dashboard
• Notifications
• Reporting
• Production deployment

The timeline may need to accommodate:

Discovery

↓

Product and UX definition

↓

Architecture

↓

Tenant model and authentication

↓

Core workflows

↓

Billing

↓

Administration

↓

QA

↓

Security and stabilization

↓

Launch

An MVP of this complexity might reasonably fall into the 3–6 month planning range, depending on the team and scope.

A more complete product with advanced reporting, mobile applications, complex integrations and enterprise security requirements can extend significantly beyond that.

---

Example: Enterprise Platform

An enterprise platform often includes additional complexity:

• Corporate SSO
• Multiple environments
• Role hierarchies
• Legacy integrations
• Data migration
• Security controls
• Audit requirements
• Infrastructure governance
• Disaster recovery
• Formal UAT

The technical build is only one part of the schedule.

Enterprise projects may also involve:

• Security reviews
• Procurement
• Architecture approval
• Infrastructure approval
• Business stakeholder reviews
• Integration testing
• Change-management processes

That is why a complex enterprise platform can require 9–18+ months even when the visible application interface does not appear unusually large.

---

Example: AI Application

AI applications have an additional layer of uncertainty.

An AI product may require:

• Model-provider integration
• Prompt design
• Retrieval
• Knowledge ingestion
• Embeddings
• Vector storage
• Tool integrations
• Evaluation
• Guardrails
• Monitoring
• Usage and cost controls

For an AI document-processing platform, the workflow might be:

Upload document

↓

Extract content

↓

Classify

↓

Retrieve relevant context

↓

Run model

↓

Validate output

↓

Store result

↓

Human review

↓

Feedback/evaluation

The visible interface may be small.

The underlying system may not be.

An AI MVP can sometimes fit into a 3–9 month planning range, while enterprise AI systems involving proprietary data, security controls, evaluation and multiple integrations can extend substantially beyond that.

---

What Usually Causes Software Projects to Miss Their Original Timeline?

The most common causes can be grouped into eight categories.

1. Scope Expansion

New requirements appear after development starts.

2. Requirement Ambiguity

Important business rules were never defined.

3. Dependency Delays

APIs, data, credentials or approvals arrive late.

4. Technical Surprises

Legacy systems or architectural constraints are discovered.

5. Data Problems

Migration requires more cleaning or transformation than expected.

6. Late Testing

Important defects are discovered near launch.

7. Decision Delays

Stakeholders take too long to approve designs or requirements.

8. Production Readiness Gaps

Monitoring, security, infrastructure or deployment work was underestimated.

This classification is useful because it distinguishes engineering problems from project-governance problems.

A project can be technically well executed and still miss its target because business decisions were delayed.

---

How to Reduce Software Development Time Without Reducing Quality

The best way to shorten a project is often to remove uncertainty and rework rather than simply adding developers.

Define the MVP

Separate essential workflows from future roadmap items.

Freeze the initial scope

Use change control instead of continually adding requirements.

Resolve critical business rules early

Do not leave important workflow decisions for development.

Provide dependencies early

Give the team access to:

• APIs
• Existing systems
• Data
• Credentials
• Brand assets
• Stakeholders

Design important workflows before coding

This reduces downstream rework.

Start QA early

Do not leave all validation until the final weeks.

Automate repetitive delivery work

Use:

• Automated testing
• CI/CD
• Infrastructure automation
• Monitoring

Keep decision-making fast

A designated product owner can remove unnecessary waiting.

---

Why Very Short Software Timelines Can Be Misleading

A vendor might promise:

"Your entire SaaS platform will be ready in eight weeks."

That statement is meaningless without knowing what is actually included.

Ask:

• Is discovery included?
• Is UX/UI included?
• Is architecture included?
• Are all user roles included?
• Are integrations included?
• Is migration included?
• Is QA included?
• Is UAT included?
• Is security testing included?
• Is deployment included?
• Is monitoring included?
• Is handover included?
• What assumptions support the date?

A short estimate may be perfectly reasonable for a narrow MVP.

It may also simply exclude work that another provider has included.

---

How to Compare Two Software Development Timelines

Suppose:

Proposal A

20 weeks

Includes:

• Discovery
• Design
• Development
• QA
• Deployment
• Handover

Proposal B

12 weeks

Includes:

• Development
• Basic testing

Now the comparison is no longer:

20 weeks vs 12 weeks.

It is:

Two different scopes and delivery models.

This is why timeline comparisons should always be normalized against:

• Scope
• Deliverables
• Team
• Testing
• Dependencies
• Assumptions
• Deployment
• Handover

The same principle applies when comparing development proposals by price — a shorter, cheaper timeline that excludes QA and handover is not actually the better deal.

---

What Should a Good Software Timeline Include?

A professional schedule should identify:

Scope

What will actually be delivered?

Phases

Discovery, design, engineering, QA and launch.

Milestones

What should be completed at each major point?

Dependencies

What must happen before each milestone?

Client responsibilities

What must the client provide or approve?

Risks

What could affect the schedule?

Assumptions

What conditions must remain true?

Critical path

Which tasks directly affect launch?

Contingency

What uncertainty has been accounted for?

Acceptance

What must happen before the project is considered complete?

A date without these elements is closer to a promise than an estimate.

---

How Should a Client Evaluate a Vendor's Timeline?

Ask the development company:

1. What is included in the timeline?

Get the full scope.

2. Does the timeline include discovery and design?

Some proposals start the clock at coding.

3. Does it include QA and UAT?

It should be clear where testing ends and client acceptance begins.

4. Does it include deployment and handover?

Production readiness is part of delivery. A handover document that never gets written is usually a sign the "delivery" quoted in the timeline stopped short of actual production readiness.

5. What assumptions are being made?

Ask specifically about:

• Client availability
• APIs
• Data
• Content
• Infrastructure
• Approvals

6. What happens if scope changes?

Understand the change-control process.

7. What are the biggest schedule risks?

A credible vendor should be able to name them.

8. What does the team look like?

Ask who is actually delivering the work.

9. What is the expected range?

Avoid treating an early estimate as an exact commitment.

10. What is not included?

This question can reveal more than asking what is included. It pairs directly with the questions to ask before hiring a software development company — timeline and vendor selection are really the same conversation.

---

Timeline, Cost and Scope Are Connected

Software projects have three closely related variables:

Scope

Time

Cost

Changing one can affect the others.

For example:

Add more functionality without changing the deadline.

This may require:

• More team capacity
• Reduced scope elsewhere
• Higher cost
• Increased project risk

Similarly:

Reduce the budget without reducing scope.

may require:

• More time
• Smaller team
• Reduced support
• Lower delivery capacity

A responsible project plan makes these trade-offs explicit.

PMI's project-estimation guidance treats scope, resources, effort and schedule as interconnected elements of planning rather than independent variables.

---

The Myth of "100% Accurate" Software Estimates

No serious software estimate should pretend that uncertainty does not exist.

Unknown requirements, technical discoveries, third-party dependencies and changing business needs can affect schedule.

The goal is therefore not:

Predict the exact launch date before the project starts.

The goal is:

Create the most defensible forecast possible, expose the assumptions, identify the risks and refine the estimate as uncertainty decreases.

This is a much more useful definition of estimation.

---

Software Timeline Readiness Checklist

Before approving a development timeline, verify:

Scope

• MVP is clearly defined.
• In-scope functionality is documented.
• Out-of-scope functionality is documented.
• Major workflows are understood.

Technical

• Architecture assumptions are documented.
• Integrations are identified.
• Data migration is addressed.
• Infrastructure requirements are understood.
• Security requirements are included.

Delivery

• Discovery is included.
• UX/UI is included where required.
• Development is included.
• QA is included.
• UAT is included.
• Deployment is included.
• Handover is included.

Dependencies

• Client responsibilities are identified.
• Third-party dependencies are identified.
• Approval timelines are considered.
• Required accounts and credentials are available.

Risk

• Assumptions are documented.
• Major risks are identified.
• Critical path is understood.
• Contingency is addressed.
• Change-control process exists.

---

Ortem Software Timeline Framework

At Ortem Technologies, our approach is to avoid treating software timelines as arbitrary calendar promises.

We assess six areas:

1. Scope Readiness

Can the requested product actually be estimated?

2. Complexity

How difficult are the workflows, architecture and integrations?

3. Delivery Capacity

What team is required to complete the work?

4. Dependency Readiness

Are APIs, data, credentials, infrastructure and stakeholders available?

5. Validation Effort

How much QA, UAT, security and performance testing is required?

6. Production Readiness

Are deployment, monitoring, documentation and handover included?

The resulting timeline should be expressed as a range with explicit assumptions rather than presented as an unsupported exact date.

---

A Simple Timeline Estimation Worksheet

Before asking a software company for a timeline, document:

Planning Factor	Your Project
Number of major modules
Number of user roles
Number of complex workflows
External integrations
Existing data migration
Web application
Mobile application
AI functionality
Authentication / SSO
Reporting / analytics
Security requirements
Performance requirements
Multiple environments
Third-party approvals
Required launch date
Client approval dependency

The more clearly these factors are defined, the more useful a vendor's estimate becomes.

---

Final Takeaway

There is no universal timeline for custom software development.

A small application may take weeks or a few months.

A medium business platform may take several months.

A complex SaaS, enterprise or AI system may require considerably longer.

The timeline depends on:

Scope

Workflow complexity

Architecture

Integrations

Data

Security

Team capacity

Testing

Client availability

Third-party dependencies

Production readiness

The most important distinction is this:

A software timeline is not simply a prediction of how long developers will write code. It is a forecast of how long the complete system will take to become ready for real-world use.

Research from DORA reinforces another important principle: software delivery should be evaluated through both speed and stability, rather than speed alone. Its current framework measures throughput and instability separately, including change lead time, deployment frequency, failed-deployment recovery time, change-failure rate and deployment rework rate.

That means a shorter promised timeline is not automatically a better timeline.

A project that launches quickly but requires extensive rework, emergency fixes or stabilization may have delivered faster on the calendar while performing worse operationally.

The better objective is:

Deliver the right scope, with realistic assumptions, enough validation and a clear path to production.

Planning a Custom Software Project?

Before you accept a development timeline, make sure you understand what is actually behind the number.

Ortem Technologies can help you assess your scope, workflows, technical complexity, integrations, data migration, security requirements, delivery dependencies and production-readiness needs before you commit to a development schedule.

Whether you are starting a new product, replacing an existing system or evaluating competing development proposals, we can help turn an uncertain software idea into a clear development roadmap with realistic milestones and delivery assumptions.

Talk to Ortem Technologies about your project before you commit to a timeline.

Discuss Your Software Project →

Planning note: The project ranges and Ortem Timeline Complexity Framework in this article are planning guidance developed by Ortem Technologies. They are not guarantees or industry-wide delivery standards. Actual schedules should be estimated against the project's documented scope, team, dependencies, assumptions and acceptance requirements.