The questions people actually ask us

Name the process or service, the people using it, the current tools and what you would like to change. A few lines are enough.

No. We can begin with an operational problem and build the scope with you. An existing document is useful, but not a condition for speaking with us.

We check users, available data, dependencies, production constraints and who will own the outcome. Important unknowns become tests or a scoping workshop.

Yes, and that is often preferable. We look for a complete but limited flow that is useful enough to test in real work.

Yes. The team is based in Casablanca and works with organizations throughout Morocco and abroad, remotely or on site when needed.

The office is at 77 Mohamed Smiha Street, 10th floor, apartment 57. The Google Maps link in the footer opens the current route.

Email contact@oscorp.ma or call +212 6 67 19 60 38. The contact form also lets you provide context before the conversation.

Our stated target is a response within 24 business hours. An urgent request should name the affected service, impact and a reachable contact.

Oscorp mainly works with SMEs and business teams that need to connect data, software and operations in Morocco or internationally.

No. It is used to understand the situation, check fit and decide on the best next step. A formal audit then has an agreed scope and deliverables.

Yes. We clarify responsibilities, access and decision-making so we complement existing skills without creating a parallel delivery chain.

Yes. Workshops, reports and deliverables can use the language agreed for the project and its stakeholders.

Completed work, decisions, risks and next steps are shared regularly. A demonstration of a working flow is more useful than a long progress percentage.

We ask for a client-side owner who can settle rules and bring the right users together. Important decisions are recorded.

The engagement states ownership and licensing. Client-specific code, data and agreed access remain available to the client, with an organized handover.

Yes for the delivered scope: useful architecture, operating procedures, configuration points and what another team needs to take over.

We show the impact on outcome, cost and timing, then present the options. Scope changes after an explicit decision, not silently.

The budget is tied to scope, assumptions, integrations, data quality and support level. Uncertain areas are isolated in discovery or a prototype.

Yes. Each milestone targets a demonstrable outcome with acceptance criteria, not merely a list of completed technical tasks.

Users test written scenarios with representative data, including exceptions. Findings are classified before the launch decision.

Yes when the project requires it. The stabilization period follows real usage, handles incidents and separates fixes, support and new enhancements.

That is a handover objective. Access, repositories, procedures and key decisions should enable a reasonable transition without artificial dependency.

They enter a backlog with impact and priority. The team decides whether they replace an item, wait for a later phase or require additional budget.

Depending on the engagement: source code, configuration, agreed access, documentation, deployment procedure, initial backups and open-item list.

No. We prefer one end-to-end flow — for example quote to invoice — then expansion after data and usage have stabilized.

Yes when the tools offer a reliable exchange through an API, structured files or a connector. We also define the source of truth and error handling.

We select useful data, clean the source, rehearse imports in staging and have users validate totals and scenarios.

When the workflow creates real value, cannot be covered properly by an existing product and the organization can own its ongoing evolution.

Yes after a discovery phase covering source code, dependencies, access, data, known incidents and deployment procedures. This determines the risk level.

Yes when standard features or configuration cannot cover the need cleanly. The module must remain testable, documented and compatible with the upgrade strategy.

Yes. We define the source of truth for products, prices, stock, orders, payments and returns, then add monitoring and error replay.

The choice depends on the product and operating model. The team works with PHP, Python, JavaScript and API architectures, favoring a stack the client can maintain.

Yes when the mobile context justifies it. Scoping first checks offline use, camera, location, notifications and store publishing.

Review, risk-based tests, dependency analysis, staging and reproducible deployment form the baseline. Exact controls depend on the product.

Yes if interfaces, data and responsibilities were designed for evolution. We favor a stable core followed by usage-led extensions.

We compare business fit, total cost, upgradeability and usage frequency. Custom development is selected only when its value exceeds its maintenance cost.

Scope may include inventory, monitoring, patches, backups, certificates, incident procedures and capacity review. Exact responsibilities are written into the agreement.

No. It applies to critical environments covered by an appropriate managed-service agreement. Thresholds, channels and response times are agreed for each scope.

We monitor executions and schedule restoration tests. A backup without recovery testing is an assumption, not a guarantee.

Scope and testing are adapted to the environment. Potentially disruptive checks are scheduled, isolated or performed in staging with prior agreement.

By affected asset, exposure, exploitability and business impact. Each item receives an action, owner and evidence of closure.

Yes within a defined managed-services scope. Inventory, patches, capacity, logs, secrets and deployment procedures are documented.

It depends on architecture, dependencies and contract. A target is credible only with measurement, suitable redundancy, incident procedures and explicit exclusions.

Yes after inventorying workloads, dependencies, volumes, security needs and the cutover window. A rollback strategy accompanies the migration.

Resources are allocated to services or environments, then tracked with budgets, thresholds and usage reviews. Optimization must not damage service levels.

Yes for systems that require it. It rehearses migrations, configuration and deployment with protected data before production is affected.

Named accounts, least privilege, MFA where available, secret storage and regular review form the baseline. Emergency access is logged.

Yes, provided application, system, hosting and client responsibilities are clearly separated. This speeds up incident diagnosis.

We define important actions — enquiry, call, quote or purchase — and track their source. Speed, comprehension and editorial autonomy complete the picture.

No. It earns its place through field use, offline access, notifications or frequent use. Otherwise a mobile web experience may be simpler to maintain.

A frequent, measurable and stable-enough task, often involving documents, classification or search. Exceptions need a route to human review.

No. A rule or conventional integration is usually cheaper and more predictable. AI is selected when it adds a genuinely necessary capability.

Yes. We organize handover by role: users, administrators, technical team or the next service provider.

Yes when sources, limits and escalation are defined. The pilot measures accuracy, time saved and cases requiring human takeover.

Yes with limited permissions and logged actions. We separate reading, proposing and irreversible actions to retain control.

The flow is mapped before integration: data categories, purpose, provider, retention, access and anonymization or deletion method.

Yes when each metric maps to a decision, reliable source and useful frequency. We avoid decorative dashboards with no owner or action.

Forms, campaign sources, consent and next actions feed a tracked journey. Duplicate and error handling are part of the integration.

Technical foundations, structure, redirects and measurement are included in the agreed scope. Editorial production and ongoing work are priced separately when needed.

Yes, often using extraction, rules and human review. The system must signal uncertainty and retain the original document for verification.