This is BarmajTek’s operating-evidence page as a software company in Jordan, not a general guide for choosing a vendor. It states what a buyer can test in our method: workflow discovery, the SaaS-or-custom decision, acceptance evidence, Arabic product design, security boundaries, account and data handover, and named operating responsibilities. A market label and technology list are not proof; an inspectable output, scenario, and decision record are.
Start with the work, not the requested screen
Discovery asks who performs the task, which information they need, where they wait, what they decide, and which exception breaks the normal route. “We need a management platform” is too broad. “Staff copy an approved request across three files and cannot see who changed it” gives the team a journey to map and an outcome to verify.
We do not assume that new code is the answer. A ready product may cover the process, a contained integration may remove the bottleneck, or the procedure may need simplification before software. Useful discovery produces understandable artefacts: actors, workflow, rules, data, risks, and an initial release boundary.
Choose ready SaaS or custom delivery honestly
BarmajTek’s software products address defined sector workflows. When a product covers the important journey, configuration, migration, and training are usually more rational than building another version. Custom delivery becomes appropriate when a rule genuinely differentiates the business, an unusual integration is central, or the organisation needs control unavailable from a product.
Custom does not mean turning every preference into code. We separate necessary policy from habit and propose a first release that completes a valuable journey. The software cost planning guide explains why scope and operating responsibility must precede a final estimate.
Define acceptance before declaring completion
Every stage should create an outcome someone can inspect. Instead of saying “scheduling is complete,” define scenarios: an authorised user creates a booking, conflicts are rejected, a reschedule leaves history, and errors provide a recoverable action. The customer exercises the result with fictional data and records decisions.
Acceptance criteria protect both parties. The delivery team knows what done means, and the customer knows what a payment milestone represents. A newly discovered need can be assessed against priorities and timing rather than silently folded into ambiguous scope.
Design Arabic as a product constraint
Arabic is not a translation file added after the interface is finished. We test right-to-left layout, mixed Arabic and Latin content, numbers, dates, search, tables, errors, keyboard operation, and generated documents. Domain terms are reviewed for meaning rather than translated mechanically. English is then treated as a complete experience too.
Logical layout properties and reusable components help direction adapt consistently, but automation does not replace review. “Arabic-first” does not make English secondary; it prevents Arabic from being the exceptional path that breaks the product.
Use Laravel around explicit use cases
Laravel provides mature routing, authorization, queues, database tooling, and testing support. We use those capabilities without placing every rule in a controller or a large Eloquent model. Use cases state business intent, policies protect actions and resources, and provider integrations remain behind application-owned contracts.
Not every module needs extensive DDD patterns. Structure follows domain complexity, risk, and change pressure. The Clean Architecture and DDD guide describes when value objects and adapters earn their cost and when direct CRUD is clearer.
Keep external providers at the edge
Payment, e-invoicing, delivery, identity, and communication contracts change. An adapter translates provider requests, states, and errors into the application’s language. Retry, duplicate safety, monitoring, and reconciliation are designed as part of the integration, not left for an incident.
We test timeouts, duplicate events, invalid signatures, changed amounts, and expired credentials as appropriate to the provider. A regulatory or financial integration is reviewed against current official and provider documentation at implementation time; an old implementation is not presented as permanent compliance.
Treat security as continuing work
Security begins with data sensitivity and consequence, then applies least privilege, secret management, validation, auditability, dependency maintenance, backups, restoration, and incident planning. No product is described as perfectly secure. Controls and shared responsibilities need evidence and recurring operation.
In multi-tenant systems, isolation extends beyond database queries to jobs, cache, files, search, exports, and support access. In every system, demonstrations and tests should use fictional or controlled data unless a documented migration procedure requires otherwise.
Plan migration before cutover
We inventory data sources, fields, attachments, identifiers, duplicates, quality issues, and retention decisions. A trial migration lets business owners validate samples and reconcile counts. The scope also states what will not move and whether an archive remains. Developers cannot decide the meaning of every ambiguous historical value without the customer’s domain knowledge.
After launch, data portability remains a commercial requirement. Export format, relationships, attachments, turnaround, retention, and deletion should be defined. A supplier backup intended to restore its own platform is not a substitute for a usable customer export.
Hand over accounts and knowledge
Ownership of domains, repositories, cloud infrastructure, stores, and provider accounts must be explicit. The customer receives agreed access and documentation; production should not remain dependent on a developer’s personal account. Runbooks cover deployment, restoration, critical configuration, and important architecture decisions.
Code ownership alone is not an operational handover. A qualified team should be able to understand and operate the delivered system within reasonable limits. Pre-existing components, open-source dependencies, licensed services, and custom work must be distinguished.
Define operation after launch
A live system creates continuing tasks: monitor failures, queues, certificates, and capacity; update dependencies; verify recovery; support users; and plan changes. The agreement identifies what BarmajTek operates and what remains with the customer, along with support channels, severity, and escalation. General promises are not useful during an incident.
We prefer small releases, controlled migrations, observability, and a rollback path. Logging should collect what investigation needs while avoiding secrets and unnecessary personal content.
Communicate through decisions and evidence
Progress reporting should state what is complete, what is under review, what is blocked, and which decision the customer must make. Short decision records preserve why an option was selected and when it should be revisited. Regular demonstrations expose misunderstandings before they accumulate.
Customer participation is essential: assign a decision owner, review terminology, approve rules, prepare data, and exercise acceptance scenarios. Software delivery is not an order placed on one side of a wall and returned complete on the other.
How to evaluate BarmajTek
Do not select us because this article says the right things. Apply the Jordan software company buyer checklist and ask us for the same evidence: a fictional product workflow, assumptions and exclusions, acceptance examples, data terms, continuity, and support. Compare us with mature products and other delivery teams.
Ask what remains unknown, which small step would reduce the largest risk, and when we would recommend not building. The quality of that answer is more useful than the speed of a promise.
Bound public claims
We do not publish a customer name, outcome, or performance number without permission and evidence that can be reviewed. Software alone cannot guarantee a commercial result; adoption, process, data, and operation contribute. We can commit to a defined scope, test method, and documented responsibility.
Regulatory and financial claims also require current sources. The team verifies official and provider material during delivery and identifies decisions that require qualified accounting, legal, or sector advice.
Use products to inform custom engineering
Operating a product creates practical questions about upgrades, support, tenancy, configuration, and data portability. Those questions inform custom delivery, but one product’s design is not copied blindly into every system. Requirements and risks still decide.
Likewise, custom projects can reveal reusable engineering practices without moving customer data or proprietary rules into a shared product. Boundaries between engagements remain explicit.
Test BarmajTek through operating evidence
The evidence we offer is a clearer problem, a testable decision, protected access and data, and a system that can be operated and changed. Apply the Jordan software vendor due-diligence checklist to these claims exactly as you would for another supplier. If you have a defined operational journey, send BarmajTek an evidence-first project brief with the users, current handoffs, data sources, and hardest exception; the first response should produce something you can inspect.
