South Africa · Development

Bespoke Development for South African Businesses

Choose between eCommerce, app development, PHP changes and custom software for your South African business, and prepare a useful first brief.

Let’s talk

Choose the workflow that needs better software

You may know exactly where work gets stuck without knowing what kind of development to ask for. Perhaps customers need to place orders, staff need a clearer way to complete a task, or an existing PHP application needs a change. Each calls for a different starting point.

We help connect that practical need to a development brief. Start with what someone needs to do and where the current process falls short. The systems you already use, the information they hold and the people who understand the work then help shape the proposed solution.

Find the right development brief

Choose eCommerce development when the work centres on a storefront, catalogue or order journey. Bring the people responsible for products and fulfilment into the discussion: what customers can buy depends on what the business can price, supply and deliver.

Choose app development when customers or staff need to complete a defined task through an application. Explain who uses it, on which devices, and what each person should be allowed to see or change.

PHP development is a starting point for changing an existing PHP application’s behaviour or adding a specific feature. Custom software suits a wider workflow whose rules and connections to other systems still need defining. These routes can overlap; you do not need to settle every technical choice before talking to us.

Prepare a reviewable first phase

Bring an example of the work as it happens today: a sample order, form or sequence of steps, along with where the information comes from. Explain what should happen differently and who can confirm the result. Use synthetic information or agree how sensitive information will be handled before sharing it.

If the code is unfamiliar, a business rule is unclear or an integration is untested, a discovery phase may be the useful first step. It gives the proposal a firmer basis by examining those questions before committing to implementation.

The proposal should make clear which behaviour will be built, whether existing records need moving, which third-party systems are involved and what ongoing support is included. These are separate pieces of work, even when they contribute to the same feature.

Discuss a South African development requirement with one process or application change. The global development programme provides the broader capability overview.

Choose a first transaction the business can review

Follow one record or action from start to finish. For example, a quotation workflow might begin with a customer request, pass to someone who checks the details, and end with a quote sent back to the customer. What information is needed at each step? Who can change it? What happens when a detail is missing?

That example helps identify a useful first piece of software and the exceptions it must handle. A request for “an application to manage everything” gives us much less to work with. Choose a task that matters on its own, then use the relevant service pathway above to explore the build or investigation it needs.

Decide who can accept the first working transaction

The people who use or manage the process should help check the result. Different briefs need different input:

  • An online trading brief needs a product and order owner who can check the purchase through to fulfilment.
  • An application brief needs a representative user and clear rules for who can view, create or change information.
  • An inherited-system change needs an authorised technical contact and someone who can check that existing business behaviour still works as expected.

For that first review, bring a normal example and a realistic exception. A screen may look finished while still missing a rule that staff depend on every day.

Local development selection questions

A few useful answers before you decide.

Should our first phase be eCommerce or a quotation workflow?
Start with how you sell. If a customer can choose a standard product at a known price and the business can fulfil the order, checkout may fit. If the price depends on configuration or an assessment, a structured enquiry may be more useful. Confirm who handles pricing and fulfilment before choosing the interface; a product catalogue alone does not answer those questions.
How do app and custom software scopes connect?
An app can be one part of a wider custom software workflow. Describe the task, users and operating rules first, then discuss device and distribution needs. For example, the person submitting a request and the person approving it may need different views of the same information. A useful first release should complete the chosen task, with permissions, data ownership and future maintenance understood.
When is PHP assessment needed before implementation?
An assessment helps when unfamiliar code, dependencies or release conditions could affect the change. Through authorised access, the work should establish a runnable baseline and check representative behaviour. The assessment should explain what was inspected and what remains uncertain. A repository name or a previous supplier’s description is not enough to estimate a change confidently.
What role do business examples play in acceptance?
They show what a correct result means to the people doing the work. Include a normal case, a meaningful exception and a correction where relevant. If a user enters the wrong detail, for example, explain who should be able to fix it and what should happen next. Use synthetic or appropriately handled information so the review can focus on the behaviour safely.
Can the software connect to our existing tools?
We need to assess the available interface, authorised access and which system owns each record. Explain what should move between the tools and what should happen if a transfer fails or creates a duplicate. A one-record test is a useful start, but the scope also needs to cover the relevant production scenarios, integration responsibilities and any migration work.
What must remain with the business after development?
The business needs its accounts, agreed source ownership and someone authorised to make operating decisions. Release, backup and support responsibilities should be clear in the actual arrangement. If a pricing or approval rule changes later, someone in the business still needs to decide what that rule should be; future development and maintenance must have an agreed scope.

Prepare your next conversation

Tell us which customer transaction or staff task needs to change, what happens today and what a useful result would look like. Include the systems involved and who can help check the work. We can then direct the discussion to the relevant development service.

Plan a local software programme · Resolve an uncertain starting point

Discuss your South African development brief.

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