What Really Drives the Cost of Custom Software (and How to Control It)

Every screen, button and rule has to be designed, built and tested. So the more your software does, the more it costs and the longer it takes.

Some features look small but hide a lot of work. "Users can reset their password" is simple. "Users can see live stock across three warehouses" is not. When you list your features, a good team will help you see which ones are heavy and which are light.

Who will use the software? A customer, a delivery driver, a shop manager and an administrator all need different screens and different permissions.

Each new type of user is almost like adding a small extra product. Imagine a hypothetical restaurant group in Rabat: an ordering app for customers is one thing. Adding a kitchen screen, a driver app and a manager dashboard multiplies the work.

Connections to other systems (sometimes called integrations) let your software exchange information with your accounting tool, your website, a delivery partner or a government platform. Some connect easily. Others are old or poorly documented and take more effort.

Payments need extra care: security, testing, handling refunds and failed payments, and working with local payment providers.

Design ranges from a clean, standard look to a fully tailored brand experience with custom illustrations and animations. Both are valid, but they are not the same amount of work.

In Morocco and much of Africa, software often needs to work in Arabic, French and sometimes English or Amazigh.

More than one language means every text must be translated and checked. Arabic adds another layer, because it reads from right to left, so screens must flip their layout properly. This is very achievable, but it should be planned from the start. Adding a language late is usually harder than building it in early.

Software is not finished on launch day. Phones and browsers update, security fixes are needed, small bugs appear and your team will ask for improvements.

Plan for ongoing maintenance from the beginning. Think of it like servicing a car: a modest, regular effort that prevents big, expensive breakdowns.

Beyond features and screens, a few factors come up again and again in Moroccan projects. None of them is unusual, but each one adds work, so it is better to mention them before you ask for a quote.

• Invoicing and tax rules: if your software produces invoices, they must show the legal details Moroccan invoices require, such as your ICE and the correct TVA. Morocco is also moving towards electronic invoicing with the DGI, so ask how the software could adapt if your obligations change.
• Cash, cheques and LCN: many businesses still get paid by cheque, bill of exchange or cash on delivery. Tracking due dates, unpaid cheques and partial payments is real work and should be listed as a feature, not assumed.
• Local online payments: accepting cards online means working with a Moroccan payment provider and its own testing and approval steps. Allow time for this.
• WhatsApp: customers often expect order confirmations or updates on WhatsApp. Connecting to WhatsApp's official business tools is possible, but it has its own setup, rules and running costs.
• Connectivity: if staff work in a warehouse, on a construction site or in rural areas, the app may need to keep working when the connection drops and sync later. That is more complex than an app that assumes good internet.

Two practical points on the quote itself. First, check whether prices are in dirhams or euros, and whether TVA is included. Comparing a price without TVA to one with TVA is a common source of confusion. Second, ask about the payment schedule. Paying in stages tied to visible progress, such as design approved or first version delivered, protects both sides.

Finally, if a family member or a long-serving employee is the only person who knows how the current process really works, plan time with them early. Their knowledge often shapes the features more than any written brief.

The most reliable method is to start small with a first version. Build only what you need to solve the main problem and test it with real users. Then add more based on what you learn.

To get there:
- Split your wish list into "must have", "nice to have" and "later"
- Be honest about which features really bring value on day one
- Reuse ready-made tools for common needs instead of rebuilding them
- Make decisions quickly, because waiting and changing direction also costs time
- Keep one person on your side responsible for answering questions

A good quote should show:
- A clear list of features and screens
- What is not included
- The main stages, from design to launch
- How testing is done
- Who owns the code and the data
- How maintenance and support work after launch

Red flags to watch for:
- A single price with no breakdown
- No questions asked about your business before quoting
- Promises that everything is "easy" and "fast"
- No mention of testing or maintenance
- Unclear ownership of what is built

At Africodex, we prefer to start with a conversation about your goals, then propose a focused first version with a transparent breakdown. If you would like a clear estimate for your idea, we are happy to help.