How to turn a business process into internal software

You do not need to write a technical specification to turn a business process into internal software. With Maleus, you start from what already exists: your documents, your tools, and the way your team works every day.

Maleus asks questions, reformulates the main features, and proposes a versioned roadmap with a clear cost. Once you approve it, Maleus builds the application. You can then use it, check that it works as expected, and request adjustments directly while reviewing it.

1. Share the process as it exists today

Gather the material your team already uses. It can include:

• XLSX (Excel) spreadsheets with tracking data, calculations, or task lists;
• Word documents describing procedures or templates;
• PDFs such as forms, supplier files, reports, or contracts;
• PowerPoint presentations used to explain the process;
• meeting transcripts, emails, and notes;
• screenshots of existing tools.

There is no need to reorganize everything before sharing it. These materials help Maleus understand the vocabulary, information, and documents that matter to your team.

For example, a supplier validation process can be described in four numbered steps:

1. A requester submits the supplier information and supporting documents.
2. The operations team checks that the dossier is complete.
3. The designated approver accepts it or requests a change.
4. The approved information is recorded in the reference tool.

2. Explain your daily work in natural language

Talk to Maleus as you would talk to a colleague joining your team. You can write or speak directly to explain:

• what starts the process;
• who does what;
• which information is required;
• what usually blocks a dossier;
• who validates the result;
• what should happen once the work is complete.

You can also describe exceptions as they come to mind. For example: “If a document is missing, the requester must be notified”, or “A manager must approve dossiers above this amount.” Maleus will ask follow-up questions when something needs to be clarified.

3. Show the information and tools involved

Concrete examples are often more useful than abstract descriptions. You can show Maleus:

• the spreadsheet where cases are currently tracked;
• the Word template used to create a summary;
• the PDFs attached to each dossier;
• the PowerPoint deck shared during a validation meeting;
• screenshots of the current CRM, ERP, back office, or internal portal.

Maleus uses these examples to identify what the application must display, collect, generate, or transfer. You remain in control of which documents and data are shared.

4. Review the proposed application and roadmap

Once the process is understood, Maleus summarizes the main features in business terms. For example:

1. Submit a dossier and its documents.
2. Check missing information.
3. Assign the dossier to the right person.
4. Approve it or request a correction.
5. Track its progress and history.

You review these main points before development begins. Maleus then proposes a roadmap split into useful versions, with the scope and cost of each version. You can validate the order, remove anything unnecessary, or add an important case that was missed.

5. Let Maleus build

After the roadmap is approved, Maleus builds the agreed version. Depending on the scope, this work can take several hours or several days.

During this time, Maleus turns the shared material and validated decisions into a usable application. The application is reviewed and tested before it is presented to you.

6. Use the application and comment as you go

The most useful review happens while doing the real work. Open the application, follow a typical case, and check the result with examples you know.

With the Maleus review experience, you can comment directly while using the application, including by voice. Point to what needs to change in natural language: a missing field, an unclear label, a different validation step, or information that should appear earlier.

Maleus collects this feedback, makes the adjustments, and prepares the next version. You do not have to translate your comments into technical tickets.

What you need to get started

• one recurring process your team wants to simplify;
• a few representative documents or screenshots;
• someone who knows how the work is actually done;
• availability to answer questions and review the proposed features;
• a real example to test in the first version.

That is enough to begin. The details are clarified with Maleus throughout the project, then validated before each version is built.