Python development in Toronto and across Ontario: data pipelines that validate and reconcile regulated data, integrations between the systems you already run, automation that replaces the spreadsheet in the middle, Django applications built accessible — engineered, tested and maintained by the same team for over a decade.
Regulated data, moved reliably. The one bad record is rejected and logged; everything else lands, and the tests say so.
Python in production
10+ yrsPython in production
accessibility built into every delivery
AAaccessibility built into every delivery
built and supported in Ontario
Torontobuilt and supported in Ontario
The language of the middle
Most organizations do not have a software problem; they have a middle problem. The ERP is fine and the CRM is fine, and between them sits a spreadsheet that one person understands, a nightly export nobody trusts, and a form whose data is retyped twice. Python is the language that fixes the middle: it speaks to databases, files, APIs, the ERP and the scientific stack alike, and it is readable enough that the person who maintains it next year will understand it.
We have built Python in production for over a decade: data pipelines that validate regulated data and tie their totals to the source, integrations between the systems clients already run, the automation that replaces the export nobody trusts, and Django applications built accessible. Odoo is written in Python, and so are our custom modules for it — the OneClient CRM we built with Achēv is Odoo custom modules end to end — which is why one team can build the ERP, the pipeline and the application without a hand-off. The enquiry form on this site is handled by a Python service we wrote — with its own spam scoring, file scanning and audit trail — because we would rather run our own than trust a vendor’s.
Engineered, which means tested
The difference between a script and a system is what happens when the data is wrong. Our pipelines validate on the way in, reject and log what fails, load what passes idempotently, and carry an audit trail out the other side; tests run on every change, and the totals are reconciled to the source before anyone depends on them. That is what the cover of this page draws, and it is the standard we hold to whether the job is a nightly indexer or a platform.
What we build in Python
The language of the middle — where your systems, your data and your people meet
Data pipelines that reconcile
Extract, validate, transform, load — with a schema on the way in, an audit trail on the way out, and totals that tie to the source. Built for regulated data: health, research, government, finance.
Integrations between the systems you run
The ERP, the CRM, the registry, the partner API, the legacy database nobody will retire. Connected with code you own and we test, not a chain of connectors and exports. For Green Standards, the integration between their Quickbase application and their Odoo client portal is custom Odoo modules we wrote in Python.
Automation and scheduled work
The nightly job, the document indexer, the report that assembles itself. For HEQCO, Python text extraction with cron and WP-CLI put full-text search across every PDF publication on the site.
Data science and machine learning, in production
Models are the easy part; the pipeline that feeds them, the validation around them and the monitoring after them are the work. We build the whole of it, and we say when a model is not the answer.
Odoo and the ERP layer
Odoo is written in Python, and so are our custom modules for it — the OneClient CRM we built with Achēv is Odoo custom modules end to end. The same team writes the integration on both sides.
Django applications
Full applications on Django — authentication, roles, workflows, reporting — built to WCAG 2.1 AA because the people who use them have a right to, and hosted on a hardened stack we configure by automation.
How an engagement runs
Discover
The data as it is, the systems as they are, the decisions the software has to support, and the rules the data must obey. A scope you can price and a plan you can defend.
Build, tested
Working software every two weeks, with tests that run on every change and a staging environment you can see. Validation rules written down as code, not remembered by one person.
Reconcile and cut over
Rehearsed runs against real data, totals tied to the source, a cutover that is boring on purpose.
Run
Monitoring, logs that answer questions, and a support arrangement sized to how much you want to own. Repositories are yours from day one.
Who this is for
Public-sector data programs
Ministries, agencies and institutions that collect regulated data and must move it between systems without losing a record or a rule. We are an Ontario Vendor of Record.
Research and health organizations
Teams whose data carries meaning in its structure and whose applications must be accessible to everyone who uses them.
Operators with systems to connect
Organizations running an ERP, a CRM and three spreadsheets that should be one pipeline — and who want to own the code that replaces them.
Questions we're asked
Why Python?
Because it is the language of the middle: the one that speaks to databases, files, APIs, the ERP and the scientific stack alike, with libraries mature enough to trust and readable enough to maintain. It is Odoo’s language and it is ours, which is why one team can build the pipeline, the integration and the application without a hand-off.
Do you maintain what you build?
Yes. Every delivery includes tests, documentation and a repository you own, and most clients keep us on a retainer for the changes, upgrades and questions that follow. We would rather be the team that answers in year three than the one that disappears after launch.
Can you work with our data team?
Yes, and we prefer it. We write in the open, review together, and leave your team able to run and extend what we built. Knowledge transfer is a deliverable, not a courtesy.
How do you handle personal and health information?
On your infrastructure or ours in Canada, with the minimum data needed for the job, encrypted in transit and at rest, logged and access-controlled. Where a project touches personal health information, the design follows the custodian’s obligations under Ontario’s health privacy law and is documented for your privacy officer.
Are the applications accessible?
Yes. A Django application is a website, and we build it to WCAG 2.1 AA with the same accessibility practice that serves our public-sector clients — and we say so with a conformance report if you need one.
Where does it run?
On a hardened Linux stack we configure by automation — the same discipline as our WordPress hosting — on your infrastructure, your cloud account, or ours in Toronto. Never on a platform you cannot leave.