Architecture and design practices run on a rhythm that generic ERP does not model. Work advances through recognised RIBA-style stages, fees are agreed as a percentage of construction cost and then drawn down per phase, and every hour a designer or technician logs has to be recoverable against a specific project and discipline. Out of the box, Odoo gives you Project, Timesheets, Sales and Accounting as separate, loosely-coupled apps — but it has no concept of a work stage that gates invoicing, no phased fee schedule, no drawing register, and no clean view of realisation (billed value versus logged cost) per project. Firms end up managing all of this in spreadsheets that drift out of sync with the ERP, so utilisation and WIP figures are never trusted.

The Architecture Firm template is a build-to-order configuration package that we design, code, and install on top of your Odoo database to close exactly those gaps. On the data side we extend project.project and project.task with practice-specific fields — work stage, discipline, drawing number, revision, and issue status — declared as proper fields.Selection and fields.Many2one on models.Model subclasses, with computed fields (@api.depends) that roll fee draw-down, logged timesheet cost, and remaining budget up to the project record. A dedicated fee-schedule model links each stage to a percentage of the agreed appointment and to the sale.order.line and account.move that bill it, so a phase can only be invoiced once its stage is reached and signed off.

Technically, the package ships as a standard Odoo module with a versioned __manifest__.py declaring dependencies on project, hr_timesheet, sale_management and account. Access is governed by ir.model.access.csv plus record rules that scope projects to their assigned team, so a project architect sees their jobs while a director sees the whole book. The UI is delivered through XML view inheritance (form, list, kanban by stage, and a gantt-style planning view) with OWL components where an interactive drawing register or fee tracker is warranted. QWuery/QWeb reports produce a branded fee proposal, a drawing issue sheet, and a project WIP statement; automated actions and scheduled crons handle stage-change notifications and stale-drawing reminders. Everything is reachable over the XML-RPC/JSON-RPC API so a BIM tool, a portal, or a reporting layer can read and write the same records.

Delivery is build-to-order, not an instant download. After a short scoping call we confirm the exact stage model, fee logic, disciplines, and reports your practice uses, then build your version, test it on a staging copy of your database, run UAT with your team, and deploy to production with a rollback plan. Typical delivery is one working week from confirmed scope, depending on how much of your existing project and contact data we migrate and how many integrations are in play. We support Odoo 17.0, 18.0 and 19.0 on both Community and Enterprise, adapting the build to whichever edition you run.

Pricing starts from $999 (indicative, single-company base scope); multi-company practices, additional disciplines and integrations (BIM, portal, e-signature), deeper localization, and larger project/contact data-migration volumes increase the quoted scope. The from-price is a starting point — you receive a fixed written quote after the scoping call, not a surprise at the end.