Skip to content
All solutions
// Solution

ERP software for procurement and operations

The systems an organisation actually runs on are rarely the exciting ones: purchase requests, approvals, stock movements, contracts, budgets and reconciliation. I build and implement those — Arabic-first, audit-ready, and designed for staff who will use them every day for years.

// Who this is for

Built for these situations

  • Organisations running procurement and inventory on Excel, email and paper approvals
  • Companies whose ERP was implemented but never adopted by the people who need it
  • Groups needing Arabic-first, RTL internal systems with real approval hierarchies
  • Teams evaluating ERPNext/Frappe and needing honest scoping plus customisation

Not a fit if

  • Organisations unwilling to document their current workflow before building
  • Anyone who wants a system that mirrors a broken process rather than fixing it
  • Teams with no internal owner to make approval-hierarchy decisions
// The problem

What usually goes wrong

01

Approvals live in email and paper

Nobody can say where a purchase request is, who approved it or why. Every escalation becomes an archaeology exercise across inboxes.

02

Stock on paper ≠ stock on the shelf

Receipts, issues, transfers and returns are recorded in different places at different times, so reconciliation is a monthly argument rather than a query.

03

Supplier pricing is opaque

Without a structured quotation and negotiation trail, the organisation cannot demonstrate it bought at a fair price — the exact problem the Ministry of Interior supply platform was built to solve.

04

The report is always late

When operational data is scattered, management reporting is assembled by hand — which means it is late, inconsistent and quietly distrusted.

// What gets built

What Makhloof Studio actually delivers

Procurement from request to receipt

Purchase requests, multi-vendor RFQ, offer comparison, negotiation history, purchase orders, goods receipt and invoice matching — each step with an owner, a timestamp and a reason.

Inventory and warehouses

Multi-warehouse stock, transfers, batch and serial tracking, stock-take workflows and archiving — modelled on how your storekeepers actually work, not on a textbook.

Contracts, budgets and finance

Contract registers with renewal and obligation tracking, budget lines with commitment control, and financial entries that reconcile against operations rather than beside them.

Roles, permissions and audit

Role-based access down to the field, delegation and acting-for rules, and an immutable activity log — the security-first layering used on the Ministry Improvement Fund platform.

// Scope

Typical modules

A realistic scope for this kind of build. Yours will be a subset — the first call is where we cut it down.

Procurement

  • Purchase requests with approval hierarchy
  • Multi-vendor RFQ and offer comparison
  • Negotiation and award trail
  • Purchase orders and amendments
  • Goods receipt and quality check
  • Three-way invoice matching

Inventory & assets

  • Multi-warehouse stock ledger
  • Transfers, issues and returns
  • Batch, serial and expiry tracking
  • Stock-take and adjustment workflows
  • Asset register and custody
  • Barcode-friendly operations

Governance & reporting

  • Role-based access and delegation
  • Immutable activity and audit log
  • Budget lines and commitment control
  • Contract register and renewals
  • Operational dashboards per department
  • Exportable statutory reports
// Delivery

How this gets built

  1. 01

    Document the current workflow

    We write down how a request moves today — including the informal steps. Most ERP failures are workflow failures discovered too late.

  2. 02

    Decide build vs ERPNext

    Standard finance, stock and purchasing are cheaper on ERPNext/Frappe. Genuinely unusual workflows are cheaper custom. You get a straight recommendation, not a preference.

  3. 03

    Roll out department by department

    One department goes live, is supported until it is genuinely used, then the next. Big-bang rollouts are how systems get rejected.

  4. 04

    Train, support, hand over

    Arabic training material, an in-system help path, and a support window while habits form. Adoption is the deliverable — not the go-live date.

Typical stack

ERPNextFrappePythonMariaDBNestJSPostgreSQLNext.js
// Fit

Worth knowing before you write.

A short, honest filter. It saves both of us a call that was never going to work.

A good fit if

  • You have a real business or a funded idea, and a decision-maker in the room
  • The product has to handle money, roles, or operations correctly — not just look good
  • You want one senior engineer accountable end to end, not a rotating team
  • Arabic and English both matter to your market
  • You can give a few hours a week to reviews and decisions

Not a fit if

  • You need a team of ten starting Monday — that is an agency's job, not mine
  • The budget is fixed before the scope exists and cannot move
  • You are looking for the cheapest possible quote rather than the right build
  • Nobody on your side can answer product questions within a few days
  • You want equity-only work or an unpaid prototype

What you get in the first call

Fifteen minutes, free, no deck.
  • A straight answer on whether this is buildable the way you imagine it
  • The two or three decisions that will drive most of your cost
  • A rough shape: phases, surfaces, and where the risk sits
  • An honest ballpark range — or a referral if I am not the right fit

What to prepare

None of it has to be polished.
  • One sentence on what the business does today
  • The workflow that hurts most, described in plain language
  • Who needs to log in, and what each of them does
  • Any deadline that is real, and why it is real
  • A budget range you are comfortable discussing openly
// Questions

Answered straight

Do you implement ERPNext or build from scratch?
Both, and the choice is made on your workflows, not on preference. ERPNext/Frappe covers standard finance, stock and purchasing well and cheaply; custom work earns its cost where the process is genuinely unusual — multi-vendor negotiation, government-specific approval chains, or an operating model no product models.
Is the system fully Arabic?
Yes — Arabic-first with full RTL layout, Arabic reports and Arabic training material. The Ministry of Interior supply platform referenced here runs Arabic-first for hundreds of daily users.
Can it integrate with our accounting system?
Yes. Integration is scoped explicitly — which entities sync, in which direction, and what happens on conflict. Undefined sync rules are the most common source of post-launch data problems.
What about the two government systems on this page?
Both are their companies' products and I worked on them as one engineer within a large delivery team — building features, maintaining them in production and supporting the offices that use them. That is stated on each case study, and it is why they are shown as domain proof rather than as solo work.
How do you avoid building a system nobody uses?
By documenting the real workflow first, rolling out department by department, and treating adoption — not go-live — as the finish line. If a department is not using it, the work is not done.
// Next step

Need an internal system like this?

Bring one workflow that hurts today — a purchase approval, a stock count, a monthly close. We'll map it on the first call.

WhatsApp