The custom software development process: a buyer's step-by-step guide

The custom software development process has nine steps when you look at it from the buyer side: frame the problem, choose a partner, validate a prototype, agree scope and contract, approve the design, settle the technical foundations, follow iterative development, run acceptance testing, then go live and plan maintenance. At each step the vendor produces something, and you, the buyer, have to provide inputs and make a decision. Projects that go wrong rarely fail on code. They fail on a decision nobody made at the right step.

Most guides describe the process as the vendor sees it: requirements, design, build, test, deploy. This one follows the person paying for the software, and lists for every step what you provide, what you sign off and the warning signs to watch.

The nine steps at a glance

Step 1: frame the problem

Before talking to any vendor, write a single page that answers four questions: what hurts today, who suffers from it, what a good outcome looks like, and what is out of scope. "Our team re-types every order from email into the ERP, it takes two people half a day and causes errors" is a far better starting point than a list of features.

You provide: the problem in your own words, the list of user roles, the tools the software must work with, and any hard constraints (deadline, data location, budget ceiling).

You decide: whether this deserves custom software at all. If a well-configured off-the-shelf product covers most of the need, buy it. Our build vs buy guide walks through that choice.

Step 2: choose a development partner

Share the brief with a small shortlist and pay attention to the questions they ask back. A good partner asks about your process, your users and your data before talking about technology.

You provide: the brief, your timeline and how you prefer to pay.

You decide: who you trust with the next step. Our guide on how to choose a software development company lists the questions to ask, and the red flags.

Warning sign: a firm quote before anyone has asked how your team works today.

Step 3: validate a prototype before you commit

This is the step most guides skip, and the one that saves the most money. A clickable prototype turns your brief into screens: the main workflows, the roles, the key data. Your users can react to something concrete instead of a document.

In one review session, you discover that the warehouse needs a different view from the office, that a status is missing, or that a screen nobody asked for is in fact essential. Fixing that on a prototype costs nothing. Fixing it after three months of development does.

You provide: two or three real users for a review session, and honest feedback.

You decide: whether the prototype reflects how your business works, and what the first release must contain.

At LPR Studio, this step is free: within 5 business days, we present a prototype of your software on a video call. It is a demonstration, neither paid for nor delivered, and it becomes the shared reference for the quote. Our guide to the differences between a prototype, an MVP and a POC explains what each one proves.

Step 4: agree scope, price and contract

With a validated prototype, scoping becomes precise: the list of screens, business rules, integrations and data migration for the first release, plus what is explicitly left for later.

You provide: priorities (what is essential for launch, what can wait), your preferred pricing model and a legal review of the contract.

You decide: three things that shape the whole project.

• The pricing model. Fixed price, time and materials, or a subscription where you do not pay for development upfront. Our comparison of fixed price vs time and materials covers the trade-offs.
• The contract terms. Acceptance criteria, change requests, warranty, rights to the code (set case by case in the contract), data reversibility. See our checklist of software development contract clauses.
• The first release. Keep it small. Our guide to what to build first in an MVP helps you cut.

Warning sign: a contract with no written acceptance criteria. Without them, "done" means whatever each side wants it to mean.

Step 5: design

The designer turns the prototype into final screens. The happy path is easy to approve. What matters is everything else: what each role sees, empty states, error messages, what happens when a record is cancelled halfway.

You provide: the edge cases only your team knows, brand assets and real sample content (actual product names, actual customer types).

You decide: the final screens, role by role. Approve them once the core workflows have stopped moving, not before.

Step 6: technical foundations

The development team chooses the architecture, the hosting, the security model and how the software will connect to your existing systems. You do not need to understand every technical choice, but some decisions are yours.

You provide: access to the systems to integrate (API documentation, test accounts, a contact on the vendor side), your rules on data location and security, and who on your side will own admin accounts.

You decide: where the data is hosted, who holds the admin keys and whether the identified risks are acceptable. If you handle personal data of people in Europe, our GDPR checklist for business applications applies whatever your location.

Warning sign: hosting, domains or third-party accounts registered in the vendor's name with no plan to transfer them.

Step 7: iterative development

Development runs in short cycles, each ending with a demo of working software. The Scrum Guide caps each sprint at one month or less; many teams use one or two weeks.

You provide: someone at every demo who can make decisions, and quick answers to questions between demos. A question left unanswered for a week costs a week.

You decide: whether each increment meets its acceptance criteria. "The code is finished" is not the same as "accepted". Any new idea goes through a written change request with its impact on cost and schedule, rather than a quiet extension of scope.

Step 8: acceptance testing

Acceptance testing is when your team, not the developers, checks that the software supports real work. Real users run real scenarios with realistic data: a full order from entry to invoice, a month-end close, a user with restricted rights.

You provide: testers with time blocked in their calendars, test scenarios based on daily work, and a realistic data set.

You decide: whether the software is ready for production. Separate blocking issues from improvements that can follow; otherwise testing never ends.

Warning sign: a test plan written by the vendor alone. Only your team knows which cases matter.

Step 9: go-live, handover and maintenance

Going live combines three things: migrating the final data, training users and switching over. If you are replacing an existing tool, keep it read-only for a few weeks as a safety net. Our legacy data migration guide covers the checks before and after cutover.

You provide: the final data export, time for user training and a date that avoids your busiest period.

You sign off: the handover. At minimum, you should receive access to the code repository according to the contract, admin access to hosting, domains and third-party services, documentation, a description of backups and how to restore them, and a written maintenance arrangement covering bug fixes, security updates and response times.

Software is never finished. Budget for maintenance and new features from the start, and review usage after a few months: the most valuable second release usually comes from what users actually do, not from the original wish list.

How long the process takes

It depends on scope far more than on the process itself. A focused first release and a large platform follow the same nine steps at very different scales. Our guide on how long it takes to build an app gives the factors that drive the schedule, and our article on custom business application cost covers the budget side.

The steps that most often slip are the buyer's: a prototype review that waits two weeks for a meeting, a design approval stuck with an absent manager, testers who were never freed from their daily work. Plan those in your calendars at step 4, when the schedule is agreed.

Mistakes buyers make most often

• Skipping the prototype. Discovering a missing workflow during development is the most expensive way to find it.
• No single decision maker. When five people approve, nobody does. Name one person with authority, and a deputy.
• Treating the contract as paperwork. Acceptance criteria, change requests and code rights decide what happens when things go wrong.
• Absent at demos. Feedback given at the end costs much more than feedback given every sprint.
• Leaving accounts in the vendor's name. You should be able to change vendor without losing your software.
• No maintenance budget. Security updates and small fixes are part of the cost of owning software.

Where to start

You do not need a full specification to begin. A one-page brief is enough for step 3. Describe your problem in a few lines, and within 5 business days we show you, on a video call, what your software could look like. You then decide on evidence, with screens in front of you, whether to go further and with which of our three models: a fixed-price build, a subscription with no upfront development cost, or a SaaS we publish together. We do not sell hours or staff.