How to Choose a Software Development Company in South Africa: 12 Questions Before You Sign

Choosing a software development company means assessing much more than coding ability.

Most competent teams can implement features. The harder question is whether the partner can help you avoid building the wrong product, make sound architecture choices, protect the business from avoidable delivery risk and leave you with software that can still be changed after the launch invoice is paid.

For a South African business appointing a software partner, evaluate the whole delivery system:

discovery → product decisions → architecture → engineering → security → quality → delivery transparency → ownership → support

Start with the problem, not the feature list

A weak software brief is a long list of screens and features.

A stronger brief explains:

• target users;
• business problem;
• current process;
• desired outcome;
• key constraints;
• systems that must integrate;
• important risks;
• known evidence;
• budget or investment boundaries;
• decision timeline.

Why does this matter?

Because a good partner should challenge whether the proposed feature set is the best way to achieve the outcome.

If the supplier's only contribution is translating your backlog into developer hours, you are buying production capacity, not product expertise.

Question 1: What happens before development starts?

Ask how the company handles discovery.

A credible process may include:

• stakeholder interviews;
• user research;
• process mapping;
• existing-data review;
• technical discovery;
• architecture assessment;
• prototype testing;
• scope prioritisation;
• risk identification.

The depth should match the project.

A small internal tool may need a few focused sessions. A multi-tenant marketplace with payments, identity and logistics needs more.

Be wary of a supplier that can quote a complex build precisely after a 30-minute sales call. Precision is not the same as knowledge.

Question 2: How do you reduce scope before you add it?

Ask the team to identify what they would not build first.

Strong product teams look for:

• unnecessary features;
• manual processes that can remain manual initially;
• assumptions better tested with prototypes;
• integrations that can wait;
• edge cases that do not belong in the first release;
• existing products that can replace custom development.

This protects capital and speeds learning.

A supplier paid purely for engineering volume has a natural incentive to discover that every idea is essential. Procurement should account for that delightful little coincidence.

Question 3: Who owns product decisions?

Clarify responsibilities.

Who decides:

• priorities;
• acceptance criteria;
• user experience;
• technical trade-offs;
• scope changes;
• release readiness?

A healthy model often has:

• a client-side business or product owner;
• a partner product lead or analyst;
• design and engineering ownership;
• explicit escalation when trade-offs affect budget or outcome.

Do not outsource the business decision entirely. The partner can advise, but the organisation remains accountable for what it funds.

Question 4: How do you approach architecture?

Ask the technical lead to explain the architecture in business language.

The answer should cover:

• application structure;
• data storage;
• integrations;
• authentication and permissions;
• hosting;
• observability;
• scaling assumptions;
• third-party services;
• failure modes;
• backup and recovery where relevant.

Good architecture is proportional.

A small MVP does not automatically need microservices, Kubernetes and an event bus. An enterprise transaction platform may genuinely need more robust separation and resilience.

Architecture should fit the risk and expected evolution of the product.

Question 5: How is security built into delivery?

Security should not appear as an optional penetration test in the final week.

Ask about:

• authentication;
• authorisation;
• secrets management;
• secure development practices;
• dependency management;
• environment separation;
• logging;
• data protection;
• vulnerability handling;
• security testing.

For higher-risk products, expect stronger controls and specialist review.

The supplier should also be willing to tell you which security obligations sit with third-party infrastructure providers and which remain with the application team.

Question 6: How do you test quality?

Ask for the testing strategy, not merely whether there is a QA person.

A mature approach may combine:

• unit tests;
• integration tests;
• end-to-end tests;
• accessibility tests;
• visual regression tests;
• performance tests;
• security tests;
• user acceptance testing;
• production monitoring.

The mix depends on the system.

What matters is whether critical workflows are protected automatically enough that future changes do not depend entirely on human memory.

Question 7: How will we see progress?

You should be able to inspect working software regularly.

Ask about:

• delivery cadence;
• demonstrations;
• staging environments;
• backlog visibility;
• issue tracking;
• release notes;
• risks and blockers;
• budget burn;
• scope change.

A monthly status deck is not a substitute for access to the product being built.

Early visibility lets the business correct misunderstandings while they are still cheap.

Question 8: How are estimates handled?

Software estimates contain uncertainty.

A credible supplier should explain:

• assumptions;
• what has and has not been discovered;
• confidence range;
• third-party dependencies;
• change-control method;
• how scope and budget trade off.

Fixed pricing can be appropriate for well-understood scope. It becomes dangerous when the scope is uncertain but everyone pretends otherwise.

The risk does not disappear. It is merely hidden inside contingency, exclusions or later change requests.

Question 9: Who owns the code and accounts?

Clarify this contractually before development.

The business should understand ownership of:

• source code;
• design files;
• infrastructure accounts;
• domains;
• cloud resources;
• repositories;
• app-store accounts;
• third-party subscriptions;
• data;
• documentation.

Where practical, critical production accounts should be under client control with appropriate partner access.

A handover should not require negotiating the release of your own system.

Question 10: What documentation will exist?

Useful documentation can include:

• architecture overview;
• local development setup;
• deployment process;
• environment variables;
• data model;
• API documentation;
• runbooks;
• third-party dependencies;
• admin guidance;
• backup/recovery process.

Documentation should reduce key-person dependency.

It does not need to become an encyclopaedia that is obsolete before anyone reads it.

Question 11: What happens after launch?

Ask who owns:

• monitoring;
• incidents;
• security patches;
• dependency updates;
• backups;
• user support;
• bug fixes;
• feature roadmap;
• performance;
• cloud cost.

A live product needs an operating model.

GOV.UK's service guidance makes the same point: moving into live includes sustainable support, security, performance, quality assurance and ongoing iteration.

Launch is a milestone, not the disappearance of engineering responsibility.

Question 12: What happens if we part ways?

A professional supplier should be comfortable with an exit plan.

Ask whether another competent team could take over using:

• the repository;
• documentation;
• infrastructure access;
• issue history;
• architecture records;
• credentials transferred securely;
• deployment instructions.

Exitability improves discipline even if the relationship lasts for years.

Evaluate evidence, not only portfolio screenshots

Ask to see evidence relevant to your project type.

For example:

• repository structure;
• testing approach;
• architecture diagrams;
• production monitoring;
• case studies;
• references;
• examples of handling scope change;
• examples of systems maintained after launch.

A polished interface proves design capability. It does not prove secure backend engineering, data migration, delivery governance or long-term maintainability.

Check whether the team understands your business model

A marketplace, subscription product, internal workflow tool and ecommerce platform have different economic and operational concerns.

The partner should ask about:

• how value is created;
• who pays;
• transaction frequency;
• customer acquisition;
• support model;
• regulatory constraints;
• operational dependencies;
• unit economics.

Product decisions are business decisions expressed through software.

Red flags

Be cautious when:

• the supplier never challenges scope;
• the quote contains no discovery assumptions;
• architecture is described only through fashionable technologies;
• there is no automated testing strategy;
• security is postponed until launch;
• you cannot access the repository;
• working software appears late in the project;
• every change becomes a surprise invoice;
• production accounts are owned only by the supplier;
• documentation is excluded;
• support after launch is vague;
• the company cannot explain what would make it recommend buying instead of building.

Compare proposals on total delivery quality

A useful scoring model can include:

Weight the categories based on the product.

A regulated financial workflow should weight security and reliability more heavily than a marketing microsite.

Do a paid discovery before a large build when uncertainty is high

For complex products, consider commissioning a smaller discovery or product opportunity sprint first.

Useful outputs include:

• validated problem statement;
• key user journeys;
• prototype;
• technical constraints;
• architecture options;
• prioritised release scope;
• risks;
• delivery estimate with clearer assumptions;
• build, buy or stop recommendation.

This gives the business something valuable even if it chooses a different delivery partner later.

Contract for change

Software projects learn things.

The contract should therefore explain:

• how priorities change;
• how new scope is estimated;
• who can approve changes;
• how budget is tracked;
• what constitutes acceptance;
• how defects are handled;
• how third-party cost changes are treated.

Pretending requirements will never change does not make them stable.

The practical takeaway

Choose a software development company that improves the quality of your product decisions, not merely the velocity of your feature factory.

The right partner should help you:

• validate before overbuilding;
• choose proportional architecture;
• see working software early;
• protect critical workflows with testing and security;
• retain ownership and exitability;
• establish a sustainable live operating model.

Those capabilities are less visible than a homepage animation. They are also what determine whether the software remains an asset after the launch photos stop circulating.

Further reading

• GOV.UK Service Manual, How the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
• GOV.UK Service Manual, Making prototypes: https://www.gov.uk/service-manual/design/making-prototypes
• GOV.UK Service Manual, How the live phase works: https://www.gov.uk/service-manual/phases/live/

Abrasim's Product Opportunity Sprint separates opportunity validation from a large build commitment. It gives leadership enough evidence to decide what to build, what to buy, what to test and what should never reach a development backlog at all.