Key takeaways
- Custom software development follows five phases: discovery, design, build, ship, and maintain. Each phase produces a specific written output that the next phase depends on.
- Discovery is the phase most often compressed or skipped in custom builds that exceed their budgets. A properly scoped discovery costs $5,000 to $15,000 and prevents mid-build scope decisions that cost significantly more to resolve.
- The build phase involves iterative delivery and client review, not a single handoff at the end. Timely feedback at each checkpoint is one of the few variables the client controls directly.
- Shipping involves more than deploying code. Data migration, staff training, production environment configuration, and a monitored first period in production are all part of a well-run launch.
- Maintenance is a real line item, not an afterthought. A small-business custom application requires $1,000 to $4,000 per month in ongoing engineering time to stay secure, updated, and operational.
The conversation that makes custom software projects go wrong usually starts with a price quote. A founder asks for a number, gets one, approves it, and moves on. The number was real, but it was based on requirements that had not yet been fully defined. Six months later, the project has cost twice as much and taken three times as long.
The process explanation does not excuse that outcome, but it does predict it. Each phase of a well-run custom build produces a specific set of decisions. When a phase gets skipped or compressed, those decisions get made later at higher cost, or they do not get made at all and become operational problems after launch.
This piece describes each phase in sequence: what a well-run version of it produces, what it costs, and what the consequences are of getting it wrong.
Why process clarity matters more than the quote
When a client asks for a fixed-price quote before discovery is complete, the number they receive is an estimate built on assumptions, not a commitment built on knowledge. Both parties often know this, and both often proceed anyway.
The pattern is familiar enough in the industry that it has an informal name: the low bid that wins the contract and the change orders that recover the margin. It is not inevitable. A client who insists on discovery before approving a final number, and who builds change order terms into the contract from the start, will get a meaningfully more reliable quote.
The practical reason this matters: the cost of a decision in custom software is inversely proportional to how early it is made. A requirement settled in discovery costs little. The same requirement settled during build, after code has been written around a different assumption, costs the development team time to stop, reassess, revise the design, and re-implement. That overhead typically doubles the cost of the decision.
Settled after launch, the cost includes operational disruption on top of the engineering overhead. Understanding which decisions belong in which phase is the frame that makes a cost conversation real.
Phase 1: Discovery
Discovery is the phase where the actual problem gets defined. No code is written in discovery. No final designs are produced. What discovery produces is a shared, written understanding of what the software will do, what it will not do in the first version, and what the constraints on the build are.
A well-run discovery for a small-business application typically takes two to four weeks. The cost ranges from $5,000 to $15,000, depending on the number of stakeholders involved, the complexity of existing systems the new software must interact with, and the amount of data that needs to be inventoried before scope can be set.
Discovery includes structured conversations with each person who will use or operate the system. It includes a review of any integrations: accounting tools, CRM, document storage, payment processors. It includes a data audit that maps what data currently exists, where it lives, how clean it is, and what the new system will need to import or read from it.
The output is a scope document. Not a technical specification (that comes in design), but a clear description of the problem, the core use cases that must work at launch, and the constraints that apply. Both the client and the development team should be able to read the scope document independently and describe the software consistently.
The test for whether discovery was done well is simple. Ask both parties to describe what happens when a specific unexpected input arrives: a user with no assigned permissions, a record with a missing required field, an integration that returns an error. If the answers differ materially, the discovery work is not yet complete.
When discovery is compressed because a client wants to get to the build, the decisions that should have been made in discovery get pushed into design and build. Each discovery-level decision made during build costs two to four times more than it would have cost during discovery. That multiplier is why the $10,000 discovery phase is one of the most cost-effective components of a custom project.
Phase 2: Design
Design translates the decisions made in discovery into specifications a development team can build from. It runs in two parallel tracks: product design and technical design.
Product design produces wireframes and, for user-facing software, high-fidelity screens. The goal of this work is not visual polish. The goal is to surface every decision about how users will interact with the system before a developer writes the code for it. An interaction that requires a design decision mid-build costs two to four times more to handle than the same decision made during the design phase.
A well-run product design process walks through every user flow from start to finish, including error states, empty states, and permission edge cases. When a designer draws the actual screen sequence a user navigates to complete a task, missing steps and contradictory requirements become visible. Those discoveries are significantly cheaper to address in design than in build.
Technical design produces an architecture document: which systems the software will connect to, how data will be structured, which parts of the system face the highest load, where authentication happens, how the deployment environment will be organized, and what the data model looks like for each entity. For a small-business application with modest traffic, this document is typically ten to twenty pages.
Design for a small-to-mid-size custom application takes three to six weeks and costs $8,000 to $25,000. Applications with many distinct user roles, complex integrations, or data-intensive reporting land at the higher end of that range.
At the end of design, both the client and the development team should be able to walk through every user flow without encountering open questions. A design phase that ends with significant open questions is a design phase that did not finish.
Phase 3: Build
Build is the phase where the software gets written. For most small-business custom applications, build runs eight to sixteen weeks. For a mid-scale platform with multiple user types and significant integrations, it runs twelve to twenty weeks.
What happens during build is not a single sustained effort followed by a delivery at the end. A well-run build phase delivers working software incrementally, with client reviews at each stage. A custom CRM build, for example, might deliver working authentication and user management in weeks one and two, a functioning data model and record creation in weeks three through six, reporting and export in weeks seven through ten, and integrations with external systems in weeks eleven through fourteen.
Each delivery gets reviewed by the client team. Those reviews are the mechanism that catches gaps between what was specified and what was built before those gaps compound. A client team that delays reviews, or reviews work superficially, loses the benefit of the incremental delivery model.
Build is also the phase where integrations occasionally reveal complexity that was not visible during design. A payment processor's API may have rate limits that only appear under load. An accounting tool's official API may have data format inconsistencies in older records. A government data feed may have updated its schema since the design was completed. A development team that handles these discoveries transparently, communicates them to the client promptly, and prices any necessary rework through a clear change order process is working correctly.
Build for a focused workflow application at a boutique studio in 2026 costs $20,000 to $60,000. An application with significant integrations, a complex data model, or high performance requirements costs $60,000 to $150,000 or more. Both ranges assume that discovery and design produced stable, complete specifications before build began.
Phase 4: Ship
Shipping is the transition from software that works in a controlled environment to software that runs in the client's actual operations. For most businesses, this phase takes one to three weeks and involves four activities that are frequently underestimated in the initial project scope.
Data migration moves existing records from prior systems into the new one. If the business has been running on spreadsheets, a legacy database, or a departing SaaS tool, that data needs to be mapped to the new schema, cleaned for inconsistencies, and imported. Historical data is almost always messier than the scope assumed. Fields that look clean in a spreadsheet header contain formatting variations in the actual rows. IDs that should be unique are not. Required fields are empty for records that predate the current policy. Data migration that looks like a two-day task in the scope document commonly takes a week or more on real production data. The additional cost, when it arises, typically falls between $2,000 and $10,000.
Deployment configuration establishes the production environment: cloud hosting, domain and SSL setup, access controls, backup schedules, and monitoring configuration. For cloud-hosted applications, this is typically a one-to-two-day engineering task handled by the development team.
Staff training ensures that the people who will use the system know how to use it before the old system is turned off. For an internal tool used by a small team, a half-day walkthrough plus written documentation is usually sufficient. For a customer-facing application, a staged rollout to a subset of users during the first week is a more controlled approach.
Production monitoring during the first two to four weeks in production catches issues that only appear under real load with real data. Minor bugs during this window are expected and normal. A development partner who considers the engagement complete at the moment of deployment, before this monitoring period ends, is worth noting carefully in the reference check.
Phase 5: Maintain
Maintenance begins the day the software ships and does not stop while the software is in use. It is the phase most often underestimated in initial budget planning, and the omission frequently damages otherwise successful builds.
Custom software runs on infrastructure that changes beneath it. Cloud providers update their services. Operating systems release security patches. The frameworks and libraries the software uses internally get updated, and some of those updates require corresponding changes to the application. A custom system that receives no maintenance will, over a two-to-three-year window, accumulate compatibility problems and security exposure that require remediation at significant cost.
The minimum reasonable maintenance budget for a small-business custom application is $1,000 per month. This covers a few hours of monthly engineering time for dependency updates, minor bug fixes, and production monitoring. It does not include new features.
A maintenance arrangement that covers minor feature additions (new report formats, small UI adjustments, additional export fields) typically costs $2,000 to $4,000 per month at boutique-studio rates.
The development partner who built the system is almost always the most efficient choice for ongoing maintenance. They wrote the code, they understand the architecture decisions, and they do not have to spend time orienting before they can act. A handoff to a new team after launch is possible, but it carries an onboarding cost that is rarely reflected in the new team's initial quotes.
When the business grows significantly or the original requirements evolve enough to require a major expansion, maintenance shifts back into a new build engagement. That transition is expected behavior, not a failure of the original architecture. The original system should have been built with a data model that makes expansion feasible without a full rewrite. Whether the development partner considered this at the architecture stage is one of the most useful things to ask before hiring. The hiring a creative engineering studio piece on this site covers the full evaluation process, including which questions reveal how a studio approaches long-term maintainability.
Typical timelines by project shape
Timeline estimates in custom software are significantly more reliable after a completed discovery phase than before one. The ranges below assume discovery produced stable specifications and that client reviews happen on schedule during build.
A focused workflow application (one to two user types, four to eight core screens, two to four integrations): discovery two to three weeks, design three to four weeks, build eight to twelve weeks, ship one to two weeks. Total calendar time: fourteen to twenty-one weeks from contract signature to production.
A mid-scale internal platform (multiple user types with distinct permissions, ten to twenty screens, five to ten integrations, reporting): discovery three to five weeks, design four to six weeks, build twelve to eighteen weeks, ship one to three weeks. Total calendar time: twenty to thirty-two weeks.
An application with an AI integration layer (any of the above, plus an LLM, a retrieval layer, or an agent component): add three to six weeks to the build phase, plus additional discovery and design time for the AI component specifically. Total calendar time: twenty-five to forty weeks at this scope.
Timeline overruns in custom builds trace to a small set of causes. Scope changes after design is complete are the most frequent. Integrations that proved more complex than expected are the second most frequent. Client review delays that break the incremental feedback loop are the third. The first is within the client's control. All three are reduced, though not eliminated, by a well-run discovery phase that surfaces decisions early.
A client who commits to timely reviews, holds scope through the build phase, and treats design decisions as final once made will almost always finish closer to the early end of the timeline range. That is not a consequence of optimistic scheduling. It is a consequence of removing the most common sources of delay.
For a complete picture of what custom development costs at each phase and project scale, the how much does custom software cost in 2026 piece on this site covers pricing in more detail, including ranges for boutique studios versus larger agencies.
