Custom Software: When Your Company Needs It and How to Define It

When orders are pursued between emails, spreadsheets and messages, the problem is not usually the lack of another tool. It may be that your company process does not fit well in those you already use.

The custom software can solve that situation if you need to organize a specific operation, connect tools or give each person access only to the information and actions that correspond to him. But it is not the automatic response to any internal disorder.

This guide answers a practical question:When is it worth putting in custom software and how can you define it before asking for a proposal? When you finish, you can distinguish whether you need to adapt an existing solution, automate a part of the process, or develop an application of your own.

Direct response

Custom software is an application created to cover rules, users, data and processes defined by your company. It can be an internal panel, a customer portal, an order system, or a tool that connects multiple applications.

It is worth assessing when a major need is not reasonably resolved by a standard tool. For example, because your team must follow too many manual steps, because there are specific rules that a generic solution does not contemplate or because the information is distributed in systems that do not communicate with each other.

Before deciding, separate three layers:

This separation avoids starting with a technical label. Ordering an app, a CRM or an ERP does not define the project by itself. First you need to specify which problem to solve.

Context and scope

A standard tool can be sufficient if it allows working with few adaptations and its limits are acceptable. Developing from scratch does not add value just because it is customized.

The need for custom software appears when the process has particularities that it is not appropriate to move to a rigid template. It may occur, for example, if:

• different persons should consult, modify or approve information according to their role;
• an order passes through states that are your own operations;
• you need to keep a specific traceability of actions or documents;
• several tools contain related data and the equipment must copy them from one to the other;
• a customer needs to consult information, request something or follow a process without relying on emails and calls.

Imagine, hypothetically, a company that receives requests through various channels. One person registers them on a spreadsheet, another prepares the answer and a third updates the customer. If each step depends on remembering what to do and where to point it out, the problem is not only the tool: there are also states, responsible and exceptions to define.

The initial scope does not have to cover the entire company. In fact, it is usually more useful to start with the flow that causes a concrete and repeated friction. The rest may be foreseen as evolution, but it should not be confused with what will be built first.

Practical criteria for deciding

The decision is not to choose between ‘cheap tool’ and ‘complex development’. It is to assess the adjustment between what you need and what you are willing to maintain.

Check if the process is sufficiently defined

You don't need to come up with a technical specification. You need to be able to explain what happens now, who intervenes and what should happen otherwise.

A useful description is observable: ‘When a request comes in, we must assign it, ask for information if it is missing, approve it and notify the customer’. A description such as ‘we want to better manage the requests’ still requires work of definition.

Identify users, permissions and data

A software starts to change its scope when there are different user profiles. It is not the same as a panel that consults a person as a system where employees, managers and customers perform different actions.

It clarifies at least:

• who will use the tool;
• what you can view, create, edit or approve each profile;
• what data are entered and where they come from;
• which decisions should be registered;
• what should happen when information is missing or an error occurs.

Permits matter because they affect the system’s operation and security. They should be defined from the start, although some details are adjusted during the project.

Examine integrations without taking them for granted

Connecting the software with billing, mail, payments, inventory or other services may be necessary. It also introduces dependencies: accesses, data exchange rules, external service limits, and behaviours when a connection fails.

It is not enough to write down "integration with X". Define what information comes out or enters, when and who should review the incidents. This way you can assess if integration is essential in the first version or can be postponed.

Think about maintenance before launch

The development does not end when the application starts to be used. It will be necessary to decide who updates content or data, who manages users, how incidents are corrected and what changes are predictable.

It is also important for the company to maintain control over accesses, accounts and relevant data. It is not an administrative detail: it conditions the continuity of the tool.

Application: How to prepare a first scope

You can turn a general idea into a project base without yet choosing technology. Start with one page for each important stream and respond, with business language, to these questions:

What goal is it? describes the expected change: reduce duplications, centralize information, allow a client to consult a state or avoid a particular manual task. 2.

Who starts the flow? Indicates whether a client, a team person, a controller or an external system does. 3.

What steps do you have? Sort actions from the start to the result, including approvals, notices and possible returns. 4.

What information you need each step? Includes fields, documents, states and data that need to be viewed or updated. 5.

What situations require exception. For example, what happens if data is missing, a request is rejected, or a person is not allowed. 6.

How you'll know it works. Make a specific check.For example: a complete request is registered, assigned to the person indicated and displays a visible state for whom it applies.

Then, it classifies the functions into four groups: essential, desirable, future and out of reach. This decision protects the first version from a list of ideas that grows without order.

If work is done primarily outside the office or requires quick action from a device, a mobile app can be part of the solution. In that case, it is important to assess what tasks really need mobility and which work best from a browser. You can learn about the AVSISTEC approach to mobile applications and business solutions.

Limits to be kept in mind

Custom software does not correct for itself a process that no one has decided how to work. If there is disagreement about responsible, rules or priorities, it is best to resolve it before or during the definition of scope.

It is also not advisable to attempt to replicate in a first version all the generalist tool functions. Each permission, exception, integration and screen adds decisions that need to be built, tested and maintained.

There are cases where a reasonable configuration of an existing tool fits better. For example, if the process is common, it changes little and does not require particular rules. It may also make sense to automate a particular point rather than create a complete application.

Finally, there are decisions that require specific validation: the processing of personal data, sectoral requirements, legal obligations or conditions of third party services. A technical project should consider them, but does not replace legal, fiscal or regulatory advice that may be necessary.

Next step

The clearest signal is not "I need an app", but to be able to name a process that generates repeated work, errors of coordination or lack of visibility. From there, it defines the objective, the minimum flow, the people involved and what should be left out of the first version.

If you can already describe that situation, see the custom software service for companies and explain your project to AVSISTEC to assess what type of solution fits your process and what information should be specified before developing.