This is a buyer due-diligence checklist for choosing a software company in Jordan, not a BarmajTek company profile or an automatic argument for a local supplier. Location can improve shared context, Arabic design, working-hour overlap, and access to current local providers. It does not prove engineering quality, commercial clarity, or reliable support. A defensible selection turns claims into inspectable evidence across discovery, comparable scope, account and data ownership, team continuity, security, support, and exit.
Confirm that custom delivery is the right route
Start by challenging the assumed solution. A mature SaaS product may already cover a common workflow with less implementation risk. A contained integration or process change may solve the actual bottleneck. Custom development becomes credible when the workflow differentiates the business, important systems do not connect adequately, or control and ownership justify the added responsibility.
Prepare a one-page brief before approaching vendors. Describe the problem, users, essential journeys, current data, constraints, target date, and an indicative budget range. Do not send a long wish list and compare totals: each supplier will price a different imagined product. The software development cost guide for Jordan explains how assumptions, migration, operations, and acceptance change those estimates.
Judge the discovery conversation
A capable team asks about work before discussing frameworks. It should explore users, decisions, exceptions, current tools, failure consequences, and the evidence that would make a release valuable. Notice whether the conversation uncovers contradictions and risks or merely confirms everything you say. Agreement is easy; useful discovery often includes a respectful challenge.
Ask for a short written understanding after the meeting. It should restate the outcome, boundaries, assumptions, unresolved questions, and likely risks. Correct misunderstandings before requesting a delivery proposal. The ability to represent your operation accurately is early evidence of communication discipline.
Request proof without requesting confidential information
A portfolio should be more than screenshots. Ask to use a live product, or watch a complete workflow with fictional or safely anonymised data. Do not demand customer names, medical records, commercial metrics, or privileged source code. A supplier that protects other clients’ information is demonstrating behaviour you should want for your own.
Ask the team to explain one difficult decision: what options existed, which evidence guided the choice, how failure was tested, and what changed after release. Request sanitised examples of an acceptance scenario, architecture decision, or operating runbook. These artefacts show whether delivery knowledge survives outside one person’s memory.
Normalise proposals before comparing price
Two totals may differ because one includes discovery, user experience, migration, testing, monitoring, and training while the other covers coding only. Build comparison rows for discovery, design, delivery, content, migration, integrations, security, accessibility, infrastructure, training, support, handover, and exit. Mark omitted items explicitly. An omission is not a saving until someone accepts the responsibility.
Milestones should produce reviewable outcomes. The proposal should explain acceptance, payment timing, change control, assumptions, exclusions, third-party charges, and what happens if a dependency is unavailable. Software will change as evidence appears; the commercial process must make change visible without turning every clarification into a dispute.
Test local fit in the product, not the address
A Jordan-based supplier should be able to design natural Arabic and right-to-left interactions, coordinate during relevant business hours, and verify current local invoicing or provider requirements from official documentation. Ask to see mixed Arabic and Latin input, dates, numbers, tables, and generated documents. “Arabic supported” is a claim; correct behaviour in your acceptance script is evidence.
Local context also includes restraint. Requirements and provider terms change, so a responsible supplier states what must be checked at implementation time. It does not promise permanent regulatory compliance from an old integration or publish unverified fees and settlement times.
Do not reject a distributed team merely because every developer is not in the same office. Evaluate accountability, decision speed, documentation, and communication overlap. The relevant question is whether you know who owns each decision and how continuity is protected.
Compare a company and a freelancer through continuity
An experienced freelancer can outperform a weak agency. A larger company can still concentrate all knowledge in one person. Ask who reviews code, manages infrastructure, verifies backups, maintains design decisions, and responds if the primary developer is unavailable. The team need not be large, but critical responsibilities cannot remain implicit.
Confirm who will actually do the work. Sales credentials may not represent the delivery team. Ask whether subcontractors are involved, how their work is reviewed, and which entity remains accountable. Meet the delivery lead before committing to a substantial engagement.
Put ownership and account control in writing
The agreement should distinguish code created for the project, pre-existing components, open-source dependencies, design assets, and licensed services. Domains, cloud accounts, application stores, analytics, and provider accounts should have clear business ownership and role-based supplier access. Production should not depend on a developer’s personal account.
Data portability needs equal precision. Request a sample export and terms covering formats, relationships, attachments, turnaround, cost, retention, and deletion after termination. Decide what operational documentation and credentials are handed over. The BarmajTek software delivery approach describes the checkpoints we use from workflow discovery through operations; use it to evaluate us as critically as any alternative.
Ask security questions that produce concrete answers
No credible supplier promises absolute security. Ask how secrets, access, dependencies, logs, backups, restoration, and incidents are managed. Which controls are automated? What receives human review? How are vulnerabilities triaged and communicated? The depth should match the sensitivity and consequences of the system rather than a generic tool list.
Clarify the shared responsibility model. Your organisation usually retains duties such as approving access, managing staff changes, setting retention, and responding to suspicious behaviour. The supplier may operate infrastructure and updates. Every boundary should have an owner, especially actions needed during an incident.
Define support before launch
Separate warranty defects, user assistance, routine maintenance, and new development. Request support hours, channels, severity definitions, target response times, escalation, and maintenance notice. “Ongoing support” has little meaning without this detail. Ask how dependency updates, capacity, failed jobs, certificates, and backup restoration are handled.
The launch plan should identify training by role, migration verification, the release window, monitoring, rollback, and named contacts. If no one can explain how the previous version or data would be restored, launch is not ready.
Recognise warning signs
Warning signs include a fixed quote before anyone examines data, refusal to document exclusions, requests for sensitive live data during sales, unmeasured outcome promises, no export path, unnecessary dependence on one provider, and full payment before reviewable output. A very low quote is not automatically bad, but it requires a clear explanation of what is excluded.
High price is not proof either. Ask what risk, capability, or responsibility justifies it. Consider a small paid discovery or prototype with independent outputs before a full commitment. The stage should reduce uncertainty rather than create a throwaway demo that cannot inform delivery.
Check references with respect
When references are appropriate, ask previous clients about communication, scope changes, defects, support, and handover. Do not ask them to reveal confidential information. Compare the reference project’s scale and risk with yours; success on a brochure site is not direct evidence for a regulated multi-tenant platform.
Also inspect the supplier’s own public product and writing. Does the product behave as claimed? Are technical and regulatory statements sourced and reviewed? Does the company correct limitations rather than hide them? Operating discipline leaves traces beyond testimonials.
Turn due diligence into a scorecard
The right software company makes uncertainty visible and proposes an economical way to reduce it. Score each supplier on missing evidence, assumptions, ownership, continuity, support, and exit, then have decision owners accept the residual risks. Local presence adds value when it becomes specific understanding and verifiable accountability rather than a marketing label.
Review the scope of BarmajTek custom software services as one option in your comparison. For local context, see how BarmajTek delivers from Amman, including on-site meetings and national invoicing. If you have a defined workflow and want evidence before a broad proposal, send a workflow due-diligence question. Include the users, current handoffs, data involved, and most difficult exception; record the quality of the response in the same scorecard used for every supplier.
