Custom software development process: the stages and how to get custom software built

The sales team collects orders over WhatsApp, the warehouse enters them into an Excel file, and accounting types the same information a third time. You have looked at the off-the-shelf programs on the market; none of them quite fits your approval sequence, your discount rules or the way your field staff work. You are thinking of having a software company build custom software, but the answers to “where do we start, what do I do, when does it go live” are not clear. This guide explains the process from your side, through the eyes of the person who will make the decisions.

Custom software development is the process of building software around an organisation’s business rules, user roles and integration needs where an off-the-shelf package is not enough. The process generally has six stages: needs analysis, design, development, testing and acceptance, go-live, and support. Below you will find what happens at each stage and what is expected of you.

What is custom software development, and when do you need it?

Custom software is not the right answer for every business. If several of the signs below apply at the same time, you have reached the limits of an off-the-shelf solution:

• Your process departs from the industry standard; your approval sequence, pricing rule or record format is unique to you.
• Every month you add a new Excel sheet or make manual corrections to fit the off-the-shelf program to your process.
• Several systems (orders, stock, accounting, field) need to exchange data with each other.
• Different roles must see and do different things on the same record; the permission rules come from the process.
• Field staff need a short-step flow they can use on their phones.

Software development stages: the table at a glance

How do you get custom software built? The process step by step

1. Needs analysis: process before screens. No screens are drawn in the first step; goals, users, data and business rules are worked out. The answers to “who opens an order, who approves it, when is it sent back, what are the exceptions?” are put in writing. What is expected of you is to involve the person who actually runs the process in these meetings; the process as described by a manager alone is often not the same as the one actually followed in practice. The decision at this stage is what goes into the first version and what is left for later.
2. Design: user flow and architecture. Which steps will the user take and in what order, which role will see what, where will the data be kept, which systems will it talk to? At this stage screen mock-ups and the technical structure are handled together. Your job is to check the mock-up by walking through your own daily work on it: “how many steps does the task I do most often take on this screen?”
3. Development: modular progress. If the software is built in parts, each part can be tried early. A big package delivered all at once is the surest way to discover misunderstandings as late as possible. At this stage you are expected to give quick feedback on interim versions and to channel decisions through one person; different requests from three different managers quietly expand the scope.
4. Testing and acceptance: try it with your own data. Testing is not only the developer’s job. Acceptance criteria should be written down from the very start: “accepted when this scenario gives this result”. Test the system not with sample data but with a real week of your orders, cancellations and exceptions. The decision point is whether the criteria are met.
5. Go-live: from the old setup to the new. Going live is as much a change of habit as a technical event. When the old Excel file will be retired, how existing records will be migrated and how users will be informed should be planned in advance. Otherwise everyone works in two places at once and the argument about which one is current begins.
6. Support and improvement: go live and measure. The work does not end when the system goes live; real usage becomes visible with real data for the first time. Which screen gets skipped, where users get stuck and which report is missing all emerge from actual use. Collecting feedback and prioritising the next improvements is your decision.

Who should be on your side throughout the process?

Software projects most often get stuck not on technical issues but on a gap in ownership on the customer’s side. Four roles should have a name attached; one person can take on more than one, but none should be left unfilled:

• Decision-maker: the person with the final say on scope, priorities and acceptance. They should be reachable at every interim version, not once every few weeks.
• Process owner: the person who runs the work day to day and knows the exceptions. They are the most valuable source of information in the analysis.
• End-user representative: the employee who will actually use the software in the field, the warehouse or the office. They tell you whether the screen flow really works.
• Data and systems owner: the person who knows where the current files, databases and other systems are; the contact for integration and data migration questions.

Naming these four roles in the first meeting speeds up most of the later stages, because the “decision point” at each stage really depends on one of these people answering in time.

Process before screens; users, data and business rules before the feature list.

How far can you go with Excel, WhatsApp and off-the-shelf software?

In small teams, with few records and rules that rarely change, Excel and WhatsApp work perfectly well, and they need no development at all. The problem starts when versions multiply, when several people update the same file and when the question “who approved what, and when?” comes up. Permissions cannot be separated, history cannot be tracked and information stays on people’s phones. Off-the-shelf software is usually the fastest route when your process is standard; custom software makes sense where your real difference lies in your process and fitting it into a ready-made tool creates work for you every month.

Sometimes the solution is not new software but a simpler process. Mapping the current flow first, seeing the bottleneck and deciding only after that often gets results more cheaply and more quickly. A digital transformation roadmap is a step you can take before the software decision.

Six common mistakes that slow the process down

• Skipping the analysis and asking for screens straight away.
• Not involving the person who knows the process in the meetings.
• Not putting the acceptance criteria in writing.
• Trying to fit everything into the first version; not keeping a list for the second version.
• Several decision-makers requesting changes without knowing about each other.
• Leaving go-live and user communication until the last day.

How does YazSis run the custom software process?

YazSis runs custom software work under four headings: first, goals, users, data and business rules are worked out; then the user flow and a sustainable technical structure are designed; next come modular development and validation with real scenarios; finally, the system goes live, is measured and is improved with feedback. The scope can include web applications, role-based admin panels, request-approval-assignment flows, mobile apps, API services for data exchange with other systems, and back-office interfaces for busy operations teams. We do not give a timeline or a price in this article; both are discussed together with the scope after the analysis.

If you are not sure which stage your process should start from, you can look at our approach on the Custom Software page and start a first conversation by briefly describing your need.