Where the product stops, we start.
Custom modules, REST APIs and field apps for the processes no standard system covers. Built for Saudi operations, in Arabic and English.
Software written for one company. Yours.
This volume is the detail behind one line in the capabilities book: what we build when a standard product runs out of road.
Why customisation
The process that makes you money is the one nobody sells.
Standard software is built for the average of a thousand companies. It handles the parts of your business that look like everyone else's, and quietly ignores the parts that do not.
The step the system cannot do gets done beside it, and the two disagree by the end of the month.
One person knows the real rule. When they are on leave, the rule is guessed at.
If the approval happened over WhatsApp, there is no record of who agreed to what, or when.
What is not in the system is not in the report, so management never sees the cost of it.
- —An approval chain that currently runs on email and memory
- —A costing or margin rule the standard product cannot express
- —A field team reporting work by phone call and photograph
- —A report somebody rebuilds by hand every month
Not a new system. A module inside the one you already run, sharing its database, its permissions and its audit trail. Your team learns nothing new; the process simply stops being manual.
Written, not configured
Thirty-five modules. Thirty-eight thousand lines.
These are modules our team wrote, not community add-ons we installed. The ten largest, with their real line counts:
Line counts are Python, XML and JavaScript in each module, counted from source. Twenty-five further in-house modules cover access control, document handling, approvals on purchasing, and Saudi localisation.
Governance without friction
Control that does not slow the business down.
- —Purchase, discount, expense and contract approval chains
- —Thresholds by amount, department or product category
- —Escalation and delegation when approvers are away
- —Every decision timestamped, giving a free audit trail
- —Approvals that reach people where they already are
Two modules, one idea: multi_level_approval routes by rule; sales_approval_workflow lets the rules themselves be configured without code.
Know the margin before you quote
The quote leaves. Do you know what it costs?
Most systems tell you the margin after the invoice. By then the price is agreed and the loss is booked. We build the costing in at the quotation line, where the decision is still open.
- —Cost breakdown captured per quotation line, not per invoice
- —Margin computed live as the line is edited
- —Approval triggered automatically when margin falls below policy
- —Purchase orders generated from the approved costing
- —Internal cost never printed on the customer document
Why it matters: the salesperson finds out the deal is thin while they can still change it, not at month end when finance does.
Attribution that survives an argument
Who actually won this deal?
Commission disputes are rarely about arithmetic. They are about attribution: the inquiry came from a referral, the meeting was someone else's, the order arrived through a third person. If the system does not record that chain, the argument happens every quarter.
- —sale_commission_engine — source tracking and configurable rates
- —partner_profit_share — per-job distribution for partnerships
- —Reproducible calculations with a full history
- —Reporting that both finance and the salesperson can read
Where a business shares profit per job rather than paying commission per sale, the same principle applies: the split is computed from the job's real numbers and recorded against it, so partners see the same figure the accounts do.
The vertical we know best
From the contract to the technician's hand.
Service businesses lose money in the gaps: the visit that was never scheduled, the part fitted but not billed, the contract that lapsed unnoticed. We built the whole chain as one system.
- —Service contracts with covered equipment and entitlements
- —Automatically generated preventive-maintenance visits
- —Renewal reminders raised before expiry, not after
- —A service dashboard showing profitability per contract
The job-management module alone runs to 6,785 lines: configurable checklist templates, per-item evidence, technician and customer signatures, parts consumption feeding costing, and reporting management can act on.
Built for people who never sit down
The job card, in a pocket.
- —GPS check-in and check-out with time on site recorded
- —Configurable checklists: pass/fail, readings, photos per item
- —Technician and customer signatures captured on the screen
- —Parts and materials picked on site, feeding the costing
- —Offline queue that syncs automatically when coverage returns
- —Push notifications and the day's jobs on opening
- —Full Arabic and English interface, following the device
Honest scope: the app ships on Android today. iOS is a build target, not a claim — we will say so before you ask.
Documented, versioned, tested
An interface the next system can build on.
The app is only half of it. Underneath sits a REST layer with twenty-four documented endpoints, its own test suite, and versioned migrations — so it can be extended later without guesswork.
- —Token authentication with secure device storage
- —An automated test suite covering the surface
- —Versioned migration scripts for schema changes
- —Documentation written for whoever comes next
Plenty of integrations are a script somebody wrote once. A tested, versioned API is a contract: it survives an upgrade, it can be handed to another team, and it does not silently change shape.
The numbers, without asking for them
Management reporting that nobody assembles.
- —Conversion, receivables, margin and pipeline in one view
- —Every figure clickable back to the records behind it
- —Role-aware: people see what their permissions allow
- —Service profitability per contract, not just per invoice
- —Built into the system, so it is never a separate export
Systems that were never meant to talk
Most of the work is between the products.
Nobody buys an integration. They buy two systems and then discover the gap. That gap is where a surprising share of our work lives.
Moving off software that has stopped serving you
"We'll lose our history" is the fear that keeps companies stuck.
It is a reasonable fear and usually an unnecessary one. If the data can be read, it can be moved — and the moving is a discipline, not an act of courage.
- —Back up before any write, without exception
- —Dry run, verify, then commit — never the reverse
- —External IDs so imports are safely repeatable
- —A written decision log, so choices can be revisited
- —Reconcile the ledger against the source before go-live
A Jeddah automotive workshop moved off a legacy garage system onto current-generation ERP: 63 customers, 73 vehicles with their identifiers and owners, and 277 products across parts and labour — plus every historical job card. Six defects in the underlying vertical module were found and fixed on the way, each verified failing before and passing after.
The worst day
If your restore has never been rehearsed, you have a hope.
Most companies discover the true state of their backups on the day they need them. We have been called in on that day, and we design so that it does not arrive.
- —Assess what survives: database, files, backup sets, replicas
- —Recover to a clean environment, never over the damage
- —Validate the restored data before it returns to use
- —Rebuild the environment and document what was done
- —Automated backups with off-site copies
- —Restore rehearsals — a backup is only proven by a restore
- —Documented recovery procedure, not tribal knowledge
- —Redundancy where the business genuinely needs it
- —Monitoring that tells you before the customer does
Western Star, UAE: complete production data loss with a corrupted backup set. Recovered and operational inside 24 hours; the relationship continued into new development afterwards.
Technomid
A service business, built module by module.
- ·Quotations priced without a visible cost breakdown
- ·Approvals agreed verbally, recorded nowhere
- ·Service contracts tracked in files; renewals slipped
- ·Field work reported by phone call and paper
- ·Field-service chain from contract to invoice
- ·Configurable approval workflows with audit trail
- ·Costing sheets and margin control at quotation line
- ·REST API and an Android app for technicians
- ·The margin is known before the quote is sent
- ·Approvals leave a record instead of a memory
- ·Technicians close jobs on site, with signatures
- ·Renewals surface themselves before they expire
Nothing here was bought as a package. Each module answered a bottleneck the business had actually hit, and was commissioned once the previous one was earning its keep.
Legacy system out. Nothing left behind.
- ·A legacy garage system running the workshop floor
- ·Accounts kept separately, reconciled by hand
- ·Years of customer, vehicle and job history locked inside it
- ·No integrated path to Phase 2 e-invoicing compliance
- ·Extraction and normalisation from the legacy system
- ·Idempotent import with external IDs, dry-run first
- ·Workshop vertical: job cards, vehicles, parts and labour
- ·Six defects found and fixed in the vertical module
- ·E-invoicing onboarding through to live production
- ·Workshop, accounts and reporting in one system
- ·A vehicle's full history opens in one click
- ·Invoices are cryptographically signed and reported
- ·The ledger was reconciled against source before go-live
The fear was losing the history. The result kept every record, and the discipline that made it safe — back up, dry run, verify, then commit — is the same on every migration we run.
Total data loss. Back inside 24 hours.
- ·Complete loss of production data
- ·The backup set was found corrupted
- ·Business operations stopped
- ·Recovered the database and rebuilt the environment
- ·Validated the restored data before returning it to use
- ·Established backup and disaster-recovery procedures
- ·Went on to build several custom applications
- ·Operations resumed the following day
- ·Recovery became a documented procedure
- ·The engagement continued into new development
We would rather be your migration team than your recovery team. But if the worst has already happened, the first hours decide how much survives.
Custom work, without an open cheque
Custom does not have to mean open-ended.
The reason custom software has a bad reputation is that it is usually sold by the hour, against a specification nobody finished writing. We scope and price each phase before it starts.
We sit with the people who do the work today and write down what actually happens, including the workaround nobody mentions in meetings.
You get a written specification and a fixed price for the phase. If the scope changes, the price changes with a new agreement, not a surprise invoice.
You see working software early and often, in your own data, so misunderstandings surface while they are still cheap.
Documented, versioned and installable by someone else. We would rather be kept than needed.
The source code, the documentation and the migrations. Written to the platform's own conventions, so any competent team can maintain it. No hidden runtime, no licence you did not agree to.
- —When a standard feature already does it — we will point you there
- —When the process should be fixed before it is automated
- —When the requirement is really a reporting problem
- —When nobody can tell us who decides the rule
The next step