# Custom Software Development > Plan custom software around the tasks your staff and customers need to complete, with clear rules, permissions, integrations and handover. Canonical page: https://webvelopment.co.za/services/development/custom-software-development/ Language: en Development Plan custom software around the tasks your staff and customers need to complete, with clear rules, permissions, integrations and handover. [Let’s talk](https://webvelopment.co.za/contact/) ## The problem we help solve ![Two colleagues working side by side with laptops and notebooks.](https://webvelopment.co.za/images/lifestyle/pair-programming-1400.webp) Illustrative photography · [Christina @ wocintechchat.com M / Unsplash](https://unsplash.com/photos/two-women-using-macbook-pro-KzU0ezL9tJo) Your team may be copying requests between spreadsheets, chasing approval by email or asking customers to send the same information twice. Those frustrations do not automatically call for a new application. We help you work out which part of the task needs to change and whether an existing tool, an integration or custom software can handle it. For a custom build, we define what someone needs to enter, see, decide and pass to the next person. ## What we can deliver - A walkthrough of the current task and a choice of what to tackle first. - Roles and permissions: who can submit, view, edit or approve each record. - A business application built around the agreed workflow and rules. - Plans for connecting existing tools and moving the records the application needs. - Guidance for everyday use, administration and operational handover. We agree which of these you need before implementation. For example, a customer request form may also need a staff review screen, a way to ask for missing information and a visible status for the customer. ## How we approach the work We follow one request, order or other record from arrival to completion with the people who handle it. We look at where people copy values, check information and correct mistakes. You should be able to review that task with realistic examples: submit a request, return it for a correction, approve it and see what the next person receives. ## Who this is for This service is for operations teams, service organisations and businesses whose approval or data rules are difficult to support in their current tools. It can also suit a workflow shared by customers and staff, where each needs different information and access. You can start with an account of that task and its frustrating steps; you do not need a finished specification. ## Boundaries to agree early Someone in your business needs to own the rules and decide when they change. We also agree maintenance responsibilities, record sources and connections to existing systems. Be clear about work that stays elsewhere. If an accounting tool continues to hold invoice records, for example, the new application needs an agreed way to refer to those invoices. Creating a second editable copy could leave staff unsure which amount to use. We compare configuration and integration options before recommending a custom build. ## Questions before we start A few useful answers before you decide. ### How is the first release defined? We choose a task people can complete from start to finish, then agree who uses it and what a successful result looks like. For an approval workflow, that might include submission, review, a correction and the final handover. The scope also names any exceptions staff will continue to handle manually. ### What do you need from us? Bring a non-sensitive example of what starts the task and what a finished result looks like. Tell us who handles each step, which tools they use and where they get stuck. That gives us something concrete to compare with the configuration, integration and custom-build options. ## Build a decision model before a feature inventory An illustrative brief might replace a manual approval chain: collect a request and supporting information, record a decision and pass the approved item to the next person. Before building screens, we would identify who can approve the request, what they need to check and where that information is kept. Walk through a rejected request, a correction and an unavailable approver as well. Can a requester edit an item after submission? Does changing the amount require another approval? Who can act when the usual approver is away? These answers affect permissions and screens. Staff need instructions for any exceptions that stay manual. Bring representative records with sensitive details removed and involve the people who use them. Explain what happens if a decision is wrong, such as work beginning before approval. That helps us distinguish a screen preference from a rule the application must enforce. ## Define the rule that makes custom development necessary - Show the decision or task your current tools cannot support, including any configuration you have already tried. - Identify which record staff should rely on and who can correct it or approve an exception. - Check the proposed first release against normal, rejected and corrected cases before adding more features. ## Further custom software questions A few useful answers before you decide. ### When is configuration preferable to a custom build? Configuration is worth considering when an existing product can support the task, permissions and connections you need. Compare how staff would use it day to day, what it costs to maintain and where they would still need workarounds. A custom build needs a necessary rule or task the available options cannot reasonably handle. ### How do you identify the source of truth? We trace a record through the process, checking which version staff use and who can correct it. For example, a customer address may appear in both a service application and an invoicing tool. We need to agree where an address change is made and how the other tool receives it. Your team needs to resolve conflicting ownership before we connect the records. ### Can several departments share one application? Yes, subject to understanding their roles, permissions and handovers. For example, “complete” may mean that operations has finished the work while finance still needs to issue an invoice. We would clarify those states and what each team can see or change. Start with one cross-team task before deciding how much of each department belongs in the application. ### What should a useful prototype establish? A prototype should help you answer a specific question. Can a staff member find the information needed to approve a request? Can a customer understand what they need to correct? We walk through the relevant screens together. A prototype helps test the workflow; production reliability, live integrations and historical data still need separate work. ### How do you avoid an unbounded first release? Choose one complete task and agree examples that show it working. Keep later ideas in a prioritised list, checking whether any are needed for that first task to function. For example, a dashboard may wait; a way to return an incomplete request may be essential. ### What does migrating business records involve? We need to map fields, check the records and resolve exceptions as well as move them. Duplicate customers, missing identifiers or old status values may need a business decision. We agree which records are included, who checks the result and what happens to items that cannot be matched. Access and handling need authorisation, and the plan must cover when you switch systems and what to do if the transfer needs to be reversed. ### What will our operating team need after release? Your team needs guidance for the tasks they perform, someone who manages user access and a clear route for problems and change requests. Handover should explain how to add or remove a user, handle agreed exceptions and identify who owns each business rule. We also agree hosting, backup and support responsibilities; the scope determines what is provided and who looks after it. ## Prepare your next conversation Send us the repeated task you want to improve, a non-sensitive input and output example, and the tools involved. Include the awkward case your staff have to work around. We can use that material to discuss whether configuration, integration or a custom application is the most useful next step. [Plan changes across an operating process](https://webvelopment.co.za/solutions/digital-transformation/) · [Assess the uncertain parts first](https://webvelopment.co.za/solutions/technical-discovery/) [Discuss this custom software development brief](https://webvelopment.co.za/contact/). ## Related project scope and planning [Enterprise energy data orchestration](https://webvelopment.co.za/work/enterprise-energy-data-orchestration/) · [Multi tenant business platforms](https://webvelopment.co.za/solutions/multi-tenant-business-platforms/) · [05 customer portal](https://webvelopment.co.za/pricing/05-customer-portal/). Keep exploring ## Keep the right things connected. [Our expertise ### Bespoke Development Plan business software around the work people need to do: choose an application, eCommerce change, PHP update or integration, with a clear first release.](https://webvelopment.co.za/services/development/)[How we work ### Clear decisions. Reviewable progress. How Webvelopment scopes, designs, builds and hands over digital work with clear ownership at every stage.](https://webvelopment.co.za/about/our-process/) 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](https://webvelopment.co.za/contact/)