Service Applications & integration
Cloud business systems, centralised records and the integrations that keep them true
Most companies do not have a software problem; they have a copy-and-paste problem. Sales says one number, finance says another, stock says a third, and three people reconcile them in a spreadsheet every Friday. We put the system of record in place — Odoo, a custom application or the platform you already own — then build the connections that keep it accurate without effort.
1 · What we build and run
| Service | Typical scope | Who signs it off |
|---|---|---|
| Business platforms | Odoo and comparable systems: finance, sales, CRM, inventory, purchasing, projects, helpdesk, portal | Finance and operations leadership |
| Custom applications | Client portals, pricing and quoting tools, internal dashboards, workflow and approval systems | Product or process owner |
| Integrations | REST APIs, webhooks, file exchange, payment and logistics providers, marketplaces, banking files | IT and the owning department |
| Reporting | Management reporting from one source, scheduled statements, board-ready exports | Finance |
| Platform operation | Hosting, environments, releases, monitoring, backups, upgrade planning | IT or the retained technical supplier |
2 · Odoo implementation and support
Odoo is a serious choice for a company that wants one system of record without an enterprise price structure — and a disappointing one when it is installed as if it were a theme. We treat it as a business project with a technical tail: process first, configuration second, customisation only where the standard application genuinely stops.
- Modules — accounting and invoicing, sales and CRM, inventory and purchasing, manufacturing basics, projects and timesheets, helpdesk, website and portal, subscription and multi-company structures where the group needs them.
- Hosting — on our managed platform, on the client's own cloud, or on Odoo's infrastructure with us responsible for configuration, integrations and upgrades. All three are honest arrangements; the choice is stated in the proposal.
- Localisation and documents — chart of accounts, tax treatment, invoice layouts, Arabic and English documents, and fiscal or e-invoicing interfaces scoped with the client's compliance adviser.
- Studio work — fields, views and reports where they help, with every deviation from standard documented so a future upgrade is not a surprise.
- Long-run care — version planning, sandbox testing, user administration, training refreshers and a written note after each release.
3 · Custom business applications
When no package holds the process, we build the application — and then we operate it, because software without an owner quietly becomes someone's problem. Typical stacks are PHP and Laravel, Node.js and TypeScript, Python for data work, PostgreSQL or MySQL for state, and a plain server-rendered front end unless the interface genuinely needs a rich client.
The brief is written as a process description, not a feature list: who does what, in which order, and what happens when the answer is no. That is where the cost saving usually appears — most requested features turn out to be a checkbox on a step somebody already performs.
4 · API and systems integration
Integration is where projects either pay back or quietly fail. We build and then keep alive:
- REST and JSON interfaces, plus XML, CSV and fixed-width files where the other system is older than its marketing page.
- Inbound and outbound webhooks with retry, idempotency keys and a dead-letter queue an operator can read.
- Payment gateways, logistics and courier APIs, marketplaces, advertising platforms, banking and card acquirer files.
- Identity and access: single sign-on, directory synchronisation, and a defensible answer to "who still has an account?".
- Monitoring that shows which flow stopped, when, and how many records are affected — not just that a server is up.
Every interface is documented with its contract, its failure modes and its owner. Undocumented integrations are technical debt with a delivery date attached.
5 · Centralising records and identity
One customer, one product, one invoice, one set of terms — defined once and referenced everywhere else. Centralisation work usually means choosing the system that owns each object, then making the others read from it. It is unglamorous and it is the part that changes how a company feels to run.
6 · Method: discovery to hypercare
- Discovery — walk the real process with the people who perform it; record exceptions, because exceptions are where implementations die.
- Design and fixed scope — a written specification, a module or feature list, a data plan, an interface list and a decision log. Sign-off is by a named person with authority.
- Build in a sandbox — configuration first, development second, with a demo cadence so nobody sees the system for the first time in week nine.
- Data migration rehearsals — at least twice before cutover, with counts and control totals reconciled rather than eyeballed.
- Training and user acceptance — short role-based sessions and a scripted test set the department signs.
- Go-live and hypercare — a defined window with daily review, then hand-over to the managed service.
7 · Migration, cleansing and validation
Legacy data is never as tidy as the export suggests. We profile it, deduplicate it, fix references, and tell you what we are deleting instead of importing it silently into a new system. Migration reports are kept: rows read, rows written, rows rejected and why.
8 · Environments, releases and change control
Development, staging and production are separated as standard. Changes move through version control, are reviewed, and are applied by a documented release rather than by an editor open against a live system. Rollback is tested at least once, because an untested rollback is a rumour.
9 · Where the system runs
Application hosting sits on the group's own platform — virtual and dedicated servers with backups, monitoring and a named operator — or inside your existing cloud account, with the responsibility split written down. Databases are sized against real query behaviour, and capacity reviews are scheduled rather than triggered by an incident.
10 · Support, service levels and ownership
After go-live the question is not whether somebody will answer, but who. Each service carries a named contact, a published escalation route, an agreed support window and a monthly or quarterly review of incidents, changes and spend. Availability targets, response times and security obligations are defined in the contract for your system — they differ between an internal quoting tool and a customer-facing portal, and we would rather write the right number than publish a decorative one.
Source code, configuration exports, documentation and data remain the client's. A hand-over pack is maintained continuously so that leaving is possible, which is precisely why most clients do not need to.
11 · Questions teams ask first
- Do we have to replace the tools we already use?
- No. Some engagements consolidate several systems into one platform and some keep the existing stack and connect it properly. We recommend the option that survives a review of your actual process, and we say plainly when a replacement would cost more than it returns.
- Who owns the code, the data and the configuration?
- You do. Source code produced for you is assigned or licensed as the contract provides, configuration is exported and documented, and data remains yours to take at any time in a structured format. No engagement is designed to make leaving difficult.
- Can you work alongside our existing developer or integrator?
- Yes. We frequently take the hosting, release and support side of a build made elsewhere, or act as the technical supplier behind another organisation's contract. Roles are written down at the start so nobody discovers an overlap in production.
- How are upgrades handled on a managed platform?
- A staging copy is upgraded first, the client validates the affected flows, and production is changed inside an agreed window with a tested rollback. Major-version upgrades are planned work with a written scope, not an event that happens to you.
12 · Related services
Correspondence
Describe the process, not the software you think it needs.
Tell us what happens today from order to payment, where it stalls and what has already been tried. You will get a written approach, a phased scope and an honest note on what should be configured rather than built.