■ SERVICES · ODOO ERP DEVELOPMENT
Custom Odoo development for workflows the standard setup cannot cover.
Tijara Tech designs and develops approved Odoo modules, extensions, interfaces, reports and integrations around clearly defined operational requirements.
Discuss Your Odoo Requirement
See What Can Be Developed →
↻A workflow you depend on is handled outside Odoo in a spreadsheet.
⚠An earlier customisation blocks upgrades and nobody documented it.
?It is unclear whether the requirement is configuration or development.
✕Reports do not show what the operation actually needs to see.
05 · TECHNICAL APPROACH · Illustrative extension-development architecture
01Business requirementWRITTEN
02Functional specificationAPPROVED
03Module / extension buildIN BUILD
04Technical reviewDEPENDENCIES
05Test environmentSEPARATE ENV
06AcceptanceCLIENT SIGN-OFF
07Controlled releaseTIMING AGREED
SUPPORTING LAYERS
ODOO STANDARD APPSCUSTOM MODULEEXTERNAL APIREPORTING / PORTALROLE + ACCESS RULES
CONCEPT · EXTENSION PATTERNS PREFERRED OVER CORE MODIFICATION
■ 02 · OVERVIEW — CONFIGURATION OR DEVELOPMENT
Configuration, or genuine development?
Development starts only once the requirement, environment and acceptance conditions are written down. These questions decide the route.
Which existing Odoo workflow needs to change?
Is the requirement configuration or custom development?
Which Odoo version and applications are involved?
Is the environment Community, Enterprise or externally hosted?
Which user roles are affected?
Does the requirement involve external APIs?
What existing custom modules must be considered?
What are the acceptance conditions?
How will future upgrades affect the customization?
■ 03 · SCOPE
What can be developed.
Configuration is preferred over customisation wherever it is practical. Upgrade impact is reviewed during scope.
FUNCTIONAL DEVELOPMENT
Custom modules
Workflow extensions
Forms and views
Approval logic
Business rules
Scheduled actions
INTERFACES & REPORTING
Reports and operational dashboards
Customer or supplier portals
External API integrations
Data validation
Access and role behavior
ENVIRONMENT & RELEASE
Existing module review
Upgrade-impact assessment
Testing and release support
■ 04 · DEVELOPMENT PROCESS
Six stages, responsibilities on both sides.
The exact process, deliverables and timeline depend on the project scope.
01
Discover
Understand the operation before proposing a configuration.
Activities: Process review, system inventory, constraints, problem definition.
You provide: Process owners, current documentation, access to review sessions.
→ Workflow and requirement summary
02
Scope
Agree what will be delivered — and what will not.
Activities: Application selection, assumptions, milestones, acceptance expectations.
You provide: Priorities, budget owner decisions, written sign-off.
→ Scope and implementation plan
GATE — CLIENT SIGN-OFF
03
Design & validate
Test the approach before committing to the full build.
Activities: Target workflow mapping, key screens, integration feasibility.
You provide: Review sessions, confirmation of the validated approach.
→ Workflow prototype or blueprint
CONFIRM — APPROACH APPROVED
04
Build & integrate
Configure, develop and connect the working solution.
Activities: Module configuration, approved development, API connections, testing.
You provide: Data extracts, provider access, test participation.
→ Working modules and integrations
05
Launch & enable
Introduce the solution in controlled stages.
Activities: Data preparation, release checks, role-based training, cutover.
You provide: Nominated test users, go-live confirmation, training attendance.
→ Launch and enablement plan
GATE — GO-LIVE CONFIRMATION
06
Support & improve
Support the system in real operation.
Activities: Issue triage, operational feedback review, improvement prioritisation.
You provide: Reported issues, prioritisation decisions.
→ Support process and backlog
Development principles.
✓Configuration before customization where practical
✓Written requirements before development
✓Extension patterns instead of unnecessary core modifications
✓Version and dependency review
✓Test environment before release
✓Acceptance criteria
✓Documentation and handover
✓Upgrade impact considered during scope
■ 06 · DELIVERABLES
Who does what, written down before build.
TIJARA TECH DELIVERS · MAY INCLUDE
→ Requirement specification
→ Functional design
→ Technical design
→ Custom module or approved extension
→ Integration endpoints
→ Test scenarios
→ Acceptance checklist
→ Deployment notes
→ User or administrator guidance
→ Known limitations
→ Support scope
CLIENT PROVIDES
✓ Confirm business rules
✓ Provide access to the correct environment
✓ Identify affected users
✓ Review prototypes or test builds
✓ Provide realistic test data
✓ Complete acceptance review
✓ Approve release timing
■ 08 · RELEASE & UPGRADE CONSIDERATIONS
Testing, release and upgrade considerations.
Test environment first
Changes are built and reviewed in a test environment before any release to the working system.
Acceptance criteria
Agreed before development starts, and signed off against the built functionality rather than a demo.
Controlled release
Deployment notes, timing approved by you, and a defined fallback where the environment allows one.
Upgrade impact
Reviewed during scope. Customisation cannot be guaranteed compatible with every future Odoo release.
Documentation and handover
Technical notes, administrator guidance and a written list of known limitations.
Support scope
What is covered after release is agreed in writing — not open-ended.
■ 09 · FAQ
Odoo ERP Development questions.
Can you develop custom Odoo modules?
−
Yes. Modules and extensions are built against a written requirement and functional design, using extension patterns rather than unnecessary core changes.
Can you modify an existing custom module?
−
Usually — after reviewing its code, dependencies and Odoo version. The review determines whether modification or replacement is the safer route.
Can you connect Odoo to an external API?
−
Where the provider exposes a usable and documented API. Feasibility and authentication requirements are assessed before scope is fixed.
Do you customize reports and dashboards?
−
Yes — operational reports, views and dashboards are a common part of development scope.
How do you decide between configuration and development?
−
Configuration is preferred wherever it meets the requirement. Development is proposed only when configuration cannot cover the workflow.
Can custom development affect future upgrades?
−
It can. Upgrade impact is assessed during scope and recorded in known limitations. No customisation can be promised compatible with every future release.
Do you test changes before deployment?
−
Yes — test scenarios in a separate environment, followed by your acceptance review before release.
Can you work with an existing Odoo environment?
−
Yes. We review version, hosting, applications and existing customisations first, then recommend the correct service route.
What information is needed before development begins?
−
The affected workflow, environment details, user roles, acceptance conditions and any existing custom modules.
All questions and answers are present at every breakpoint. Triggers are 48px buttons with aria-expanded and aria-controls; the −/+ indicator carries state alongside colour. Shown expanded so the full answer set is visible in a static export.
