Webvelopment
South Africa · Development

Custom Software Development in South Africa

Plan custom software around a South African business workflow: compare build and buy options, clarify handovers and choose a useful first release.

Let’s talk

Fix a defined operating problem

Two colleagues working side by side with laptops and notebooks.
Illustrative photography · Christina @ wocintechchat.com M / Unsplash

Start with the task that keeps getting stuck. Perhaps staff copy the same request between tools, chase missing information or disagree about whether a handover is complete. Custom software may help, but an existing product, a configuration change or an integration may solve the same problem with less to maintain.

At Webvelopment, we start with the record behind the task and the people who use it. What must they enter, decide and pass on? That gives us a practical basis for discussing a first release. It also helps you decide whether the work justifies a custom application before committing to a long feature list.

Establish the rules before the interface

A screen is easier to discuss when the business rules are clear. Identify who creates each record, who can change it and which system holds the version everyone should rely on. Then work through the awkward cases: an order changes after approval, a request is declined or a required detail is missing. Each needs a sensible next step for the person using the software.

A proposed scope can include workflow discovery, a data model, prototypes, implementation, authorised integrations and an agreed migration. We also need to specify the training, reporting and ongoing support you require. If another platform will stay in use, make that part of the discussion early; replacing it or its supplier is not assumed.

Review with the people doing the work

Bring someone who can confirm the business rules and staff who regularly carry out the task. They answer different questions. A manager may confirm when a request can proceed, while a staff member can spot that the proposed form asks for information they only receive later.

We can turn those examples into checks for the working software as it develops. Ask users to complete a task, correct a mistake and pass the record to the next team. Looking at an approved design alone will not show whether the system saves the right information or permits the right actions.

Before release, agree who manages user access and backups, how records will move across and what happens if the changeover needs to be reversed. The handover should explain how to request future changes. If sensitive information is involved, agree how it will be handled before sharing it for development or testing.

Bring the departmental handover into the first brief

  • Identify which team creates the record and what the next team needs before it can act.
  • Bring an example of a handover that stalls: a missing detail, an unresolved approval or two conflicting versions of a record.
  • Choose a useful part of the workflow to introduce first, and identify which existing tools will still hold the records other teams depend on.

Common questions

A few useful answers before you decide.

Should we build rather than buy a tool?
Not automatically. Start by showing where the current tool falls short. Compare that task with an existing product, a configuration change and a small integration. A custom build needs a reason in the way your business works, along with a plan for looking after the application once people depend on it.
Can we introduce it in stages?

Often, one complete workflow makes a useful first phase. It should let someone finish a real task, even if other departments keep their current tools. Shared records and dependencies determine whether that part can be introduced on its own.

Explore the global custom software service. Discuss one local operating problem with an example record, the current handovers and the person who can explain the business rules.

Follow one record through the proposed system

For example, imagine a South African business replacing a shared purchase-request spreadsheet. An employee creates a request, a manager approves it and an operations team acts on it. Before choosing a dashboard, work out what makes a request ready and what happens when it changes.

Suppose the employee changes the quantity after approval. Should that send the request back to the manager? Can operations still act on the earlier version? The answer affects who can edit the record, its status and what each person sees next. This is an illustrative business rule to settle with your team, rather than an account of a completed Webvelopment installation.

A first release could cover one request type, including incomplete, declined and amended requests. Those examples give users something specific to check: can they see why a request stopped and what they need to do next?

Bring redacted records and current instructions, including an example that went wrong. Identify any existing system that must retain ownership of customer, order or financial information. That helps us discuss what the new application should store and where it should refer back to an existing record.

More questions for a local software programme

A few useful answers before you decide.

How do we know the problem needs custom software?
Describe the step your current tools cannot handle, then compare the alternatives against that step. Include the people who will maintain the records and handle future changes. If a product or integration can meet the need, discovery should leave that option open. A custom application is easier to justify when you can explain the rule or handover that other options cannot reasonably support.
Can one department begin before the whole business changes?
Possibly. Follow a record into and out of that department first. Which decisions still belong to another team, and where will both teams check the current information? A pilot needs someone responsible for its use and a way for staff to report problems. Agree which records belong in it so it does not create conflicting copies of information used elsewhere.
Who is responsible for data quality?
Your business needs someone who can explain what correct information looks like and resolve conflicting records. Development can provide checks and migration tools, but it cannot reliably choose between undocumented versions of the same record. Agree who prepares the data, how old fields map to the new ones and how the imported records will be checked. Sensitive or production data also needs an agreed handling plan.
How are requests from different managers prioritised?
Agree who can decide what enters the next release. When requests compete, relate them to the task being improved: does the change help staff complete it, resolve an exception or meet a dependency? Keep other useful ideas in a backlog for later discussion. Adding a request to that list should not be treated as a commitment to build it.
What should be included in user acceptance?
Ask representative staff to follow a record from creation to handover, including a refusal, missing information and a correction where relevant. The person responsible for the business rules should check the resulting records and permissions. Let staff try the task themselves; a developer’s demonstration can miss confusing labels or a step that does not fit everyday work.
How do we plan future improvements?
Keep a list of requests and explain how they will be reviewed. Name the people responsible for the application, user access, hosting and backups, and agree what support is included. Future changes need their own scope and release decisions. This gives you a way to improve the software without assuming that the first build includes every later request or unlimited maintenance.

Prepare your next conversation

Bring one repeatable workflow, a redacted example record and someone who can explain what happens when the usual path breaks down. We can use that material to discuss whether the next step is a build, an assessment or an integration, and what a useful first release would let your staff do.

Plan adoption and operational handover · Investigate what remains uncertain

Discuss your custom software brief in South Africa.

Keep exploring

Keep the right things connected.

Development

Custom Software Development

Plan custom software around the tasks your staff and customers need to complete, with clear rules, permissions, integrations and handover.

South Africa · Contact

Contact Webvelopment About a South African Project

Discuss a South African website, software, eCommerce, marketing or creative brief with Webvelopment, including goals, current tools and the people reviewing delivery.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk