Brian Pond
I understand the business. I build the solution.
I understand the business. I build the solution.
In February 2021, I joined Farm To People as their sole backend developer. Fourteen months to retire expensive proprietary systems and build a company-owned stack from scratch: one integrated platform serving as shopping cart, ERP, and data hub. No Shopify. No WooCommerce. No Magento. The platform had to understand farm-to-table business — subscriptions, farm boxes, multi-week ordering windows, real-time quantity availability — none of which the out-of-the-box solution supported.
Before ERPNext, I spent over a decade in Microsoft Dynamics AX, first as an employee, then as an independent consultant. I was typically the sole technical resource for my clients: custom development, reporting, data warehousing, upgrades, and operations. This era concluded in 2019 and is not my current practice.
BTU (Background Tasks Unleashed) started at Farm To People out of necessity: ERPNext's built-in scheduler couldn't handle production workloads, so I built a replacement: a multi-threaded Rust daemon with a Python interface, Redis queue integration, and timezone-aware cron scheduling. It became the backbone of FTP's integration and automation layer, and is now used across the ERPNext community (62 stars, 26 forks).
dbconform is a database schema drift detection and repair tool for SQLAlchemy/SQLModel projects, my first contribution to the broader Python and SQL ecosystem, not niche Frappe work. It's the primary artifact of my Scribe Coding methodology (documentation-driven AI development) showcased at PGConf.dev 2026.
Industries across the full record: e-commerce, manufacturing, biotech, construction, distribution, and retail.
Each of these maps to real client work. If one sounds familiar, I've solved it before.
Our ERP doesn't match how we actually sell.
Custom subscription logic, ordering windows, availability rules, and storefront APIs on ERPNext, built when out-of-the-box ERP cannot model the business.
We've outgrown our vendor stack.
Replatforms, database migrations, and major version upgrades while the business keeps operating, including retiring proprietary systems you no longer want to rent.
We need reports finance actually trusts.
Balance sheets, P&L, aging, and operational reporting written to specification, plus Kimball-style data warehouses and ETL when the source data lives in more than one place.
Our data is scattered and operations run on spreadsheets.
Data engineering, warehouse design, and targeted automation, for example custom shortage and substitution workflows that recovered meaningful staff time daily.
Integrations keep breaking our operations.
Payments, logistics, warehouse systems, and customer messaging wired into the ERP so operations and engineering are not fighting separate silos.
We can't hire a whole implementation team.
Solo full-cycle delivery today: requirements through schema, APIs, customization, and production operations; one person accountable for the outcome.
Business and technology keep talking past each other.
I've worked directly with CEOs, operations managers, customer service leads, and finance teams, and written the code those conversations produced. One person who heard the problem and shipped the fix.
It started early: writing BASIC on an Epson QX-10 around age ten, copying lines from a programming book until the patterns clicked, then modifying them to see what would break. That book is still in my office, framed.
The formal foundation: Computer Engineering at West Point (1995–1999), then four years as a U.S. Army officer. Those years built discipline and a deep understanding of how large organizations actually work, both of which turned out to be useful in ways I didn't anticipate. By 2003, I was ready for a civilian career.
My first civilian job put me in front of databases built by Unix workstations running Fortran. I wasn't intimidated; I was nostalgic. It felt like being a teenager again. From there, every move was the same binary choice: stay comfortable, or learn something new. I chose SQL over stagnation at Honeywell. I chose ERP over generic database work. Depth over breadth, every time.
I spent over a decade in Microsoft Dynamics AX, first as an employee, then as an independent consultant across manufacturing, retail, biotech, and construction. X++ is a niche language, but a formative one: databases and ORMs were built into its nature, UI and forms were first-class concerns, and background task processing was a built-in concept. That ecosystem pushed me to think beyond classes and functions and consider the full picture of how a business system works. It's where I became a true all-purpose programmer.
By late 2016, I recognized a problem I'd created: I knew everything about Dynamics AX, but couldn't write a standalone program without it. My entire career ran on Microsoft's continued goodwill and licensing decisions. That realization was uncomfortable. It was also clarifying.
The answer was open source, end to end: an ERP platform (ERPNext) built on open languages (Python, JavaScript) and an open database (MariaDB, later PostgreSQL). No licensing. No lock-in. And, for the first time since the 1990s, the ability to sit down and write a real program on my own machine with no strings attached.
That felt like coming home.
A fortunate client match made it real. They needed total ownership of their stack with no vendor lock-in: exactly what I'd just rebuilt my practice around. Four years later they had a custom platform, a six-person technical team, and revenue that had tripled.
The fundamentals I internalized decades ago still hold: operating systems, networking, data structures, how software actually executes. Everything built on top of those I've replaced, upgraded, or discarded when something better arrived. Knowing the difference between what changes and what doesn't is one of the more useful things a long career teaches you.
I'm still building, and still choosing the harder problem when it arrives.
Most technology projects fail at the handoff: the gap between the person who understands what the business needs and the person who has to build it. I've sat on both sides of that table. I collapse it into one role, or I become the person who makes the handoff work.
I can read financial statements, not only query a database to produce them. I understand supply chain concepts like inventory costing, MRP, and purchase-order automation deeply enough to implement them correctly, or to write specifications clear enough that another developer can.
No handoff. No miscommunication. No implementation that was 'close enough' to a requirement nobody really understood. Whether I'm writing the code or leading the people who do, the business gets what it actually asked for.