Bespoke vs ERP.
Why Custom Now Wins.
For a long time, "buy Odoo" was the rational choice. Three deep shifts have changed the maths entirely.
Why Bespoke Didn't Use to Make Sense
Before arguing that bespoke now beats Odoo (and similar ERPs) for SMB greenfield projects, it's worth being explicit: for a long time, the non-bespoke decision was rational.
Historically, bespoke internal software lost on three axes:
Cost of Development
- You needed a proper dev team.
- There was a lot of boilerplate and ceremony just to get a simple CRUD app into production.
Risk of Failure
- A single freelancer or lone dev could leave, and the system became unmaintainable.
- No updates, no security patches, no roadmap.
Feature Parity
- ERPs arrived with accounting, invoicing, inventory, CRM, HR, reporting, permissions, integrations.
- You'd never match that breadth as a small company.
So "buy Odoo" (or a similar ERP) made sense: the platform amortised huge fixed costs over many customers.
The world that made that the default choice has changed on all three axes.
The Core Shift: What's Actually Different Now?
Three deep changes make bespoke a rational default for SMB greenfield projects today:
AI coding has collapsed the fixed cost of boilerplate and scaffolding
Flask + Postgres + simple SQL is a perfect substrate for AI assistance
The real value (and lock-in) has moved from "platform" to "schema + workflow understanding"
AI Collapses the Fixed Cost of Building
A decade ago, "let's build our own internal tools" meant weeks to set up auth, CRUD scaffolding, list/detail/edit views. Endless time spent on forms, validation, pagination, table filters. That was pure overhead before you even touched your real workflow.
Now, for the stack we advocate (Flask + psycopg2 + Postgres):
- A developer or power user can describe the schema and workflow in plain language and get initial routes, templates, queries, and basic validation generated in minutes, not weeks.
- Iteration cycles are short: "We need a new field / view / report" → change the schema → update prompts → regenerate or patch the code.
AI doesn't remove the need to think, but it removes the drudgery that used to make bespoke uncompetitive with an off-the-shelf ERP.
Implication
The fixed cost of "rolling your own" is no longer a show-stopper for SMBs.
Flask + Postgres Is AI-Native; ERPs Are Not
ERPs like Odoo are highly abstracted and meta-model heavy, configured via XML/JSON definitions, ORM layers, and framework-specific concepts (records, views, actions, wizards), tightly coupled to their own plugin ecosystem.
This makes them hostile to AI coding in two ways:
Huge cognitive surface area
You must understand Odoo's particular conventions to make safe changes. LLMs are more likely to hallucinate or mis-wire things in complex frameworks.
Code and config are not "local"
A change often touches models, views, access rights, and workflows spread across many files and layers.
In contrast, a Post-ERP, Flask-first approach is optimised for simple, explicit Python functions, raw SQL where possible, and direct mapping: table → route → template.
This is exactly the pattern that works best with AI
You can feed schema.sql, a route file, and a template into an LLM and say "adapt X to do Y". The model doesn't have to reverse-engineer a framework's meta-magic; it can see exactly what's happening.
Implication
In an AI era, simple bespoke code is easier and safer to evolve than intricate ERP customisations.
The Schema Is the New System of Record
The database is the cathedral; the Flask apps are tents.
ERPs historically sold the idea: "Your data is safest with us; we own the canonical model of your business."
But for SMBs, most pain comes from data being locked into a vendor's idiosyncratic schema, and workflows contorted to match the ERP's generic assumptions.
In a Post-ERP world:
The schema and its evolution are:
- • the primary asset
- • the real "ERP"
- • relatively stable over time
The UI / app layer is:
- • cheap to change
- • cheap to regenerate via AI
- • intentionally thin
Investing in your own schema + workflows produces something you can carry anywhere (even into a future system) and reduces lock-in dramatically. Customising Odoo deeply couples you to its framework, ORM, upgrade path, and plugin model.
Implication
Owning your schema and workflows is now higher leverage than owning "an ERP licence".
Why Bespoke Now Beats Odoo for Greenfield SMBs
Your workflow fits your business, not a template
Odoo (and peers) work by assuming a "generic business" and providing modules for sales, inventory, accounting, HR, etc. Then you customise fields, workflows, views, permissions.
The danger zones:
- • Either you contort the business to match what the ERP expects
- • Or you add so much customisation that upgrades become brittle and your instance becomes a one-off snowflake anyway — but with ERP overhead
With a bespoke approach, you start from actual processes (how the team works) and the data that truly matters. You design tailored tables, minimal sharp workflows, and opinions that fit this company, not "any business". In AI-assisted development, the cost of doing this first-principles design is now small compared to the benefits of fit.
Complexity penalty vs complexity dividend
ERPs trade breadth of features for inherent complexity (meta layers, generic abstractions). For an SMB with 10–100 users, maybe 3–7 real workflows that matter, and a limited change budget — that inherent complexity is a tax:
Implementation
is slow
Training
is painful
Change
is scary
In a bespoke, Post-ERP stack, every feature you see exists because it's needed for this workflow. The architecture is thin enough that one person can hold it in their head and AI tools can genuinely "see" the whole system. Complexity is something you add only when justified, not inherited as the starting point.
Vendor lock-in vs capability building
Odoo gives you
A rich immediate surface — but little durable internal capability beyond "we know how to click around Odoo".
Bespoke gives you
A deeper understanding of your data, your actual processes, the discipline of schema design, basic querying, and thinking clearly about workflows.
In an AI era, that capability is disproportionately valuable: your ops manager + an LLM can now generate new reports, add fields, and tweak validations with minimal external help. Long-term, this is much more defensible than "we have an Odoo instance".
Cost structure and pricing power
Odoo-style ERPs
- • Recurring licence and maintenance fees (per-user or per-module)
- • Customisations require certified consultants, change requests, integration work
Bespoke Flask + Postgres
- • Core stack is free / commodity (Postgres, Python, Flask)
- • Hosting is simple (one web app + one DB) and cheap relative to value
The main cost is initial build (now mitigated by AI) and incremental improvements (cheap if the system stays simple). On a multi-year horizon, TCO is often lower than ERP + consultants — and the option value is higher: easier to pivot, easier to integrate with other tools.
"But Odoo Has Everything Out of the Box"
There are cases where Odoo might still be the right choice, even for an SMB:
- • The business wants full accounting suite, payroll, HR, inventory — all in one place
- • They can live with "generic ERP workflows"
- • They don't have anyone willing to "own" a schema or any appetite for internal software at all
In those cases, bespoke can be overreach. The key is segmentation:
Post-ERP bespoke is strongest for
Ops-heavy SMBs with unique workflows: logistics, clinics, specialised agencies, trades, B2B service shops — where core value comes from how they operate, not just "we issue invoices".
Odoo shines if
The business is "close enough" to standard patterns and they want conventional accounting + off-the-shelf modules with minimal thinking.
Being clear about this boundary makes the bespoke argument more credible, not less.
Brownfield: Existing Odoo / ERP
For brownfield — companies that already have Odoo or another ERP — the story shifts from "replace" to "carve out and surround".
Rule of thumb: use Post-ERP at the edges first
Do not start by ripping out Odoo's core (especially not accounting). Instead, identify high-pain, high-variance workflows around it: job scheduling, quoting / estimating, field data capture, production planning, custom reports combining external data.
Build small Flask apps that integrate with Odoo only where necessary, or sync via APIs / periodic jobs. The Postgres database is the cathedral. Each small Flask app is a tent handling one painful process. Over time, you can increase the share of business workflows handled by your apps and reduce use of Odoo to the accounting base and maybe some HR pieces.
Path A — "Shadow ERP" around Odoo
Keep Odoo for general ledger, invoices, basic CRM. Build Post-ERP apps for operations that Odoo handles badly and bespoke dashboards and planning tools.
Sync options:
- • Minimal: export/import CSVs periodically
- • Moderate: a small integration service calling Odoo's API
- • Deeper: if Odoo's DB is accessible, read from its tables and keep your own app state in separate tables
The idea is not to fight Odoo; it's to stop forcing all workflows through it.
Path B — Gradual Module Retirement
Over 1–3 years, identify Odoo modules that have heavy customisation, constantly cause upgrade pain, and are hated by users. For each:
- Analyse the real workflow and data
- Design a dedicated schema (Post-ERP style)
- Build a focused Flask app
- Run both systems in parallel for a period
- Plan a cut-over where Odoo keeps historical data and new records are managed entirely in your app
Eventually, Odoo becomes a relatively small, well-understood subsystem — potentially replaceable later by a simpler accounting solution.
Path C — Data-Centric Brownfield
Some companies are stuck because they don't even understand their ERP database. Here, a schema-first approach shines as a tool for untangling the mess:
- • Dump core tables and key relationships
- • Build a parallel Postgres schema that models the same concepts cleanly, correcting naming and relationships
- • Build Flask apps on the clean schema
- • Sync data back and forth until you can gradually cut over
This turns brownfield into a data-modelling problem instead of a monolithic "ERP migration project".
Why Bespoke Post-ERP Is a Realistic Default Now
AI killed the boilerplate tax
Making custom internal tools feasible at SMB scale.
Simple Flask + Postgres architectures are AI-native
And easier to evolve than customisations in Odoo's meta-universe.
Schema + workflow thinking is the real long-term asset
You want to own that, not rent it from a vendor.
For greenfield SMBs with distinctive ops, ERP complexity is a tax, not a feature
A few sharp bespoke apps trump a sprawling generic platform.
In brownfield, you don't have to "go to war" with Odoo
You can surround it, carve out pain points, and gradually reclaim control.
This is why, for many SMB greenfield projects today, betting on a bespoke Post-ERP stack is not contrarian bravado — it is the rational move.
Ready to Go Post-ERP?
Read the full Post-ERP manifesto, or start building your first bespoke app today.
Join the Movement
Get tutorials, tools, and insights on building with Flask + PostgreSQL + Vanilla JS.
No spam. Unsubscribe anytime. We respect your inbox.