How Custom Software Gets Built: The Process from First Call to Launch

Most businesses that consider custom software have never been through the process before. That's normal. You know your operations, your team, and the problem you're trying to solve. The part that feels opaque is how a conversation about a business problem turns into working software.

This is a plain walkthrough of how we build at 0ARCH, from the first call to launch and beyond. Not theory, not a sales pitch. The actual steps, the actual timelines, and what you should expect at each stage.

Before Anything Gets Built: Discovery and Scoping

Every project starts here, and it's the phase that determines whether the rest goes smoothly or sideways.

Discovery usually takes 1 to 2 weeks. The goal is simple: understand the problem well enough to define exactly what the software needs to do. Not what it could do. What it needs to do.

This looks like:

• Workflow mapping. We walk through your current process step by step. Where does data come from? Who touches it? Where does it go? Where do things break or slow down? This usually surfaces problems the team has been working around for so long they've stopped noticing them.
• User identification. Who will use this tool, and what does each person need to see and do? An operations manager needs a different view than a client logging in to check project status. These roles shape the entire build.
• Scope definition. We write down every feature the software will include at launch, organized by priority. This becomes the project spec. If it's not in the spec, it's not in the build (and it's not in the price).
• Technical decisions. What infrastructure makes sense, what existing systems need to connect, and what the data model looks like. These decisions get made now, not halfway through development.

The output is a fixed-scope proposal: a document that describes exactly what gets built, how long it takes, and what it costs. No hourly billing, no open-ended estimates. You know the full number before a single line of code is written.

Design: Making It Real Before It's Built

Design takes 1 to 2 weeks for most projects. The purpose is to make every screen visible and clickable before development begins, so problems get caught when they're cheap to fix (in a Figma file) instead of expensive to fix (in production code).

What happens during design:

• Information architecture. How screens connect, what the navigation structure looks like, and how data flows through the interface.
• Wireframes and high-fidelity mockups. Every screen the user will interact with, designed to the level of detail that development can start directly from them.
• Clickable prototype. A working simulation of the software you can click through. This is where you catch missing screens, confusing flows, and "I assumed it would work differently" moments. It's dramatically easier to move a button in a design file than to restructure a database.

You review the design and sign off before development begins. This is a checkpoint, not a formality. If something feels wrong at this stage, now is the time to say so.

Build Sprints: Where the Software Gets Made

Development is the longest phase, and it's where most of the timeline lives. For context:

• A marketing website with lead capture: roughly 3 weeks
• A client portal, internal tool, or custom dashboard: 6 to 14 weeks
• A CRM with integrations and role-based access: 10 to 14 weeks
• An ERP or multi-module operations platform: 16 to 20+ weeks

We work in weekly or bi-weekly sprints. Each sprint has a defined set of features to build, and at the end of each sprint, you see working software. Not a progress report, not a slide deck. Functional features you can interact with.

This cadence matters for two reasons. First, you can verify that what's being built matches what you need while there's still time to adjust. Second, it keeps the project on pace. If a sprint falls behind, we know in a week, not three months later.

A typical build sprint cycle looks like this:

1. Sprint planning. We pick the features for this cycle based on priority and dependencies.
2. Development. The features get built, including backend logic, API endpoints, database work, and frontend interface.
3. Internal review. We test before you see it. Broken features don't make it to sprint demos.
4. Demo. You see the working features, give feedback, and flag anything that needs adjustment.

Most projects run 4 to 10 sprints depending on scope.

Testing: Breaking It on Purpose

Testing runs throughout development (every sprint includes internal QA), but there's a dedicated testing phase before launch, typically 1 to 2 weeks.

This phase covers:

• Functional testing. Does every feature do what the spec says it should? Every button, every form, every workflow, every edge case we can anticipate.
• Cross-device testing. Does it work on desktop, tablet, and mobile? Different browsers? The answer needs to be yes across the board.
• Data integrity. If a user enters data here, does it show up correctly there? Are calculations right? Do filters and searches return the right results?
• Load and performance. Will it hold up when your whole team is using it at once? We test under realistic conditions, not just with one user clicking through empty screens.
• User acceptance testing (UAT). You and your team use the software with real (or realistic) data and report anything that doesn't feel right. This is the last gate before launch.

Bugs found during testing are expected and normal. Bugs found after launch are expensive. That's why this phase exists.

Launch: Going Live Without the Drama

Launch is not "flip a switch and hope." It's a supervised process that usually happens over a few days.

• Staging deployment. The software goes to a production-like environment first. This catches infrastructure issues (DNS, SSL, hosting configuration) before real users see the tool.
• Data migration. If you're moving from spreadsheets, a legacy system, or another tool, your data gets imported and verified. We don't do this on launch day. It happens in advance and gets validated.
• Soft launch. A small group (often just the core team) uses the tool in production for a few days. This catches the issues that testing alone never surfaces, the ones that only appear when real people use real data under real conditions.
• Full launch. Once the soft launch is clean, the tool goes live for all users. We monitor closely during the first week.

The goal is a launch where nobody notices it happened. No downtime, no data loss, no fire drills. The software just starts working.

Post-Launch: What Happens After

Software doesn't end at launch. The first month of real usage always reveals adjustments that need to happen: a report that would be more useful with one more column, a workflow that's slightly different than what was scoped, a feature that's used differently than expected.

Post-launch support typically includes:

• Bug fixes. Anything that breaks gets fixed promptly. This is standard, not an add-on.
• Small adjustments. Minor tweaks based on real usage. These are usually quick and often included in the initial engagement.
• Ongoing support agreements. For larger tools, we offer monthly retainers that cover maintenance, small feature additions, and infrastructure monitoring. Budget 15 to 20% of the build cost per year for this.
• Future phases. The initial build is the version that solves your most pressing problem. Phase 2, 3, and beyond add features based on real feedback from actual usage, not guesses from a planning meeting.

What Makes This Different from Hiring an Agency

Two things: scope discipline and pricing model.

Most agencies bill hourly. The longer the project takes, the more they earn. Fixed-scope, fixed-price projects (which is how we work) flip that incentive. We're motivated to ship efficiently because the scope and price are locked before work begins. If a feature takes longer than estimated, that's our problem, not yours.

Scope discipline means we don't bolt on features mid-build because they seem cool. Every feature in the build was agreed on during discovery. If new requirements emerge (they sometimes do), they get scoped and priced as a separate change order, not quietly absorbed into a ballooning timeline.

The Short Version

Custom software follows a predictable process: discovery (1-2 weeks), design (1-2 weeks), build sprints (the bulk, 3-16+ weeks depending on scope), testing (1-2 weeks), launch (a few days), and ongoing support.

The total timeline for most business tools is 6 to 14 weeks. Websites are faster (about 3 weeks). ERPs are longer (16-20+ weeks).

The process isn't mysterious. It's a series of defined phases with clear deliverables, regular checkpoints, and no surprises on the invoice. The businesses that have the best experience are the ones that engage during discovery, review demos during build sprints, and participate in testing. Software built in a vacuum rarely fits. Software built with your input does.

---

Keep reading

• What Custom Software Actually Costs in 2026: A Transparent Breakdown
• Build vs Buy Software: A Decision Framework for 2026
• You've Outgrown Spreadsheets. Here's How to Know What to Build Next.

---

0ARCH builds custom software with a fixed-scope, fixed-price process. See what we've shipped or start a conversation about your project.