Custom software development: cost, process and when you need it.

Most requests for custom software start with a process that hurts. Orders arrive by email, someone retypes them into a spreadsheet, and a second person copies them into the accounting system. The obvious fix sounds like a bespoke application that does exactly what the business needs. Sometimes that is right. More often, a faster and cheaper route exists that nobody tested first.

This guide helps you make that call with clear eyes. It covers when custom software is worth it, how the custom software development process works, what an MVP, a PRD and a BRD are, what custom software development costs and what you must own when the work is done. One thing up front: Viralistic does not build custom software. We work on strategy, design, websites and automation, and we help companies define the problem before they hire developers. We have nothing to gain from selling you a build.

Do you actually need custom software?

Custom software is rarely the first answer. Before you commission a build, test three other routes: off-the-shelf software, no-code tools and automating the systems you already have. Custom development earns its price only when all three fall short.

Off-the-shelf software is often called COTS, short for commercial off-the-shelf: ready-made products that many companies buy or subscribe to, such as accounting, CRM or membership software.

The third route is the one most often skipped. A workflow tool such as n8n connects systems that already work, so data moves between them without retyping. You can use n8n in the cloud or run your own instance, for example with managed n8n hosting in Europe. Our guide to workflow automation explains how to scope that work, and our automation page shows how we approach it.

Four questions tell you whether custom software deserves a closer look:

1. Is this process what sets you apart from competitors, or is it administration every business has?
2. Have you seriously tested at least two products, with a demo on your own data?
3. Will a defined group of people use the software every day?
4. Can you fund maintenance for years, not only the build?

Three or four yes answers make custom software worth investigating. If most answers are uncertain, start with the routes above, or set your digital priorities first with a strategy engagement.

The custom software development process, step by step

A sound custom software development process runs through eight steps: discovery, requirements, design and prototype, MVP, build, testing, launch and maintenance. The first three cost the least and prevent the most expensive mistakes. Agencies use different names, but the order rarely changes.

1. Discovery: define the problem

Describe the problem before anyone proposes a solution. Who struggles with it, how often, and what does it cost today in hours or errors? Talk to the people who do the work, not only to management. The output is a short problem statement with measurable goals.

2. Requirements: write a PRD

Capture what the software must do, for whom and why. That document is the PRD, covered in detail below.

3. UX/UI design and a clickable prototype

Design the screens before anyone writes code. Start with wireframes, without colour or typography, so the route through the software gets all the attention. Then move to a full design, for example in Figma, where you can link screens into a clickable prototype. Users click, react and point out confusion while changes still cost hours instead of weeks. Our guide to UX/UI design goes deeper into this step.

4. MVP: the smallest version that proves something

Choose the smallest set of features that lets real users complete a real task. Everything else waits.

5. Build in short iterations

Good developers build in short cycles of one to four weeks and show a demo at the end of each one. You see working software regularly and can correct course before a wrong assumption becomes expensive.

6. Test with real users and real data

Testing goes beyond checking that buttons work. It covers functional tests, security, performance under load and an acceptance test in which your own team uses the software with real data.

7. Launch and handover

A launch needs a plan for migrating existing data, training for users and a handover that includes documentation, access and the source code.

8. Maintenance and further development

Software is not finished at launch. Dependencies receive security patches, browsers and operating systems change, and users ask for improvements. Budget for maintenance from the first quote onwards.

What is an MVP?

An MVP, or minimum viable product, is the smallest working version of a product that tells you whether it solves a real problem. Eric Ries, who popularised the term in The Lean Startup, defined it in 2009 as the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

The word minimum misleads people. A good MVP does little, but it does that little well: one clear job for one clear group of users. For a wholesaler, that could be an ordering portal where existing customers place repeat orders, without quotes, discount rules or returns. If customers use it, you build further.

An MVP is often confused with two neighbouring terms:

What is a PRD, and how does it differ from a BRD?

A PRD (product requirements document) describes what a product must do, for whom and why. A BRD (business requirements document) describes what the organisation wants to achieve and why, before anyone chooses a solution. The BRD answers the business question, the PRD translates it into a product, and the developers then work out the technical design.

In a smaller company, BRD and PRD are often one document. That works, as long as the business goals sit at the top. A good PRD does not need to be long either. Atlassian, the company behind Jira and Confluence, recommends in its guide to product requirements giving just enough context and leaving implementation details to the development team. A short outline:

1. Project specifics: participants, status and target release.
2. Goals: business objectives and how you will measure success.
3. Background and strategic fit: why this matters now.
4. Assumptions: what you assume about users, technology and the market.
5. User stories: what each user must be able to do, with success criteria.
6. User interaction and design: links to wireframes and the Figma design.
7. Questions: decisions and research still open.
8. Not doing: what is deliberately out of scope for now.

We add two sections ourselves, because they are the ones most often missing from quotes: integrations with existing systems, and non-functional requirements such as security, speed, availability and the handling of personal data under the GDPR.

A PRD has one more benefit. It makes quotes comparable. Give three developers the same document and you compare prices for the same work, instead of three interpretations of a conversation.

How much does custom software cost?

Custom software development usually costs between a few thousand and several hundred thousand dollars. Scope, integrations, user roles, security requirements and the team’s location decide where you land. There is no price per unit, because every project answers a different question.

Clutch, a B2B review platform, publishes pricing data based on verified client reviews, last updated in September 2026:

The gap between the typical budget and the average tells you something: a minority of large projects pulls the average up. Treat these figures as orientation, not as a quote.

These factors decide where your project falls:

• Scope: the number of screens, steps and exceptions.
• Integrations: every connection to accounting, a webshop, a CRM or an ERP adds build and test time.
• Users and permissions: one user type is simpler than customers, staff and admins with separate rights.
• Data and security: personal data, payments or health data raise the bar.
• Migration: moving existing data out of old systems or spreadsheets.
• Design: strong design costs time up front and saves development hours later.
• Running costs: hosting, licences, monitoring, security updates and further development.

Starting big is the most expensive risk. McKinsey and the University of Oxford studied more than 5,400 IT projects in 2012. Large IT projects ran 45 percent over budget and 7 percent over time on average, while delivering 56 percent less value than predicted. Each additional year of project duration increased cost overruns by 15 percent. That research covered projects above $15 million, but the lesson scales down: the bigger and longer the first version, the more likely it costs more and delivers less. A small MVP limits that risk, and you learn sooner what users actually need.

How to choose a software development agency

Choose a partner who asks questions before quoting, shows working software before you pay for the full build and is clear about ownership and maintenance. A low hourly rate means little when the number of hours is unclear.

Ask these questions in the first conversation:

• How do you map the problem before you give a price?
• Can we run a paid discovery or a prototype, separate from the build?
• Will I get a price per component, so I can decide what goes into the first version?
• How often will I see working software, and who is on the team?
• How do you test, and is testing part of the quote?
• Who owns the source code, and how does handover work if we part ways?
• What does maintenance cost per month or per year, and what does it include?
• Will you sign a data processing agreement if the software handles personal data?

If you are comparing local, nearshore and offshore teams, look beyond the rate. Time zones, working language, the governing law in the contract and who answers the phone when something breaks all affect the real cost. For companies based in the Netherlands, a contract under Dutch law with a supplier you can reach during your working day removes a lot of friction.

Ask for references from clients with a similar project, and call them. Ask how the project went, then ask what happened when something went wrong. The second answer tells you more.

What you should own: source code, IP and accounts

Keep three things in your own hands: the source code and intellectual property, every account and credential, and the documentation. Without them you depend on one supplier, even after the relationship ends.

Ownership does not arrange itself. In the United States, the Copyright Office explains in Circular 30 that commissioned work by an independent contractor only counts as work made for hire when it falls into one of nine statutory categories and both parties sign a written agreement. A standalone application rarely fits those categories, so the safer route is a signed copyright assignment. Dutch law is similar in effect: under article 2 of the Auteurswet, the Dutch Copyright Act, a transfer of copyright requires a written agreement and a deed. In both cases, a line in a quote is not enough. Have the assignment or licence drafted explicitly and reviewed by a lawyer.

A practical checklist:

• Repository: the code lives in a GitHub or GitLab organisation owned by your company. The developer gets access, not the other way round.
• Cloud and hosting: the account runs in your company’s name, on your payment details.
• Domain and email: registered to your company, with you as the administrator.
• App stores and API keys: developer accounts and third-party keys belong to you.
• Documentation: how the software is structured, how to deploy it and how a new team can take over.
• Data: you can export your data at any time in a usable format.
• Escrow: if the supplier keeps the code, agree a source code escrow arrangement so you can access it if they go out of business.

The same logic applies to your website. You want to own the domain, hosting and design files there too, as we explain in our guide to having a website built.

How we help

Viralistic does not build custom software, and we will not pretend otherwise. We help at the moments when the most expensive decisions get made: before the build and alongside it.

With our strategy approach, we look at your business as a whole. We assess your tools and workflows and put initiatives in the right order. Sometimes the conclusion is that you do not need custom software at all. Our guide to digital strategy explains what that work involves.

If custom software is the right call, we help you put the problem and the requirements on paper before you hire developers, so you can compare quotes for the same work. We also translate your brand into interfaces in Figma, from wireframe to high-fidelity design, as described on our design and webdesign pages.

If your existing tools turn out to be enough, we connect them with n8n and Claude. We agree on the value first and prove it with a few workflows in production, through our automation approach.

Not sure whether custom software development is the right step? Plan a strategic call. We will tell you honestly which route pays off, even if it is one we do not deliver ourselves.

Frequently asked questions

How much does custom software cost?

It depends on scope, integrations, user roles and security requirements. According to Clutch, a typical reviewed software project costs $10,000 to $49,000, while the average project costs about $132,480 and takes around 13 months. Hourly rates differ sharply by country. Ask every supplier for a price per component and include maintenance in your budget from the start.

What does MVP stand for in software?

MVP stands for minimum viable product. It is the smallest working version of a product that real users can use to complete a real task. The goal is learning: you find out whether the product solves the problem before you invest in the full feature set. Eric Ries popularised the term in The Lean Startup.

What is COTS software?

COTS stands for commercial off-the-shelf software: ready-made products sold to many customers, such as accounting, CRM or membership software. You can usually start quickly and pay a licence or subscription, while the vendor handles hosting and updates. The trade-off is that you adapt part of your process to the product, rather than the other way round.

What is a PRD in software development?

A PRD, or product requirements document, describes what a product must do, for whom and why. It typically covers goals, background, assumptions, user stories, links to the design, open questions and what is out of scope. A PRD gives designers and developers a shared reference and makes quotes from different suppliers comparable.

Can AI build custom software for my business?

AI assistants such as ChatGPT and Claude can write working code and produce a prototype quickly. They do not make the decisions for you: what to build, how to secure your data, who maintains it and who is responsible when it fails. If you want software that uses AI, for example to process emails or summarise documents, a workflow with n8n and Claude often does the job.

Who owns the code when I hire a developer?

By default, the developer usually holds the copyright, not the client. In the United States, commissioned software rarely qualifies as work made for hire, so you need a signed copyright assignment. In the Netherlands, a transfer requires a written agreement and a deed. Also make sure the repository, cloud account and domain are registered to your company.