Choosing Between Custom Builds and Odoo: A Strategic Framework

The build-vs-buy question is the oldest argument in software operations, and it is also the one most reliably answered incorrectly. Not because operators are careless — because the question is almost always framed wrong. Teams ask "should we build custom or use Odoo?" when the correct question is "which parts of our system are the product, and which parts are the plumbing?" Those are not the same question. One produces a binary decision that gets revisited painfully eighteen months later. The other produces an architecture where the right tool occupies the right layer from day one.

This post synthesizes the field intelligence from r/CRMSoftware, r/Odoo, r/EcommerceWebsite, and adjacent communities — operators who made this decision, lived with it, and reported back. What emerges is not a checklist. It is a decision framework with a single governing principle, a set of practical tests that apply it to your specific situation, and a hybrid architecture pattern that the most experienced operators have converged on across every vertical: healthcare, professional services, SaaS, and marketplace businesses.

The framework works because it is not ideological about either option. Odoo is not the enemy of good engineering. Custom builds are not automatically superior. The failure in most implementations is not the tool choice — it is applying the wrong tool to the wrong layer of the system. That failure is entirely avoidable. This post shows you exactly where the line is.

The One Rule That Governs the Entire Decision

Before the framework, before the decision matrix, before the POC recommendations — there is one principle that the Reddit corpus converges on with unusual consistency. Operators who got this decision right, regardless of the vertical they were in or the complexity of their system, can all be traced back to a single architectural judgment that they made correctly at the start:

If the matching algorithm is the product, build custom for that part. If the matching algorithm is infrastructure that supports the product, buy it.

The emphasis is on the phrase "is the product." Not "is important." Not "is complex." Not "is core to operations." Every software business has components that are operationally critical — without a working payments layer, the business stops. Without a functional CRM, the sales team cannot operate. But critical is not the same as differentiating. Stripe is critical. Nobody builds a custom payment infrastructure because Stripe is critical. They buy Stripe because payments are not their product — and they build custom for the piece that is.

The decision engine — the weighted ranking system, the constraint logic, the feedback loop that improves matching over time — is where most of the businesses described in the community corpus are facing this question. And the community consensus is unambiguous: constraint-based decision logic, especially when it involves timezone-aware scheduling, capacity limits, conflict detection, and evolving feedback loops, is genuinely custom territory. Not because Odoo cannot model it at all — because fighting Odoo's data model to force constraint logic into a system not designed for it creates maintenance overhead that compounds with every iteration cycle.

"Think of it like payments. Would you build the payment infrastructure yourself or would you use Stripe? Buy what doesn't make you different. Build what does." r/CRMSoftware — Senior operator, marketplace software build thread

The corollary is equally important: the operational layer — CRM records, invoicing, messaging, payment collection, scheduling around the core engine — is infrastructure, not product. It is the plumbing that allows the product to reach users. Building custom plumbing when Odoo, Zoho, or HubSpot already does it correctly is not an investment in your product. It is an investment in reinventing infrastructure that commodity platforms have spent ten years optimizing. The hours spent building a custom invoicing module are hours not spent improving the matching algorithm that actually differentiates your business.

When Odoo Wins — The Three Conditions Where It Is the Right Call

Odoo is a genuinely capable platform for a specific set of operational jobs. The operators who are running it successfully are not using it despite its constraints — they are operating within the design assumptions it was built around. Understanding those assumptions is what makes Odoo a competitive advantage in the right hands and a source of compounding friction in the wrong architecture.

Condition One: The Matching Logic Is Not the Core IP

The clearest signal that Odoo is the correct choice is when the differentiating logic of your business lives at a layer above what the CRM, invoicing, or workflow engine needs to know about. A professional services firm that matches consultants to client engagements based on availability and invoice terms is running a business where the matching is important — but the matching criteria are simple enough (availability, rate, skill tag) that Odoo's relational data model can represent them without constraint fighting. The product is the consulting engagement, not the matching algorithm. Odoo handles the CRM, the project record, the invoice, and the client communication. The "matching" is a filtered view in a module, not a weighted decision engine with feedback loops.

The healthcare mentor/mentee matching case documented in the community is instructive here. A team built a mentor matching process on top of Zoho — a comparable platform to Odoo in terms of operational capability — and was live in five weeks. The matching criteria were structured enough (specialty, availability window, geography) that the platform's filtering and assignment logic was sufficient. The core product was the mentorship program itself, not the matching algorithm. The right tool occupied the right layer. Five weeks to live is the operational return on that architectural decision.

Condition Two: You Need an MVP Live Before You Have Validated the Matching Criteria

The second condition where Odoo is clearly the right call is when you have not yet validated whether your matching criteria even matter to real users. Building a custom decision engine before you know which signals your matching algorithm should weight is the software equivalent of building a Formula 1 engine before you have confirmed there is a race track. The engine may be technically impressive. It will definitely be expensive. And when user testing reveals that the matching criteria you encoded in the custom engine are wrong — which they almost always are on first build — the cost of rebuilding is proportional to how deeply the criteria are embedded in the custom code.

Odoo, in this context, is a constraint. That constraint is also its advantage. When you are forced to represent matching logic as Odoo module configurations rather than arbitrary code, the criteria you model are the criteria that are simple enough to configure without custom development. If you can represent your MVP matching logic as Odoo field filters and assignment rules, you have implicitly validated that the logic is not yet complex enough to require custom engineering. The custom build decision should come after this validation, not before it.

Condition Three: The Operational Layer Is the Revenue Driver

The third condition where Odoo clearly wins is when the revenue-generating activities of the business — client onboarding, project delivery, invoicing, support — are the primary operational surface, and the matching or decision logic is a supporting function rather than the product core. A managed service business that uses a matching algorithm to assign account managers to clients is not in the matching business. The matching is an efficiency optimization in an operational process that is already generating revenue without it. Odoo's CRM, invoicing, and project management modules directly serve the revenue-generating surface. The matching optimization can be added as a module layer without requiring the operational layer to be rebuilt around it.

When Custom Wins — The Three Signals That Make the Decision Unambiguous

The custom build decision is frequently made for the wrong reasons — and frequently avoided for the wrong reasons. Teams build custom because they want control, or because the CTO believes the platform will limit them eventually, or because a competitor built custom and appears to be winning. These are not good reasons to build custom. The good reasons are more specific, more testable, and more directly tied to the architectural principle stated at the start of this post.

Signal One: The Decision Engine Has Constraint Logic That Cannot Be Expressed as Platform Configuration

Weighted ranking across multiple criteria. Timezone-aware scheduling with capacity constraints. Conflict detection that resolves across competing claims on the same resource. Feedback loops that adjust matching weights based on historical outcome quality. These are not features you configure in an Odoo module. They are algorithms that require a compute environment, a data model designed around the decision problem, and an iteration cycle that does not pass through a platform's change management constraints every time a weight changes.

The community formulation is exact: "Traditional business platforms (including Odoo) tend to work well for workflows, but they struggle when the core of the system is constraint-based decision logic." The struggle is not theoretical. It manifests as specific engineering problems: the Odoo data model does not naturally represent weighted scores as first-class fields that drive routing logic. The Odoo workflow engine does not natively support multi-constraint satisfaction problems. Every attempt to encode constraint logic into Odoo's model creates workarounds — computed fields that should be API responses, scheduled actions that should be event-driven triggers, Python overrides that accumulate as technical debt in the module layer.

DECISION ENGINE COMPLEXITY SPECTRUM
──────────────────────────────────────────────────────────────────

ODOO HANDLES NATIVELY ←───────────────────────────→ REQUIRES CUSTOM

SIMPLE ASSIGNMENT:                    WEIGHTED RANKING:
"Assign lead to AE                    "Score each candidate
 with lowest open                      across 7 criteria with
 deal count"                           dynamic weights based
                                       on historical close rate"
AVAILABILITY CHECK:                   CONSTRAINT SATISFACTION:
"Schedule when                        "Schedule across timezone
 calendar slot is                      constraints, capacity
 available"                            limits, conflict detection,
                                       and preference weighting
                                       simultaneously"
TAG-BASED ROUTING:                    FEEDBACK LOOP OPTIMIZATION:
"Route to team                        "Adjust matching weights
 based on industry                     weekly based on outcome
 field value"                          quality signals from
                                       completed matches"

STATIC RULE EXECUTION:               EVOLVING LOGIC ITERATION:
"If field A = X,                     "Logic changes as we learn —
 set field B = Y"                      need to iterate without
                                       fighting platform model"

──────────────────────────────────────────────────────────────────

DIAGNOSTIC: Where does your decision engine sit on this spectrum?
→ Left half: Odoo can handle it. Validate with a module POC.
→ Right half: Build custom. Keep Odoo for the operational layer only.

Signal Two: The Matching Logic Will Evolve Faster Than a Platform Can Accommodate

The second clear signal for custom build is iteration velocity. If the matching criteria are expected to change frequently — because you are learning from user feedback, because the market is shifting your understanding of what good matching looks like, because regulatory changes require algorithm updates — the cost of each change in a platform-embedded system is significantly higher than in a standalone custom service.

Platform-embedded logic changes require module updates, regression testing across the full Odoo module stack, and — in cases where the logic is encoded as computed fields or Python overrides — careful management of upgrade compatibility. Each change is a maintenance event with scope beyond the logic change itself. In a standalone custom matching service with a clean API, a logic change is a function update, a unit test run, and a deployment. The iteration velocity difference is not marginal. It is typically a 5x to 10x difference in change cycle time, and that difference compounds across every iteration in the product development timeline.

Signal Three: The Decision Engine Is the Differentiation That Justifies the Business Model

The third signal is the cleanest: if you cannot describe what makes your matching better than a human doing it manually without describing the algorithm, the algorithm is the product. This is the test that separates a business whose core IP is a decision engine from a business that uses a decision engine as an operational tool. Marketplace businesses, talent matching platforms, algorithmic pricing engines, and recommendation systems all pass this test. Their defensibility is the algorithm. The CRM and invoicing are delivery infrastructure for that defensibility.

When the algorithm is the defensibility, the architectural argument for custom becomes absolute: you do not put your core IP inside a platform whose future roadmap, pricing decisions, and data model constraints are controlled by a third party. The operational risk of having your differentiating algorithm locked inside Odoo's module layer — subject to Odoo's upgrade cycles, data model changes, and API deprecations — is not theoretical. It is a strategic dependency on a vendor whose incentives are not aligned with protecting your specific competitive advantage.

The Hybrid Architecture — What the Most Experienced Operators Actually Build

The most useful output from the community analysis is not the binary decision framework — it is the hybrid architecture that experienced operators have converged on when they have correctly applied the governing principle. The hybrid is not a compromise. It is the correct architecture for businesses where the matching logic is custom territory and the operational layer is not.

The pattern: build a standalone matching service with a clean REST or GraphQL API as the core product. Keep Odoo (or HubSpot, Zoho, or any comparable operational platform) as the CRM, invoicing, messaging, and workflow layer that wraps the matching service. The matching service does one thing: given a set of inputs (candidates, constraints, preferences, historical signals), it returns a ranked result set. Odoo consumes that result set via API and presents it through its operational interface — assignment records, project records, invoices, and client communications all flow through Odoo's native modules.

HYBRID ARCHITECTURE — MATCHING ENGINE + ODOO OPERATIONAL LAYER
──────────────────────────────────────────────────────────────────

                    ┌─────────────────────────────────┐
                    │         CLIENT / USER LAYER      │
                    │   Web App / Mobile / API Client  │
                    └──────────────┬──────────────────┘
                                   │
                    ┌──────────────▼──────────────────┐
                    │      CUSTOM MATCHING ENGINE      │
                    │    (Standalone Microservice)     │
                    │                                  │
                    │  → Weighted ranking algorithm    │
                    │  → Constraint satisfaction       │
                    │  → Timezone-aware scheduling     │
                    │  → Capacity limit enforcement    │
                    │  → Conflict detection            │
                    │  → Feedback loop weight updates  │
                    │                                  │
                    │  Exposes: REST API               │
                    │  POST /match  → ranked results   │
                    │  POST /score  → candidate score  │
                    │  PUT  /feedback → weight update  │
                    └──────────────┬──────────────────┘
                                   │
                    ┌──────────────▼──────────────────┐
                    │         ODOO OPERATIONAL LAYER   │
                    │                                  │
                    │  CRM Module:                     │
                    │  → Contact records               │
                    │  → Lead/opportunity pipeline     │
                    │  → Client relationship history   │
                    │                                  │
                    │  Project Module:                 │
                    │  → Assignment records            │
                    │    (populated from matching API) │
                    │  → Task management               │
                    │  → Delivery milestones           │
                    │                                  │
                    │  Accounting Module:              │
                    │  → Invoice generation            │
                    │  → Payment collection            │
                    │  → Revenue recognition           │
                    │                                  │
                    │  Messaging / Discuss:            │
                    │  → Client communication          │
                    │  → Internal coordination         │
                    └──────────────┬──────────────────┘
                                   │
                    ┌──────────────▼──────────────────┐
                    │     THIRD-PARTY INFRASTRUCTURE   │
                    │  Stripe (payments) / Calendly    │
                    │  (scheduling) / Twilio (SMS)     │
                    │  / SendGrid (email delivery)     │
                    └─────────────────────────────────┘

API FLOW EXAMPLE — NEW MATCH REQUEST:
  1. User submits match request via Web App
  2. Web App → POST /match to Custom Matching Engine
     Payload: { candidates: [...], constraints: {...}, 
                preferences: {...}, history_signals: [...] }
  3. Matching Engine returns: { ranked_results: [...], 
                                confidence_scores: {...] }
  4. Web App → Odoo API: create Project record with 
     assigned candidate from ranked_results[0]
  5. Odoo triggers: client notification email, task creation,
     invoice schedule generation — all native module logic
  6. Post-match: Odoo webhook → PUT /feedback to Matching Engine
     Payload: { match_id: "...", outcome_quality: 4.2, 
                completion_rate: 1.0 }
  7. Matching Engine updates weights — next match is better

This architecture has four properties that make it superior to both pure Odoo and pure custom for businesses in the hybrid category. First: the matching engine is independently deployable and testable. Changes to the algorithm do not require Odoo module updates, regression testing across the operational layer, or upgrade compatibility management. Second: the operational layer is standard Odoo, which means it benefits from Odoo's active development roadmap, community module library, and implementation partner ecosystem. No custom engineering time is spent maintaining invoicing or CRM logic. Third: the API boundary between the two systems is an explicit contract — which means either layer can be replaced without the other being affected. If Odoo is eventually outgrown, the matching engine survives the migration. If the matching algorithm is replaced with a more sophisticated model, Odoo continues operating without modification. Fourth: each layer can be built and deployed on its own timeline. Odoo can be live in week five serving the operational functions while the custom matching engine is still in week three of development.

Designing the API Contract Between the Matching Engine and Odoo

The quality of the hybrid architecture depends entirely on the cleanliness of the API contract between the custom matching engine and the Odoo operational layer. A poorly designed API boundary creates the same coupling problems that plague monolithic architectures — changes to the matching engine require Odoo module changes, and vice versa. A clean API boundary means both systems evolve independently.

The critical design principle in the API contract: Odoo is never the source of truth for the matching algorithm's inputs or outputs. Odoo holds operational records — project assignments, client relationships, invoice records — but the matching engine holds the candidate scores, the criterion weights, the availability constraints, and the feedback history. This separation prevents the failure mode where Odoo data model changes corrupt the matching engine's input data, or where the matching engine's schema assumptions break Odoo module logic.

The POC Mandate — Why You Run Both Proofs of Concept Before Committing

The most actionable recommendation from the community corpus is the one that costs the least to execute and produces the most decision-relevant data: run a proof of concept with both approaches before committing to either architecture at full scale. The POC is not a pilot. It is a targeted technical experiment designed to answer a specific question: for this specific piece of logic, what is the effort cost of implementing it in Odoo versus implementing it as a standalone service?

The Odoo POC should take three to five days. The goal is not to build a production Odoo module. The goal is to determine whether the matching logic in question can be represented in Odoo's data model and workflow engine without requiring workarounds that create maintenance overhead. If the Odoo POC produces a clean module with native field types, standard workflow actions, and no Python overrides — that is a signal that Odoo can handle this logic. If the Odoo POC requires computed fields that are essentially API call proxies, Python overrides on every model method, and scheduled actions working around the absence of event-driven hooks — that is the signal that the logic belongs in a custom service.

The custom POC should take the same three to five days. The goal is to implement the core matching algorithm for a single, simplified case — two candidates, three criteria, one constraint — and expose it via a minimal REST endpoint. The purpose is to measure: how long does it take to add a fourth criterion? How long to add a constraint type? If adding a criterion takes four hours in the custom POC and would require a module update plus regression testing in the Odoo POC, the iteration velocity differential is already visible at prototype scale. That differential grows as the algorithm grows in complexity.

FIVE-DAY POC EXECUTION PLAN — RUN BOTH IN PARALLEL
──────────────────────────────────────────────────────────────────

ODOO POC (Days 1–5)

Day 1: Scaffold
  → Install Odoo Community (Docker) or access existing instance
  → Create minimal custom module: matching_engine_poc
  → Define data model: Candidate, MatchRequest, MatchResult objects
  → Goal: data model operational, basic CRUD via Odoo interface

Day 2: Core Logic
  → Implement simplest matching case: 2 candidates, 3 criteria
  → Use Odoo's computed fields for score calculation
  → Evaluate: can the scoring formula live as a stored computed field?
    Or does it require a @api.depends that calls external logic?

Day 3: Constraint Layer
  → Add one constraint: timezone overlap requirement
  → Evaluate: can Odoo's domain syntax express this constraint?
  → Test: add a second constraint (capacity limit)
  → Evaluate: does adding constraints compound config complexity
    linearly or exponentially?

Day 4: Iteration Test
  → Change one scoring criterion weight
  → Measure: total time from decision to tested implementation
  → Change one constraint rule
  → Measure: same metric
  → Document: all workarounds introduced in Days 1–4

Day 5: Verdict
  → Count Python overrides introduced
  → Count workarounds that bypass Odoo's native model
  → Estimate: time cost of adding 5 more criteria
  → Record: total developer-hours spent on Days 1–5

──────────────────────────────────────────────────────────────────

CUSTOM SERVICE POC (Days 1–5, parallel)

Day 1: Scaffold
  → FastAPI (Python) or Express (Node.js) service
  → POST /match endpoint accepting: candidates[], criteria{}, constraints{}
  → In-memory matching logic (no database required for POC)
  → Goal: endpoint returning ranked results for hardcoded test data

Day 2: Core Logic
  → Implement weighted scoring: N criteria, configurable weights
  → Add: simple constraint check (one constraint type)
  → Unit tests: 3 test cases covering scoring correctness
  → Evaluate: how long to add a new criterion? (should be < 30 mins)

Day 3: Constraint Layer
  → Add timezone-aware scheduling constraint
  → Add capacity limit constraint
  → Evaluate: constraint addition as isolated function — does it 
    require touching scoring logic?

Day 4: Iteration Test
  → Change one weight: time from decision to tested implementation
  → Add a new constraint type: same metric
  → Simulate a feedback loop: POST /feedback updates a weight dict
  → Measure: total iteration cycle time vs. Odoo POC Day 4

Day 5: Verdict
  → Count external dependencies introduced
  → Estimate: time cost of adding 5 more criteria
  → Record: total developer-hours spent on Days 1–5

──────────────────────────────────────────────────────────────────

DECISION OUTPUT — COMPARE THE TWO VERDICTS:

If Odoo POC dev-hours ≤ Custom POC dev-hours AND
   Odoo iteration cycle time is acceptable AND
   Odoo workaround count is low (< 3 overrides):
   → Use Odoo for this layer

If Custom POC iteration cycle is significantly faster AND
   Odoo introduced structural workarounds AND
   The logic is expected to evolve frequently:
   → Build custom. Odoo handles operational layer only.

The Risks and Failure Modes — Where Both Approaches Collapse

The community corpus is unusually honest about the failure modes of both approaches. Operators who committed to the wrong architecture at the wrong stage report specific, recurring patterns that are worth documenting explicitly — because the failure modes are predictable enough that they function as warning signals when you see them developing in your own implementation.

Odoo Failure Mode: Platform Fighting

The Odoo failure mode has a specific name in the community: platform fighting. It is the state where every iteration of the matching logic requires fighting against Odoo's data model and workflow constraints rather than expressing the logic directly. Platform fighting manifests as: computed fields that are essentially database-level API proxies, scheduled actions that substitute for event-driven webhook triggers, Python method overrides that accumulate in a custom module as the "exceptions" to Odoo's native behavior, and XML configuration files that grow in complexity as each new matching criterion requires a new domain filter expression.

Platform fighting is insidious because it is gradual. The first workaround takes an hour. The second takes two. By the tenth workaround, the module is a structural dependency on Odoo's internal APIs — which means every Odoo version upgrade is a compatibility audit of every workaround in the module. The team that started using Odoo because it was faster to build than custom is now spending more time maintaining the workaround stack than it would have spent building a clean custom service from the start.

Custom Build Failure Mode: Scope and Cost Compounding

The custom build failure mode is symmetric: it is the gradual accumulation of scope driven by edge case handling. The initial matching algorithm for the simplest case — two candidates, three criteria, one constraint — is rarely the expensive part. The expensive part is the tenth constraint type, added because a specific client segment has a requirement that the original algorithm did not anticipate. And the fifteenth exception rule, added because the feedback loop revealed a systematic bias in the weight model for a specific geographic market. And the error handling layer, added because the constraint satisfaction problem is occasionally infeasible and the system needs to communicate that clearly rather than returning a null result.

Each addition is individually justified. The cumulative effect is a matching engine that costs three times the original estimate and takes twice as long to build as projected. This is not a planning failure — it is the intrinsic nature of constraint-based decision logic, which grows in complexity faster than linear as the number of constraints and criteria increases. The operators who manage this successfully are the ones who built the scope control into the architecture from the start: a minimal matching engine that proves value on the core case, deployed to production before any edge case handling is built, with new constraint types added only after the business has validated they are required by real customers.

The Build Sequence That Produces Working Systems

Synthesizing the decision framework, the hybrid architecture, the POC methodology, and the failure mode documentation produces a specific build sequence. This sequence is not theoretical — it is the sequence described by operators who shipped systems that worked, as distinct from the sequences described by operators who are still rebuilding systems that did not. The differences between the two groups are visible in the first three decisions they made.

RECOMMENDED BUILD SEQUENCE — HYBRID MATCHING + ODOO OPERATIONAL
──────────────────────────────────────────────────────────────────

WEEK 1–2: VALIDATION BEFORE ARCHITECTURE

  □ Identify 2–3 pilot customers willing to evaluate matching output
  □ Define matching criteria as a plain-language list (no code yet)
  □ Run both POCs (5 days each, can overlap):
      Odoo POC: can this logic live here without platform fighting?
      Custom POC: what is the iteration velocity on the core algorithm?
  □ Select architecture based on POC comparison
  □ Define API contract between matching engine and operational layer
    (even if Odoo will be both layers initially — document the separation)

WEEK 3–5: ODOO OPERATIONAL LAYER (parallel with engine development)

  □ Install and configure Odoo with minimal modules:
      CRM (contact and lead records)
      Project (assignment records)
      Accounting (invoice generation)
      Discuss (client messaging)
  □ Import pilot customer data — contacts, candidate records, history
  □ Train reception / operations team on Odoo native workflows
  □ Configure Odoo webhook: project stage changes → POST to matching API
    (webhook fires to a placeholder endpoint initially — engine not live yet)

WEEK 3–5: CUSTOM MATCHING ENGINE (parallel with Odoo setup)

  □ Build minimum viable matching algorithm:
      Core scoring function (N criteria, configurable weights)
      One constraint type (the most frequently required one)
      POST /match endpoint returning ranked results
      Basic logging: every match request logged with input + output
  □ Unit test coverage: scoring correctness + constraint enforcement
  □ Deploy to staging environment
  □ Connect Odoo webhook to staging matching engine endpoint

WEEK 6: PILOT DEPLOYMENT

  □ Run first live matches for 2–3 pilot customers
  □ Collect feedback: was the top-ranked result accepted? If not, why?
  □ Log all accepted vs. rejected matches with reason (where available)
  □ DO NOT add new constraints or criteria during pilot — observe only

WEEK 7–8: ITERATE ON VALIDATED LEARNING

  □ Review pilot feedback: which criteria drove the most correct matches?
  □ Review pilot rejections: which constraints were missing or wrong?
  □ Add exactly one new constraint or weight adjustment per sprint
  □ Re-pilot updated matching engine with same pilot customers
  □ Only after second pilot validation: expand to additional customers

WEEK 9+: SCALE OPERATIONAL LAYER

  □ Add remaining Odoo modules required for full operational coverage:
      Calendar integration (Calendly or Odoo's native calendar)
      Payment collection (Stripe integration via Odoo accounting)
      Client portal (Odoo's native portal module)
  □ Stripe handles payments — never build custom payment processing
  □ Calendly handles scheduling interface — matching engine handles
    availability constraints, Calendly handles UX
  □ Add matching engine endpoints: /score, /feedback, /availability
    as operational workflow validates the need for each

──────────────────────────────────────────────────────────────────

SCOPE CONTROL PRINCIPLE: Add to the matching engine only what
pilot customers rejected matches over. Add to the Odoo layer only
what operations staff cannot execute without it. Everything else
is future scope — not current architecture.

The Final Synthesis — Three Decisions, One Architecture

The build-vs-buy question for matching and decision engine systems resolves to three decisions made in sequence. Every operator who has built a system that held together under real operational load made these three decisions correctly. Every operator whose system is currently being rebuilt made at least one of them incorrectly.

Decision One: Is the algorithm the product? If yes, the algorithm is custom. If no, use the platform that most efficiently represents the logic you need. This decision cannot be deferred. It must be answered before the first line of code is written, because it determines the architecture of everything that follows.

Decision Two: What is the minimum algorithm that proves value? Not the complete algorithm. Not the production-ready algorithm with all constraints and edge cases handled. The minimum version — the simplest expression of the core matching logic — that a real pilot customer can evaluate and confirm is directionally correct. This decision controls scope compounding. Without it, every new requirement is added to the initial build rather than to a post-validation iteration cycle.

Decision Three: What does the operational layer need to do before the algorithm is ready? Odoo should be configured and operational for pilot customers — CRM records, invoicing, client communication — before the matching engine completes its first iteration. The operational layer is not waiting for the algorithm. The algorithm is being developed in parallel. Pilots interact with the operational layer immediately, providing feedback on operational experience while the algorithm feedback accumulates separately. The two iteration cycles are independent, and they should stay that way.

The architecture that emerges from these three decisions correctly is the hybrid: a custom matching service with a clean API at the core, Odoo handling the operational layer around it, and a validation-first development sequence that prevents both platform fighting and scope compounding from accumulating before the matching model has been confirmed to be correct by real users.

The failure to make these decisions explicitly — relying instead on platform preference, team familiarity, or vendor sales cycles — is what produces the rebuild situations documented across the community threads. The rebuild is always more expensive than the additional week spent making the architecture decision correctly at the start. Always.

"The hardest part isn't the CRM or the invoicing layer. It's the decision engine. Every team underestimates it at the spec stage and pays for that underestimation at the build stage. The teams that don't underestimate it are the ones who ran the POC before they wrote the architecture document." Arsalan Faysal — Revenue Systems Architect