MITHLAK

OUR PROCESS

A clear build begins before the build.

Good implementation depends on what happens before the first interface, prompt, or workflow node. We define the problem, people, information, decisions, boundaries, and useful first version before committing to the full build.

GUIDING PRINCIPLE

We do not automate confusion.

A weak process does not become stronger because it moves faster. A vague service does not become clearer because it has a beautiful website. A folder of conflicting files does not become reliable knowledge because it was uploaded to an assistant.

Our process makes those weaknesses visible early, when they are still less expensive to correct.

THE FIVE PHASES

Each phase has questions, activities, and a defined output.

01 · THE FIVE PHASES

Understand

Output

A shared problem statement and recommended next step.

Questions

  • What is happening now?
  • Who is involved?
  • What repeats?
  • Where is information lost?
  • What still depends on one person?
  • What outcome would be genuinely useful?

Activities

  • Initial brief
  • Fit review
  • Existing-material review
  • Stakeholder interview
  • Current-state map
  • Risk and data questions

02 · THE FIVE PHASES

Architect

Output

A defined architecture, scope, assumptions, exclusions, and implementation plan.

Questions

  • What is the smallest useful system?
  • What information is approved?
  • What are the user roles?
  • Which decisions may be automated?
  • Where is human approval required?
  • What belongs outside the first phase?

Activities

  • Future-state map
  • Information architecture
  • User journey
  • Data model
  • Knowledge structure
  • Feature prioritization
  • Integration plan
  • Acceptance criteria

03 · THE FIVE PHASES

Build

Output

A testable version of the agreed system.

Working rule

We build in accepted packets. Each packet has a purpose, boundaries, and review point.

Activities

  • Prototype
  • Content or knowledge preparation
  • Design-system application
  • Development or assistant configuration
  • Workflow implementation
  • Internal testing

04 · THE FIVE PHASES

Validate

Output

An issue register, corrections, and acceptance decision.

Activities

  • Normal use
  • Missing information
  • Incorrect input
  • Different users
  • Arabic and English
  • Mobile and desktop
  • Error states
  • Permissions
  • Human-review points
  • Out-of-scope behavior

05 · THE FIVE PHASES

Launch & Handover

Output

A usable system with clear ownership after delivery.

Activities

  • Final environment
  • Account ownership map
  • Documentation
  • User guide
  • Admin guide
  • Training
  • Backup or code handover
  • Support window
  • Known limitations
  • Phase-two recommendation

TIMELINES

The timeline follows the scope — not the service name.

A single focused assistant, a bilingual website, and a web-app MVP may all have different preparation, feedback, data, and testing needs. We provide a project timeline after the initial brief or paid discovery.

Timeline factors

  • Readiness of content and data
  • Number of stakeholders
  • Languages
  • Integrations
  • Review speed
  • Security requirements
  • Number of user roles
  • Migration work
  • Requested launch date

CLIENT RESPONSIBILITIES

A successful project requires the client to:

  • Assign a decision-maker.
  • Provide accurate information and approved sources.
  • Protect third-party and personal data.
  • Review within agreed periods.
  • Provide access to agreed tools.
  • Confirm legal or professional claims.
  • Separate new features from corrections.
  • Attend required training and acceptance sessions.

Start with the current process.

Tell us what happens today, who is involved, and what you want to make clearer, faster, or more consistent.

Describe your project