{"id":1077,"date":"2026-11-11T21:09:46","date_gmt":"2026-11-11T21:09:46","guid":{"rendered":"https:\/\/zamacore.com\/blog\/?p=1077"},"modified":"2026-11-11T21:09:46","modified_gmt":"2026-11-11T21:09:46","slug":"choosing-a-software-development-company-in-kenya-with-a-dispatch-note","status":"publish","type":"post","link":"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/","title":{"rendered":"Choosing a Software Development Company in Kenya With a Dispatch Note"},"content":{"rendered":"<figure><img decoding=\"async\" src=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/11\/zamacore-choosing-a-software-development-company-in-kenya-with-a-dispatch-note-flier.webp\" alt=\"ZamaCore buyer guide to choosing a Kenyan software development partner\"><\/figure>\n<p>A dispatch note with a correction in the margin can tell you more about a software development company in Kenya than a polished slide deck. Put that note on the table. Explain what was ordered, what actually left the depot and who discovered the difference. Ask the developers to walk you through what a supervisor should see the next morning. The quality of their questions will reveal whether they understand the business they want to serve.<\/p>\n<p>Imagine a distributor in Athi River that supplies hardware shops. A shop orders twelve cartons. The warehouse picks twelve, but one carton is damaged during loading. The driver delivers eleven. Sales still sees an order for twelve, the driver has a signed note for eleven and finance is preparing a statement. Everyone has part of the truth. A buyer choosing a development partner needs to know which team can bring those accounts together without making the clerk invent a transaction.<\/p>\n<p>This guide uses that fictional distributor to show how to run a practical selection exercise. The same approach works for a service business, school supplier or regional wholesaler. Change the document and the discrepancy to match your work. Keep the discipline of following one real event from the first promise to the final decision. That thread makes it much easier to tell whether a proposal will deliver something people can use.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Start_with_the_question_a_manager_needs_answered\" >Start with the question a manager needs answered<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Give_each_candidate_the_same_working_brief\" >Give each candidate the same working brief<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Listen_for_questions_about_authority\" >Listen for questions about authority<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Replace_the_generic_demonstration_with_a_short_exercise\" >Replace the generic demonstration with a short exercise<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Examine_who_will_do_the_work_after_the_sales_meeting\" >Examine who will do the work after the sales meeting<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Read_the_estimate_as_a_list_of_decisions\" >Read the estimate as a list of decisions<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Ask_what_happens_to_a_bad_record\" >Ask what happens to a bad record<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Define_acceptance_through_an_ordinary_working_day\" >Define acceptance through an ordinary working day<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Check_integration_behaviour_at_the_boundary\" >Check integration behaviour at the boundary<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Give_support_the_same_attention_as_launch\" >Give support the same attention as launch<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Evaluate_ownership_by_practising_an_exit\" >Evaluate ownership by practising an exit<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Make_the_selection_meeting_produce_an_actual_decision\" >Make the selection meeting produce an actual decision<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Send_the_finalists_a_decision_they_can_act_on\" >Send the finalists a decision they can act on<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/zamacore.com\/blog\/choosing-a-software-development-company-in-kenya-with-a-dispatch-note\/#Bring_one_difficult_document_to_the_conversation\" >Bring one difficult document to the conversation<\/a><\/li><\/ul><\/nav><\/div>\n<h2 id=\"s1\"><span class=\"ez-toc-section\" id=\"Start_with_the_question_a_manager_needs_answered\"><\/span>Start with the question a manager needs answered<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The distributor&#8217;s owner wants to know which customers still need a delivery and which accounts need a correction. A dashboard might eventually answer that question, but the first requirement concerns responsibility. Someone must record what left the depot, someone must confirm what arrived and someone must resolve any difference. If two people can overwrite the same quantity without leaving a trace, even an attractive dashboard will faithfully display a bad answer.<\/p>\n<p>Before meeting developers, ask the owner to finish a sentence. When a delivery is short, I need this person to know this fact before this other action happens. One business might require sales to contact the shop before raising the next order. Another might require finance to hold only the disputed line while it invoices the undisputed goods. Both are reasonable choices. The developers need to know which business decision the software must support.<\/p>\n<p>Now ask a supervisor for the last three occasions when that decision went wrong. Remove customer names and telephone numbers from the copies. Preserve the sequence of events, including late entries and crossed out quantities. The mistakes that matter often occur between clean screens. A delivery recorded before lunch and amended after closing time might affect a different set of people from a delivery that was never recorded at all.<\/p>\n<p>Bring one example that went smoothly. It gives the development team a baseline and stops an exceptional incident from dominating the entire design. Ask the company to explain how the ordinary transaction stays quick. A solution that asks every driver to complete an investigation form for every carton will probably create a new problem at the gate. The system should spend the most effort where the business faces the greatest uncertainty.<\/p>\n<h2 id=\"s2\"><span class=\"ez-toc-section\" id=\"Give_each_candidate_the_same_working_brief\"><\/span>Give each candidate the same working brief<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Write a short account of the operation, the problem, the people affected and the information available today. Attach the clean example and the difficult one. Tell candidates what must still work if the connection at the loading bay drops. Specify which systems you expect to retain. A team that assumes finance is replacing its accounting package will submit a very different estimate from one that understands the package must stay.<\/p>\n<p>Describe the organisation in units that influence delivery. Number of depots means more when paired with the question of whether they share stock. Number of staff means more when paired with the busiest hour and the number of people entering data at once. A single depot serving several drivers before a morning departure may create a tougher workflow than three quieter depots. Explain the pattern so the company can price the work it actually sees.<\/p>\n<p>Keep the commercial request comparable. Ask each candidate to separate discovery, development, migration, training and support. Require a list of assumptions and exclusions. Where a price depends on another supplier, ask the candidate to identify the dependency and say who will secure access. If the company cannot estimate a phase before discovery, it should say what the discovery will produce and what decision you can make with it.<\/p>\n<p>Give candidates permission to challenge your preferred solution. You may have asked for a driver application when a dispatch terminal and a better proof of delivery process would solve the immediate problem. A capable team should explain the cost and practical limits of both approaches. You can still select the application if the evidence supports it. The conversation is valuable because you learn whether the company can distinguish a business outcome from a feature request.<\/p>\n<h2 id=\"s3\"><span class=\"ez-toc-section\" id=\"Listen_for_questions_about_authority\"><\/span>Listen for questions about authority<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>During discovery, listen for a question that sounds almost ordinary. Who is allowed to change the quantity after the lorry leaves? The answer can reveal more complexity than a long feature inventory. A warehouse clerk may correct a picking error, while a sales representative can acknowledge a customer complaint but cannot adjust stock. Finance may issue a correction after checking both records. Those boundaries shape the software.<\/p>\n<p>Ask candidates what they would write down when the business itself disagrees. Suppose the warehouse supervisor says the driver must sign for the damage, while the transport manager says responsibility passes only after a loading check. A developer should record the disagreement and identify the person who can decide. Quietly choosing the easier rule in code leaves the argument waiting for the first live delivery. It also makes the test results much harder to interpret.<\/p>\n<p>Try a second change. The supervisor is on leave when the discrepancy occurs. Ask how authority transfers to a deputy, when that transfer ends and what the supervisor sees on return. A shared password might make the immediate task appear easy, but it destroys the ability to explain who approved the correction. The development company should be able to describe a practical alternative and the work involved in maintaining it.<\/p>\n<p>Finally, ask who can read a disputed transaction. The driver may need the delivery address and the quantities on the vehicle. That does not mean the driver needs the customer&#8217;s complete statement or commercial terms. An accountant may need the signed evidence without access to dispatch settings. Distinguishing access to information from permission to change it usually makes the resulting screens simpler for everyone. It also gives the buyer something concrete to verify during acceptance.<\/p>\n<h2 id=\"s4\"><span class=\"ez-toc-section\" id=\"Replace_the_generic_demonstration_with_a_short_exercise\"><\/span>Replace the generic demonstration with a short exercise<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Send the anonymised dispatch note ahead of time. Give each finalist the same opportunity to prepare and explain that you want a walkthrough of the process. A diagram or paper prototype is sufficient at this stage. The purpose is to understand the team&#8217;s reasoning, so do not demand a free working application. Paid discovery may be appropriate when the exercise grows into substantial design work.<\/p>\n<p>At the session, give the role of dispatcher to someone who actually dispatches goods. Have a colleague play the customer who receives eleven cartons. Ask the development team to narrate the sequence and say where the system would need evidence. When the customer calls the next morning, ask the dispatcher to locate the disputed line. Observe how many assumptions the developers make about who is available to answer a telephone call.<\/p>\n<p>Introduce one unexpected event after the basic walkthrough. The driver&#8217;s proof arrives twice because a device retries an upload. Ask whether the second copy would create another delivery, replace the first or attach evidence to the original. You do not need a lecture on implementation. You need an intelligible account of what the user sees and how the business avoids sending a second carton or issuing two credits.<\/p>\n<p>Let finance ask the final question. Can I tell which figure went into yesterday&#8217;s statement and why today&#8217;s figure is different? A company that answers by opening the current order screen has answered only half the question. It must account for the earlier state and the correction. If that capability depends on a manual register outside the new software, the proposal should name the register and the person who will maintain it.<\/p>\n<h2 id=\"s5\"><span class=\"ez-toc-section\" id=\"Examine_who_will_do_the_work_after_the_sales_meeting\"><\/span>Examine who will do the work after the sales meeting<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A compelling sales presentation can be delivered by someone who will never attend a working session. Ask to meet the person responsible for turning an unresolved rule into a design decision and the person responsible for testing the resulting behaviour. In a small team one person may hold several responsibilities. What matters is that the buyer knows who owns a decision and how to reach them when it affects delivery.<\/p>\n<p>Ask the proposed lead to describe a past project problem without sharing confidential client details. Useful answers have a sequence. An assumption changed, a risk became visible, someone made a decision and the team checked the effect. A candid account of a delayed migration can tell you more than a claim that every project finished smoothly. Listen for what the lead learned and how that lesson changed the next delivery.<\/p>\n<p>Meet the person who will speak to operational staff. Strong technical staff can struggle when the word dispatch means one thing in sales and something else at the depot. A good interviewer asks each person to show the document or button they mean. They write a short definition that both teams can recognise. Watch whether the candidate gives quieter participants time to explain how work gets done on a busy morning.<\/p>\n<p>Request a simple continuity plan. If the lead is unavailable for a fortnight, who can open the project, explain the latest decision and run the tests? Ask where notes, designs and deployment instructions live and who on your side can access them. A company can protect its internal methods while still making a client&#8217;s project understandable to a replacement colleague. The response tells you how much operational knowledge will survive staff changes.<\/p>\n<h2 id=\"s6\"><span class=\"ez-toc-section\" id=\"Read_the_estimate_as_a_list_of_decisions\"><\/span>Read the estimate as a list of decisions<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Price differences often come from different assumptions about work around the application. One company might allow for cleaning ten years of customer records. Another might expect your finance team to provide a clean file in an agreed layout. Neither price can be understood without that distinction. Ask candidates to expose assumptions in language that the people doing the work can accept, reject or investigate.<\/p>\n<p>For the distributor, a quote for customer migration should say whether duplicate accounts are identified, who decides which account survives and what happens to the history. If the vendor supplies a report of suspected duplicates, someone in the business still needs time to review it. Include that staff effort in the comparison. The cheapest external quote can consume the most internal time precisely when the warehouse is preparing for a busy trading period.<\/p>\n<p>Split infrastructure and third party charges from development. Ask what happens if a depot opens, archived attachments grow or an integration requires a different subscription. You do not need a confident forecast for every possible future. You need to see which assumptions could materially change the cost and when the supplier will alert you. Compare candidates using the same operating scenario and the same period of support.<\/p>\n<p>Tie each proposed payment to a deliverable you can recognise. Discovery might conclude with an agreed workflow, open questions and a revised implementation estimate. A pilot might conclude when two staff members complete a defined set of deliveries and finance can reconcile the results. Terms are for the parties to agree, but the buyer should be able to explain what has been received when a milestone is due.<\/p>\n<h2 id=\"s7\"><span class=\"ez-toc-section\" id=\"Ask_what_happens_to_a_bad_record\"><\/span>Ask what happens to a bad record<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Most demonstrations show good input. Real migrations contain branch codes that no longer exist, account names entered twice and orders with missing delivery references. Ask the company to bring a small sample into a rehearsal environment and explain the result. A buyer learns more from seeing rejected rows than from a success message declaring that thousands of rows were imported. The rejected records tell you whether a problem can be found and repaired.<\/p>\n<p>Imagine two hardware shops trading under nearly identical names. One pays centrally, the other pays on delivery. Combining their accounts would simplify a customer list while producing a serious commercial mistake. Ask how a suspected match is presented to the person authorised to decide. Record the reason for merging or keeping separate accounts. Make sure the original references can still lead a user back to the right history.<\/p>\n<p>Compare totals before and after the rehearsal. Counting customers alone cannot establish whether outstanding deliveries migrated correctly. Choose a few measures the business already understands, such as undelivered quantities by depot and the number of disputed delivery lines. Look at a sample of individual orders as well. Totals can agree while two customers have exchanged balances, so a good plan uses both aggregate checks and record level checks.<\/p>\n<p>Agree how changes made during the migration window will be handled. If a driver returns while the new system is being loaded, the business needs somewhere to record that delivery. The plan should say who enters the late movement, where it is checked and how duplicate capture is avoided. Ask the shortlisted company to explain the handover in terms a night shift supervisor can follow without access to the project team&#8217;s private chat.<\/p>\n<h2 id=\"s8\"><span class=\"ez-toc-section\" id=\"Define_acceptance_through_an_ordinary_working_day\"><\/span>Define acceptance through an ordinary working day<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Write a pilot script that starts before the driver leaves and ends when finance closes the transaction. Use sample values everyone can follow. Order twelve cartons, load eleven, record one damaged carton and have the customer sign for eleven. Confirm that the missing carton remains visible to the person who must decide whether to replace or cancel it. Check what happens when the customer changes that decision the next morning.<\/p>\n<p>Then run a clean order. Staff should be able to complete a normal delivery quickly, without selecting a reason code that does not apply. Time the exercise only after staff understand it. A slow first attempt may reveal unfamiliarity, while a consistently slow fifth attempt suggests the design is imposing work. Ask the company to observe the employee&#8217;s actions directly and explain which changes would remove unnecessary steps.<\/p>\n<p>Run the exercise with actual permissions. A test performed under an administrator account proves little about what a dispatcher can do. Have a finance user try to amend a loading record and ask the system to explain the outcome. Have a dispatcher attempt to open another depot&#8217;s confidential account information. Record the observed behaviour and compare it with the agreed rule. This gives both parties a clear way to resolve disputes about completion.<\/p>\n<p>Reserve time for retesting. When a failed case is corrected, rerun the original case and one neighbouring case. A fix that blocks editing after delivery could also block an authorised correction. The aim is to see how the new rule affects ordinary work around the defect. Give the supplier the same examples that produced the failure so everyone can tell whether the original problem has been addressed.<\/p>\n<h2 id=\"s9\"><span class=\"ez-toc-section\" id=\"Check_integration_behaviour_at_the_boundary\"><\/span>Check integration behaviour at the boundary<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A supplier may say that the new application integrates with an accounting package or a payment service. Ask for a description of the boundary. Which system creates the reference? Which system can change the amount? What does the dispatcher see if the external service accepts a request but its reply never reaches the application? These questions concern ordinary operational responsibility and can be answered without asking the buyer to understand source code.<\/p>\n<p>Use a small fictional delivery to test the answers. The application sends a confirmed quantity to the accounting system. The reply is delayed, so the dispatcher clicks again. A reliable workflow needs a way to associate both attempts with one business event. Ask the vendor to show where staff can see a pending transfer and who can retry it. The salesperson should be able to explain why a retry will not create a second invoice.<\/p>\n<p>Decide how disagreements are discovered after the immediate transaction. Finance may compare a daily list of confirmed dispatches with the records received by the accounting package. The comparison should identify missing records and mismatched values. It should also distinguish a genuine difference from an item that is still waiting to transfer. A report that treats every delay as an error quickly teaches staff to ignore the report.<\/p>\n<p>Find out who owns changes outside the developer&#8217;s control. An integration can depend on access from a separate vendor, a test account or approval from the buyer. Record that dependency before promising a launch date. Ask for an alternative pilot plan if access arrives late. It may be reasonable to demonstrate the workflow using a sample exchange, provided the buyer understands what still needs to be proved against the real service.<\/p>\n<h2 id=\"s10\"><span class=\"ez-toc-section\" id=\"Give_support_the_same_attention_as_launch\"><\/span>Give support the same attention as launch<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Picture the first Monday after launch. A driver submits a delivery and the depot cannot find it. The customer is waiting and finance is about to raise a statement. Ask each development company to describe how the depot reports the issue, what reference it receives and who decides whether operations should switch to a temporary process. A support promise becomes meaningful when the buyer knows what to do at the moment work stops.<\/p>\n<p>Separate acknowledgement from restoration. A quick reply saying the ticket is being reviewed does not give the depot permission to release replacement goods. Agree what information the first response should contain and how the team will communicate while the incident continues. The business should appoint someone to coordinate its own staff. Otherwise five people may report the same missing delivery and receive incompatible advice.<\/p>\n<p>Ask what evidence staff should attach. An order reference, time and description of the last successful step are usually more useful than a photograph of an entire screen containing customer details. The development company can provide a short reporting guide and a safe way to share any necessary evidence. Have a branch supervisor try it during the pilot. If the guide is difficult to use in a rehearsal, revise it before launch.<\/p>\n<p>Agree how incidents lead to permanent improvements. A temporary correction might allow the depot to finish the day, but someone must decide whether data needs checking elsewhere. Ask the supplier for a short account of what failed, how service was restored and how the team will recognise a recurrence. Managers need enough detail to decide whether to change a process, improve training or commission a software fix.<\/p>\n<h2 id=\"s11\"><span class=\"ez-toc-section\" id=\"Evaluate_ownership_by_practising_an_exit\"><\/span>Evaluate ownership by practising an exit<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Ownership sounds abstract until the buyer tries to continue work without the original developer. Ask the candidate to describe a handover to another qualified team. What files, credentials, instructions, configurations and historical decisions would move? Which third party services belong to your business, and which are supplied under the developer&#8217;s account? Clarify commercial rights with your advisers where necessary and test the practical consequences with the people who would operate the software.<\/p>\n<p>A useful rehearsal starts small. Ask the vendor to show how an authorised buyer representative obtains a usable export of orders with their original references. Can the export identify a short delivery and connect it to the correction? Can a colleague restore the application from a backup into a separate test environment using written instructions? Seeing a backup file exists answers only the first part of the restoration question.<\/p>\n<p>Include attachments in the rehearsal. A database export may contain the name of a signed delivery note while the actual image lives in another location. If that location is missing from the handover, the buyer has transaction records without their evidence. Sample a few documents from different dates and confirm they open against the intended orders. The exercise usually exposes assumptions that never appeared in the system diagram.<\/p>\n<p>Set a place for ongoing knowledge. A decision made during a telephone call should end up somewhere the support team can find. For example, if the buyer agrees that only finance can close a disputed delivery, the reason and the date belong with the project notes. Later changes can then be assessed against the real business decision. This is valuable even if the same supplier supports the system for years.<\/p>\n<h2 id=\"s12\"><span class=\"ez-toc-section\" id=\"Make_the_selection_meeting_produce_an_actual_decision\"><\/span>Make the selection meeting produce an actual decision<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Before opening proposals, have operations, finance and the project sponsor agree on what would disqualify a candidate. A company unable to explain how your business can recover its data may be unsuitable even if its price is attractive. Distinguish such conditions from preferences. A different meeting schedule might be negotiable. An unresolved dependency on an external system may justify a short discovery engagement before a full implementation commitment.<\/p>\n<p>Give reviewers a common evidence sheet. Each person records what they saw, what they heard and what remains unproved. If one reviewer scores migration highly because the presenter sounded experienced, ask which rehearsal or deliverable supports that score. If another scores the team poorly because its diagram was plain, ask whether the diagram nevertheless explained the dispatch discrepancy. This conversation keeps presentation style from drowning out operational evidence.<\/p>\n<p>Speak to references with permission. Ask what happened when scope changed, how the team handled a failed test and whether the client could obtain useful support after launch. Keep confidential details out of the conversation. You are looking for patterns of working that resemble your project. A reference from a different industry can still be relevant if the project faced a similar handover or integration problem.<\/p>\n<p>Write down why you selected the company and which assumptions must be confirmed first. Revisit that note at the end of discovery. If the provider&#8217;s estimate changes, you can compare the new information with the original assumptions and make a reasoned decision. Sometimes the right outcome is a smaller first release. Sometimes it is a different supplier. The selection exercise succeeds when the business understands what it is buying and can recognise delivery.<\/p>\n<h2 id=\"s13\"><span class=\"ez-toc-section\" id=\"Send_the_finalists_a_decision_they_can_act_on\"><\/span>Send the finalists a decision they can act on<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>After the interviews, return to the damaged carton. Write a short note describing what the selected team must prove during discovery. For example, the company must demonstrate a delivery for eleven against an order for twelve, retain the customer&#8217;s acknowledgement and show who owns the residual carton. Include the deadline for resolving that carton and the evidence finance needs before preparing a statement. A finalist can respond to that note with an estimate based on actual work.<\/p>\n<p>Give the dispatcher a copy of the same note and ask whether it describes a day they recognise. They may point out that customers sometimes collect the replacement themselves or that drivers return unsigned notes after the office closes. Decide which variation belongs in the pilot and which can wait. The decision should reflect the frequency and consequence of the exception. Adding every possible variation to the first release can delay the one correction the business most needs.<\/p>\n<p>Once discovery begins, use the note as a reference in the first working session. Ask the proposed lead to sketch the records and responsibilities, then ask the person who will test the software to describe a failure. If both can explain the same delivery in terms the dispatcher understands, the team has a shared starting point. If their accounts diverge, resolve the disagreement while it is still a sketch. An hour spent clarifying the outstanding carton can spare the warehouse from discovering the disagreement after the first customer has already received a misleading statement.<\/p>\n<p>Ask the supplier to give the pilot tester the same brief, so the buyer can compare the proposed solution with the transaction originally used for selection.<\/p>\n<h2 id=\"s14\"><span class=\"ez-toc-section\" id=\"Bring_one_difficult_document_to_the_conversation\"><\/span>Bring one difficult document to the conversation<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>When you approach a software development company in Kenya, bring one ordinary record, one troublesome record and one question your team cannot currently answer with confidence. Give the developers enough background to understand why the answer matters. Then listen for how they connect the warehouse, the customer and finance. A useful partner can translate a correction on a dispatch note into a decision that every affected person can explain.<\/p>\n<p>Start your internal discussion by asking the dispatcher and the accountant to tell the same delivery story separately. The point at which their stories diverge is a strong candidate for discovery. Use that finding to prepare the brief, select the pilot evidence and judge the demonstrations. For more operations guides to inform a buyer brief, continue with the <a href=\"https:\/\/zamacore.com\/blog\/\">ZamaCore business software blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Use a corrected dispatch note to evaluate a software development company in Kenya. Follow the order, delivery and finance records before comparing bids.<\/p>\n","protected":false},"author":1,"featured_media":1078,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1077","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1077","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/comments?post=1077"}],"version-history":[{"count":1,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1077\/revisions"}],"predecessor-version":[{"id":1079,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1077\/revisions\/1079"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media\/1078"}],"wp:attachment":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media?parent=1077"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/categories?post=1077"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/tags?post=1077"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}