Custom development

Six lines of work

Most projects are one of these, or two of them joined together.

Business systems

Operational systems shaped to how your company works: registers, approvals, scheduling, service desks and the back-office tools that spreadsheets and email carry today. This includes moving spreadsheets, legacy software and paper processes onto one maintained system, with your history migrated.

Typical starting points
  • An approval flow with delegation limits that runs on email today
  • A register that three people edit in one spreadsheet
  • Legacy software whose supplier no longer supports it

Client and partner portals

Sign-in areas where customers, suppliers or partners see their own orders, documents, statements or requests, in Arabic and English, with access limited to their own records.

Typical starting points
  • Customers checking statements and raising a dispute
  • Suppliers submitting documents and invoices
  • Partners seeing their own holdings and decisions

Web and mobile apps

Customer-facing websites and apps for iOS, Android and the web, in Arabic and English from day one, right to left included.

Typical starting points
  • An ordering or booking app for customers
  • A field-staff app that works from a phone
  • A public website with a content team and an approval step
Web & mobile apps service

Integrations and APIs

Connect your ERP, payment, banking, time clocks and existing systems so data moves without re-keying.

Typical starting points
  • Time clocks feeding payroll
  • Two internal systems that need the same customer record
  • An ERP connected to e-invoicing requirements
ERP & e-invoicing integration

AI assistants and chatbots

Assistants grounded in your own documents and data, for customer service, staff questions and internal search, answering in Arabic and English.

Typical starting points
  • A customer-service assistant that answers from your policies
  • A staff assistant for leave, policy and access questions
  • Internal search across documents nobody can find
AI Assistants & Chatbots

Data and reporting

Management dashboards and reports drawn from the systems you already run, in the formats your board and auditors ask for.

Typical starting points
  • An operations dashboard drawn from three systems
  • A month-end pack that is assembled by hand today
  • Exports an auditor can open without asking us
Custom development

How a written proposal is structured

It is a document you can take to your own board, your finance team and your lawyers. Prices appear in the commercial schedule of the proposal, never on this website.

If a section is missing from a proposal you receive, ask for it.

  1. What we understood

    The situation and goals in your words, and the process as mapped in scoping.

  2. Itemised scope

    What is included, line by line, and what is explicitly not.

  3. Milestones and acceptance

    What you will be able to test at the end of each milestone, and how acceptance works.

  4. Timeline

    Dates tied to milestones, and to what we need from your side and when.

  5. Users, modules, data and hosting

    Who uses it, with which roles, what data is migrated, and where it runs.

  6. Ownership terms

    Who holds the custom software written for you, who holds the reusable components we bring, and what happens to your data.

  7. Support terms

    Support levels, response times, the update schedule and what is covered.

  8. Commercial schedule

    The itemised commercial terms by milestone. Nothing is charged until you approve the proposal.

Custom development

Hosting, ownership and engagement

Stated plainly, so you can ask the same questions of anyone else you are considering.

Hosting

Each deployment is its own. The proposal names where it runs and who operates it.

  • On servers in Saudi Arabia, run by MUZN IT
  • On your own servers
  • In a cloud region you choose

Ownership

Ownership terms are written into the proposal before work starts. Ask about three things.

  • The custom software written for you
  • The reusable components we bring to the project
  • Your data, and how it is exported if you leave

Engagement

A build is a fixed scope delivered in milestones, followed by a support agreement.

  • Scope and milestones are agreed before work starts
  • Nothing is charged until you approve the proposal
  • Support terms, response times and the update schedule are written into the agreement

When a product fits better

If one of our products covers most of what you need, we say so in scoping and quote that instead of a build. Custom development is for the part that no product covers. Hardware and IT services for the same project can be quoted with it.

See the products See the services

Custom development

Questions about custom builds

How long does a project take?

It depends on scope. The proposal gives a timeline tied to milestones and to what we need from your side. Scoping gives you the first view of it.

Can we see what the first release will contain?

Yes. The proposal itemises scope by milestone, so you can see what the first working release contains and decide on the rest with that in hand.

Will it work in Arabic and English?

Yes. Screens and documents are designed for both languages from the start, including right-to-left layouts.

Can you work with the systems we already have?

Integrations are one of the six lines of work. Tell us which systems are involved; compatibility is confirmed at scoping, before the proposal is written.

Can you take over a system someone else built?

Tell us what exists. We assess it during scoping before committing to anything, and the proposal says what we found.

Who supports it after go-live?

The same team that built it. Support levels, response times and update schedules are written into your agreement.

How do I see working software before I decide?

You can see our products with sample data in a demo. For a build, you see working software at every milestone.