Skip to main content
Custom software on demand

We customise when standard is not enough not because custom is easier to sell

We build custom systems and functions where packaged software cannot represent a rule or process you actually run: a specific approval cycle, compound pricing, an integration between two systems that cannot be replaced, or an extension of an existing one. In the analysis we tell you if standard software with configuration is enough for you — because custom code is a permanent maintenance cost, and when standard fits, it is the better answer for you even when it earns us less.

Request a needs analysisSee the delivery steps
  • We tell you if standard is enough
  • A written scope and acceptance criteria
  • Staged delivery, not one big drop
  • Code and documentation are yours
  • Handover to your team or another
Custom software
Temporary placeholder — slot for the needs and scope document

Direct answers

The questions asked first

When is custom development the right answer?

When standard software fails for a substantive reason rather than a cosmetic detail: a process or rule you run that packaged software cannot represent even with configuration, an integration between two systems that cannot be replaced, a legacy system that must stay and needs a bridge, or an operational function no package sells because it is specific to your field. If the difference is a form field, a report or a permission, then configuration or training beats code you maintain for years. The analysis tells you which case you have.

How are cost and duration estimated?

By scope rather than guesswork: after the needs analysis, the written scope and the acceptance criteria, we estimate the phases, durations and hours from written items rather than from “a complete application”. Change is handled through estimated change requests: anything added after the scope is approved is estimated and approved before it is built, so neither the invoice nor the schedule grows silently. We give no binding price before the analysis and no binding duration before the scope.

Who owns the code, and what if we stop or you move to another team?

The code is yours: delivered into your repository with clear branches, architectural documentation and an operations guide, and the build environment is pinned so another developer can run the project from the documentation without secret knowledge held by us. We hand over credentials and accounts, run a knowledge-transfer session, and stay available for the new team’s questions for an agreed period. We hold no code hostage and keep no undocumented knowledge that has no replacement.

How do you test, and how is delivery done?

With written acceptance criteria before development: every scope item has a testable acceptance case. We deliver in short cycles you can try on a separate test environment, run user acceptance testing with the people who actually do the work rather than management alone, and track defects to closure with a published list. An item is not finished because the code is written — it is finished when the acceptance criterion is verified with you.

Deliverables

What we deliver

Eight tangible outputs, each with a document or a system you can inspect — not a promise of a system nobody can run afterwards.

Needs analysis and a feasibility decision

What process or rule you actually need, why packaged software cannot cover it, and what the configuration alternative would be if it can — with a written recommendation.

Output: a written analysis and recommendation

A written scope and acceptance criteria

Numbered items, each with a testable acceptance case, and what is explicitly out of scope — before any estimate or code.

Output: a scope and acceptance criteria

Solution and architecture design

How the components are arranged, where data lives, how it connects to existing systems, and which constraints the design rests on.

Output: a documented architecture diagram

A proof of concept for the hardest part

We do not build everything only to discover the integration or performance does not work: we prove the hardest part first and show the result.

Output: a proven model of the hardest part

Build in short cycles

Incremental delivery you can try on a separate test environment, in organised code in your repository, with written change reviews.

Output: a testable build on a cadence

Testing, defect tracking and user acceptance

Testing with a published defect list and acceptance testing with the people who do the work; no item closes before its acceptance criterion is verified with you.

Output: a test report and a signed acceptance

A running environment and an operations guide

Deployment to the running environment you own, with an operations guide, backups and monitoring, and separate test and production environments.

Output: a running system with a clear guide

Handover, knowledge transfer and post-go-live support

Repository, documentation and credentials handed over, a knowledge-transfer session for your team or another, and an agreed support window for faults.

Output: a team able to run it without us

Delivery steps

The delivery steps: from need to operation

Eight steps, each with a published output, starting with the feasibility question — is custom the answer? — before any estimate or code.

  1. 01

    Needs and feasibility analysis

    Understanding the actual process and rule, verifying that standard software with configuration cannot cover it, and judging whether custom work justifies its permanent cost.

    Output: a recommendation — custom or configuration

  2. 02

    Scope and acceptance criteria

    Numbered items with an acceptance case each and an explicit out-of-scope list, then an estimate built on those items rather than on an impression.

    Output: an approved scope and estimate

  3. 03

    Design and architecture

    Component layout, data flow, integration interfaces and the permissions model, with the constraints the design rests on explained.

    Output: a documented architecture

  4. 04

    Proof of concept

    We prove the hardest part early — integration with a system we do not control, or performance under the expected load — before building the rest.

    Output: a proven result on a real environment

  5. 05

    Build in short cycles

    Building the scope items in cycles you can try, with written change reviews and estimated change requests for anything added after the scope.

    Output: a testable build on a cadence

  6. 06

    Testing and user acceptance

    Testing against the items and their acceptance criteria, defect tracking on a published list, and acceptance testing with the people who do the work rather than management alone.

    Output: a signed acceptance against the scope

  7. 07

    Handover and knowledge transfer

    Deployment to the running environment, handover of the repository, documentation and credentials, and a knowledge-transfer session that leaves your team able to operate it.

    Output: operation with no dependence on us

  8. 08

    Operation, maintenance and evolution

    Fault support, security updates and dependency upgrades, and a periodic review of what needs development — because custom code does not improve on its own.

    Output: an operations report and improvements

Measurement

What we measure during and after the project

Indicators read from the tracking system and the tests, not promised figures.

Acceptance criteria coverage

How many scope items had their acceptance criterion actually verified versus how many did not — the measure that reflects delivery rather than effort.

Open defects before handover

What remains open and how severe, because handing over with a published defect list is a decision rather than a surprise.

Automated tests

What is tested automatically on every change — the thing that makes later development safe rather than a risk each time.

Cycle time

From an item’s approval to it arriving testable, because long cycles delay feedback until correcting it becomes expensive.

Fault response time after go-live

From a confirmed fault report to its resolution, per the agreement — because a system’s value is measured by what happens when it breaks.

We guarantee no schedule and no final price before the analysis and the scope, and we announce no saving percentage and no guaranteed productivity. What we measure is delivery quality and how operable what we delivered is: acceptance coverage, defects before handover, automated tests, cycle time, and the response time for faults after go-live.

Where it fits

Where custom development fits

Not every business needs custom code; these are the cases where customising costs less than bending the business to fit a package.

A specific process or approval cycle

A compound approval cycle with levels and conditions no packaged system represents, part of which today runs on email or spreadsheets.

Compound pricing or commission

Pricing or commission rules with many conditions, or recurring billing with progress claims, that cannot be reduced to a ready price list.

Integration between two existing systems

Two systems that must stay and need a bridge that reads and writes between them with no double entry and no manual export each morning.

A legacy system that cannot be replaced

A system that works and holds value, needing a modern interface, reporting or an extension without disturbing its stability.

An operational tool specific to your field

A function no package sells because it is specific to how you work: resource scheduling, field task assignment, or computing structural indicators.

A customer or supplier portal

Authenticated access to view orders and documents and submit requests, without back-and-forth messaging or email attachments.

A regulatory requirement needing a record

A change log, permissions and approval trace that must be evidenced at audit — something a spreadsheet solution does not provide.

An Odoo user needing an extension

A function absent from the standard that can be built as a separate module upgraded with the system rather than patching the core.

Integration

Custom work lives between systems

What we are asked for most is not a new system but a bridge: reading and writing between two existing systems with no double entry.

Odoo (APIs and standard)

Reading and writing into Odoo through its official APIs, or a custom module upgraded with the system rather than patching the core.

The safe extension path

Existing databases

Connecting to an existing database for reading or writing, with a clear plan to avoid conflicting writes and their effect on the original system.

With a conflict-avoidance plan

Identity and single sign-on

Connecting sign-in to the company accounts (SSO) so the system shares the permissions of the rest, without separate passwords.

Unified permissions

Messaging and notifications

Email, SMS or in-system notifications, with sending limits and templates managed from settings rather than from code.

Templates without code

Payment gateways and external parties

Connecting a payment provider or a government service through its API, after inspecting availability and terms — we promise no integration before that check.

After the interface check

Scope

Engagement scopes

Described scope with no published prices: cost follows the number of items, acceptance criteria, integrations and environments, and is quoted after the analysis.

مدخل محدود

Analysis and proof of concept

Needs and feasibility analysis, a scope with acceptance criteria, and a proof of the hardest part on a real environment — for verifying before investing.

Before investing in the build

الأكثر طلبًا

One custom module or tool

A fully delivered scope: architecture design, build in cycles, testing and acceptance, deployment with an operations guide, knowledge transfer and post-go-live support.

From need to operation

نطاق ممتد

A multi-module system or a bridge between systems

Everything above with interconnected modules, several integrations, separate test and production environments, a data migration plan, and training for several teams.

Quoted after the analysis

We publish no price before the analysis: cost follows items, acceptance criteria, integrations, environments and migration volume.

FAQ

Questions asked before starting

Direct answers on feasibility, estimation, ownership and responsibility — without inflation.

When is custom development the right answer?

When standard software fails for a substantive reason rather than a cosmetic detail: a process or rule you run that packaged software cannot represent even with configuration, an integration between two systems that cannot be replaced, a legacy system that must stay and needs a bridge, or an operational function no package sells because it is specific to your field. If the difference is a form field, a report or a permission, then configuration or training beats code you maintain for years. The analysis tells you which case you have.

How are cost and duration estimated?

By scope rather than guesswork: after the needs analysis, the written scope and the acceptance criteria, we estimate the phases, durations and hours from written items rather than from “a complete application”. Change is handled through estimated change requests: anything added after the scope is approved is estimated and approved before it is built, so neither the invoice nor the schedule grows silently. We give no binding price before the analysis and no binding duration before the scope.

Who owns the code, and what if we stop or you move to another team?

The code is yours: delivered into your repository with clear branches, architectural documentation and an operations guide, and the build environment is pinned so another developer can run the project from the documentation without secret knowledge held by us. We hand over credentials and accounts, run a knowledge-transfer session, and stay available for the new team’s questions for an agreed period. We hold no code hostage and keep no undocumented knowledge that has no replacement.

How do you test, and how is delivery done?

With written acceptance criteria before development: every scope item has a testable acceptance case. We deliver in short cycles you can try on a separate test environment, run user acceptance testing with the people who actually do the work rather than management alone, and track defects to closure with a published list. An item is not finished because the code is written — it is finished when the acceptance criterion is verified with you.

Do you recommend customisation or configuration?

We recommend what serves you rather than what increases our hours: if the difference is a form, a report, a permission or the order of steps, then configuration, training or a small process change is cheaper over time than custom code that must be maintained at every upgrade. We write the recommendation in the analysis with its reason, and if you still decide to customise we estimate it honestly together with its long-term maintenance cost — not just the build cost.

What happens to the code if our contract with you ends?

The code and documentation are yours, delivered into your repository with an operations guide and credentials, so nothing prevents another team from continuing. We run a knowledge-transfer session and fix a question window for the new team in the contract. Without those terms customisation would not be a sound decision, because a system nobody can run without its vendor is a liability rather than an asset.

What is out of scope?

Running your legacy systems on your behalf, buying licences, services and hosting (contracted in your name), training end users on a process management has not yet endorsed, legal, tax or regulatory advice, and open-ended support with no time limit. Where buying a package is genuinely better than building, we say so plainly rather than building it to bill it.

Request a needs analysis

Four details are enough: the process or rule you need, the systems it must integrate with, who will use it (internal team or customers), and whether existing data must be migrated.

  • A written analysis saying whether custom is necessary
  • Code and documentation are yours, with no tie to us
  • Scope and acceptance criteria before any commitment
Services needed

By submitting you agree that we may contact you about your request. We do not share your data with third parties.

Do you have a process no packaged system represents?

Tell us the process, the rule you need and the systems it must work with, and we will come back with an analysis that says plainly: custom, configuration, or neither.

Request a proposal

Related topics

We are a systems implementation and development company — not a certification body and not a law firm. We provide engineering analysis and a recommendation; the decision on scope and budget is the client’s. The code and the documentation belong to the client with no tie to us, and on request we hand over everything needed to run it or pass it to another team. We guarantee no final price and no binding schedule before the analysis and the written scope, announce no saving percentage or guaranteed productivity, and use your data for nothing else.

Or contact us directly