The custom software development process has five phases: discovery and scoping, architecture and design, development, testing and acceptance, and deployment and handoff. Most projects run 8 to 24 weeks from a signed scope document to a live system, depending on complexity. You receive a fixed price before any code is written.
Why I'm writing this post
I've been building custom software for 40 years. In that time, the single most common reason a project goes sideways is not technical — it's that the client didn't know what to expect, and the developer didn't explain it clearly. Surprises breed distrust. Distrust kills projects.
Most vendors describe their process in marketing language: "we partner with you," "agile methodology," "continuous delivery." Those phrases are not wrong, exactly. But they don't tell you what a Tuesday afternoon looks like six weeks into development, or what happens when something doesn't match what was agreed.
This post does. If you're considering custom operational software and you want to know what you're getting into, read through to the end.
Phase 1: Discovery and scoping (1–2 weeks)
Everything starts with a free 30-minute Clarity Call. No pitch, no proposal theater. I want to understand your situation well enough to tell you two things honestly: whether custom software is actually the right answer for you right now, and if it is, roughly what it would cost and how long it would take.
What I'm learning on that first call
I'm asking about your current process — what you're doing today, even if it's a spreadsheet, a whiteboard, or a system held together with duct tape. Specifically:
- What work does this software need to support? Walk me through a typical day.
- Where does the process break down? What takes too long, produces errors, or falls through the cracks?
- What does success look like 90 days after the system goes live?
- What other systems does this need to connect with — accounting, CRM, inventory, anything?
- Is there existing data that needs to migrate into the new system?
- Who will use this, and how technically comfortable are they?
I'm also asking what's a must-have versus what would be nice to have. This distinction matters more than most clients expect. A must-have defines the scope. A nice-to-have can be Phase 2 — after the core system proves itself.
What you get at the end of Phase 1
A written scope document. Not a proposal deck — a document that describes exactly what we're building: screens, workflows, data fields, integrations, what the system does and what it explicitly does not do. Attached to that is a fixed price and a completion timeline.
You decide yes or no with full information. No hourly billing, no "it depends." Our pricing model means the number on the scope is the number you pay.
If you're still weighing whether custom software makes sense at all, this post on custom vs. off-the-shelf software lays out the honest tradeoffs.
Phase 2: Architecture and design (1–3 weeks)
Once we've agreed on scope and you've signed off, we move into architecture before writing a line of production code. This phase is shorter but it matters more than most clients realize.
What happens here
- Data model design. What information does the system need to store? How does it relate? Getting this right early prevents painful restructuring later. A poorly designed database is the most common source of technical debt in custom software.
- Workflow mapping. We trace every user journey through the system — create a record, approve a request, generate a report — and confirm it matches the scope before coding begins.
- Wireframes for complex screens. Not every screen needs a wireframe. But any screen where the layout directly affects how work gets done gets sketched out and approved before we build it.
You review and approve before code is written
I send you the data model and wireframes. You review them with the people who will actually use the system. If something is wrong or missing, we fix it now — when a correction costs an hour, not a week. This is not a formality. It is the most important checkpoint in the entire process.
Phase 3: Development (4–12 weeks depending on scope)
This is the longest phase and the one most clients are least sure how to think about. Here's how it actually works.
You see working software every two weeks
We don't disappear for three months and return with a finished product. Every two weeks, you receive access to working software — not a mockup, not a demo with fake data, but the actual system with actual functionality you can test. Early builds may cover only one or two workflows. By week eight, most of the core system is visible and testable.
This matters for two reasons. First, it gives you the chance to catch misunderstandings while they're still cheap to fix. Second, it forces us to deliver something functional at every checkpoint rather than letting unfinished work pile up until the end.
Weekly check-ins, not monthly status reports
We have a 30-minute standing call each week. It covers: what was completed, what's coming next, anything that needs a decision from you. You're never waiting for a monthly email to find out where things stand.
I ask you to include the people who will use the system — not just the decision-maker — in the biweekly reviews. The person doing data entry or generating reports will catch things that a manager reviewing screenshots will miss.
How we handle scope changes
Honest answer: scope changes happen on almost every project. As you see the system take shape, you'll think of things that didn't come up in Phase 1. That's normal. Here's how we handle it:
- Small adjustments — adding a field, reordering a list, changing a label — are absorbed if they take under an hour and don't affect other parts of the system. No paperwork, no charge.
- Larger additions — a new reporting module, a new integration, a new workflow — get a written change order. I estimate the cost and timeline impact and you decide yes or no before we proceed. No surprises on the invoice.
If you're curious about what drives cost differences on projects like this, this post on custom software costs breaks it down in detail.
Phase 4: Testing and acceptance (1–3 weeks)
When development is complete, the project moves into formal acceptance testing. This is not a rubber-stamp step. It's the checkpoint that protects you.
You test against the scope document
The scope document is the contract. For every requirement listed in that document, we verify together that the delivered system meets it. I provide a testing checklist derived from the scope. You and your team work through it, noting anything that doesn't match.
If the delivered software doesn't match the agreed spec, we fix it. No charge, no negotiation. The scope is the bar we committed to clear.
Training
I don't hand you a 200-page PDF and call it documentation. Training happens in actual sessions with the people who will use the system. We work through real workflows with real data. Most systems require two to three sessions — one for administrators, one for end users, sometimes one focused on reporting.
Short written reference guides get created for the most common tasks, but the goal is that your team feels capable, not that they have a binder to consult when they get stuck.
Phase 5: Deployment and handoff
Deployment is when the system goes live for real use. For most clients, this is the step that feels most uncertain. Let me be specific about what it involves.
What "you own it" actually means
At handoff, you receive:
- The complete source code, in a repository you control
- The database schema and any migration scripts
- Documentation covering the system architecture, how to make common changes, and how to set up a development environment
- Credentials and access to every service the system depends on — you own those accounts, not us
You can take that code to any developer in the world. You are not dependent on MosierData to keep the lights on. No ongoing licensing fees, no lock-in. This is described in more detail on our solutions page.
Hosting
We set up the production environment — server configuration, database, backups, monitoring. But the infrastructure accounts are in your name. You pay the hosting provider directly. We don't mark up hosting or take a margin on it.
For most systems, hosting costs run $50–$300 per month depending on scale. I'll give you a realistic estimate during scoping.
Post-launch support
The first 30 days after deployment are included in the project price. During that window, any bugs or issues that surface in production get fixed at no additional charge. After 30 days, support is available at a fixed monthly retainer or per-incident rate — your choice. The rates are set during the project, not announced afterward.
What can go wrong — and how we handle it
I'd rather be honest about this than pretend every project runs perfectly.
Scope creep
The most common issue. As you see working software, you'll think of things you want. The discipline is distinguishing between a legitimate scope gap (something that was implied but not specified) and a genuinely new feature. Legitimate gaps get fixed. New features get change orders. The conversation is straightforward because we have a written scope to refer to.
Unexpected data complexity
Data migrations surface surprises. I've done this long enough to know that the data in an existing system is almost always messier than it appears during scoping. We build a buffer for this into timelines, and we flag it early if the discovered complexity is large enough to affect the delivery date.
Third-party API issues
If the system needs to connect to an external service — a payment processor, an accounting platform, a government database — that third party's API may behave differently than its documentation suggests, or may have rate limits or reliability issues we couldn't anticipate. When this happens, we document the issue, present options, and you decide how to proceed. We don't absorb the cost of a third party's broken behavior, but we also don't hide it.
For context on what happened when we ran into real-world complexity on a large-scale project, the Heartland for Children case study is worth reading. That project involved two integrated systems, data migration from legacy records, and external reporting requirements — and delivered a 3x efficiency gain.
How long does the whole process take?
Timeline depends almost entirely on scope. Here's a rough guide:
| Project type | Typical timeline | Typical price range |
|---|---|---|
| Single-workflow tool (one department, no integrations) | 8–10 weeks | $8,000–$18,000 |
| Multi-workflow system (2–3 departments, 1–2 integrations) | 12–16 weeks | $18,000–$35,000 |
| Full operational platform (multiple departments, data migration, multiple integrations) | 18–24 weeks | $35,000–$50,000+ |
These are starting points. The scope document will give you a specific number for your project. If your situation falls outside these ranges in either direction, I'll tell you why on the Clarity Call.
When custom software is not the right answer
I'll close the main article with this because I think it matters: custom software is not always the right answer, and I'll tell you so on the Clarity Call if that's the case.
Custom software makes sense when:
- Your workflow is genuinely unusual and off-the-shelf tools require so much workaround that your team spends more time fighting the software than doing the actual work
- You're paying for features you don't use and missing features you need
- You've outgrown a tool and the upgrade path is a subscription tier that doubles your cost
- You have a process that's a real competitive differentiator and you don't want your competitors using the same tool
Custom software is probably not the right answer when:
- You're early-stage and the process itself is still changing — build the process first, then build the software
- A $50/month SaaS tool handles 90% of what you need and the remaining 10% is genuinely nice-to-have
- The problem is that people aren't using the existing tools, not that the tools are wrong
If you're not sure which category you're in, that's exactly what the Clarity Call is for. Thirty minutes, no pitch, and you'll know before you hang up whether I think custom software makes sense for your situation.
If you're still researching and want to understand what the signs are that your business has outgrown its software, that post covers the specific indicators I look for when evaluating whether a project makes sense.