How I Built a Manufacturing ERP with AI—One Weekend at a Time
I am a Chartered Accountant, not a professional software engineer. What began as a weekend learning project gradually became an extensive Flask ERP covering production, inventory, labour, sales, receivables, costing, dashboards, security and audit-oriented controls.
A few months ago, I did not sit down with a plan to build a full manufacturing ERP. I simply wanted to learn how modern AI tools could help me convert business knowledge into working software. I started experimenting on weekends, one feature at a time. The project was initially meant to be a practical learning exercise. Then it refused to remain small.
A basic item master led to inventory. Inventory led to purchase receipts. Purchase receipts raised questions about valuation. Production required recipes, bills of material, material consumption, finished-goods output and reversals. Sales required customer purchase orders, dispatches and invoices. Invoices were not enough, because real collection tracking also needed receiving notes, bill submissions, deductions, cash receipts and outstanding balances.
Labour introduced another layer: daily wages, piece-rate work, contractor billing, production posting and cost analysis. As more transactions became connected, dashboards became necessary. Once different users could access the application, login alone was insufficient; the ERP needed roles, permissions, protected actions, safe error handling and an audit-friendly design.
What began as a weekend experiment eventually grew into an extensive, production-oriented business application. The current predeployment build contains roughly 20,000 lines of Python, more than 100 HTML templates, 55 database migrations and dozens of connected business tables. Those numbers do not prove that software is good, but they show how far the project travelled from its modest beginning.
A Weekend Learning Project That Kept Growing
I built the ERP alongside my regular professional responsibilities. Most of the work happened during weekends and spare hours. That shaped the way I developed it. I could not disappear for six months to study computer science first and begin the project only after I felt “ready.” I had to learn the concepts when the application demanded them.
When I needed to store related records, I learned database relationships. When changing the database structure became risky, I learned migrations. When route files became difficult to manage, I learned about blueprints and services. When one user should not be able to perform another user’s work, I learned role-based access control. When the application moved closer to deployment, I had to think about environment variables, secure cookies, CSRF protection, error logs, WSGI servers and backups.
This was not the clean, linear path described in many programming courses. I learned in loops: build, fail, understand, correct, test and rebuild. Sometimes AI gave me a useful implementation immediately. At other times, it produced code that looked convincing but did not fit the existing data model or failed under a real business condition.
I did not wait until I had learned everything required to build an ERP. I allowed the ERP to show me what I needed to learn next.
The Advantage I Already Had Was Not Coding
I began with limited programming knowledge, but I was not starting from zero in the area that matters most for business software: understanding processes, records, controls and decisions.
As a Chartered Accountant, I am trained to ask questions such as:
- What is the source document for this transaction?
- When should the transaction be recognised?
- What changes in quantity, value, cost or liability?
- Who can create, approve, reverse or cancel it?
- What information will management need later?
- How can the transaction be reconciled?
- What happens when the normal process fails?
These questions are as relevant to ERP design as they are to accounting and audit. A developer can build a technically correct form, but someone must still define what the form means, which data it should capture, how it affects other records and what decisions should eventually emerge from it.
Finance professionals often underestimate how much system-design knowledge they already possess. We understand document flows, approvals, reconciliations, exception reporting, costing, cash flow, ageing, audit trails and management information. We may not initially know how to express those concepts through Python classes or database relationships, but we understand why the concepts exist.
Data should not be collected merely because a form can capture it. Every important field should support a transaction, a control, a reconciliation, an analysis or a future decision.
Why I Chose to Learn Through a Manufacturing ERP
I could have learned Flask by building a to-do list or a simple expense tracker. Those are useful exercises, but they would not have tested the skill I was most interested in: turning interconnected business processes into one reliable flow of data.
Manufacturing is a particularly rich problem because the same transaction can affect many parts of the business. Receiving raw material changes stock quantity and inventory value. Production consumes multiple inputs and creates one or more outputs. Labour adds cost and operational context. Dispatch reduces finished-goods stock and begins a customer collection cycle. A payment may include tax deducted at source, liquidated damages or other deductions rather than a simple one-to-one settlement.
The real challenge is not creating a separate page for each activity. It is ensuring that all those activities describe the same business reality.
That made an ERP the ideal learning project. It forced me to combine accounting logic, operational logic, database design, user experience, security and analytics. Each new module exposed an assumption in an earlier module. The application became a practical lesson in how a business is connected.
What the Project Eventually Became
The ERP now records and connects a broad set of manufacturing and financial activities. The exact details will be explained throughout this series, but the current application includes the following major areas.
Masters & Setup
Items, finished goods, recipes, production stages, locations, vendors, customers, transporters, destinations, labourers, contractors and piece rates.
Inventory
Opening stock, purchase receipts, stock adjustments, inventory ledger, quantity drill-downs, weighted-average costing and material movement.
Production
BOM-driven material consumption, finished-goods output, by-products or scrap, production entries, costing and reversal controls.
Order to Cash
Customer purchase orders, dispatch and sales invoices, receiving notes, bill submissions, payment receipts and outstanding receivables.
Labour
Daily-wage sheets, hours worked, piece-rate production, approvals, contractor billing, payment controls and labour analytics.
Job Work
Material issued outside the factory, vendor-held balances, partial receipts, conversion charges, scrap return and job-work ledgers.
Dashboards
Receivables, labour cost, raw-material consumption, production, inventory value, pending orders and management alerts.
Controls & Security
Authentication, password controls, user management, role-based access, protected actions, logging, safe errors and production hardening.
I describe it as production-oriented rather than declaring it “perfect” or “finished.” A serious business application is never complete merely because its screens work. Deployment, backup, recovery, monitoring, security review, user training, data migration and continuous maintenance are separate responsibilities. This project is reaching that stage now.
How AI Became My Development Partner
I used AI tools such as ChatGPT and Kimi K3, along with other coding assistants where useful. Their biggest contribution was not one magical prompt that generated an ERP. Their value came from thousands of smaller interactions.
AI helped me:
- translate a business rule into a possible database and route design;
- explain unfamiliar Flask, SQLAlchemy, HTML, JavaScript and deployment concepts;
- generate a first version of repetitive code;
- trace errors across models, routes, templates and services;
- compare implementation alternatives;
- write migrations and tests;
- review code for missing validations or unsafe actions; and
- help me understand why a solution failed.
But AI did not act like an autonomous software company. It did not retain perfect knowledge of the entire project. It sometimes invented field names, assumed relationships that did not exist, duplicated logic, placed code in the wrong layer or solved the visible error while creating a hidden accounting problem.
The quality of the result depended heavily on the quality of the context I provided. A vague request such as “build a labour module” was far less useful than a structured explanation of worker types, wage rules, approval stages, piece-rate allocation, production impact, cancellation behaviour and billing restrictions.
Define
Write the business rule and exceptions in plain language.
Generate
Ask AI for a focused change using the actual surrounding code.
Test
Run the feature and inspect both the screen and database impact.
Refine
Correct assumptions, retest edge cases and integrate safely.
What AI generated versus what I owned
AI often generated: code drafts, explanations, queries, migrations, templates, debugging hypotheses and test structures.
I remained responsible for: the business meaning, process design, data relationships, acceptance criteria, testing, integration, security decisions and whether the result was fit to use.
Over time, the relationship changed. In the beginning, I mainly asked AI to write code. Later, I increasingly used it to challenge a design, review a workflow, identify missing edge cases and explain trade-offs. I was not only getting more code; I was learning how to ask better technical questions.
Why the Real Purpose Was Always Data and Decisions
An ERP is often described as software that records transactions. That description is incomplete. Recording is only the first layer. The real value comes when correctly structured data can be converted into timely information and then into action.
This thinking influenced the design of the ERP. Inventory records should not merely show how many units are available; they should support valuation, movement analysis, shortage identification and production planning. Receivables should not merely list invoices; they should account for bill submission, cash received, TDS, liquidated damages, other deductions and ageing. Labour data should not stop at attendance; it should connect hours, production quantities, piece rates, contractor bills and product-level cost analysis.
Dashboards were therefore not added only to make the application look modern. They were created to answer management questions. Which receivables need follow-up? Where is working capital blocked? Is labour cost rising relative to billed value? Which material is not moving? Which orders are delayed? Where could better planning reduce cost or avoid a penalty?
This is where I believe finance professionals can make a distinctive contribution to technology. We are used to looking beyond a number and asking where it came from, whether it is reliable, how it should be interpreted and what decision it should influence.
The Difficult Parts Were Not the Screens
A screen can look complete while the underlying business logic is wrong. Some of the hardest questions appeared only after a feature seemed to be working.
Inventory quantity versus inventory value
It was not enough to add and subtract quantities. Purchase receipts, opening stock, production, scrap and adjustments had to affect cost consistently and in the correct sequence.
Production reversal
Deleting an incorrect production record could not simply remove a row. The system had to reverse input consumption and output creation without damaging the audit trail.
Receivable calculation
The unpaid amount was not always invoice value minus cash. TDS, damages and other deductions needed separate treatment and visibility.
Material outside the factory
Job-work material may still belong to the business even when it is physically held by a vendor. Ownership, location, quantity and value needed to remain distinguishable.
Labour and production
An approved labour sheet could create production, but cancellation needed to reverse production while preserving wage and attendance history.
Access and accountability
A login page did not answer who could approve, cancel, delete or administer. Permissions and status-based locks had to reflect responsibilities.
These issues taught me an important lesson: software does not become reliable because the code runs without an error. It becomes reliable when the transaction behaves correctly in normal cases, exceptional cases and reversal cases—and when someone can later understand what happened.
The ERP Records the Past—My Next Goal Is to Help It Plan the Future
The present model focuses on recording and connecting production, inventory, dispatch, billing, receipts, labour and management dashboards. My longer-term interest is to move from transaction processing toward planning and decision support.
The following features are part of the roadmap; they are planned and not presented as completed functionality:
Production Planning
Use customer orders, delivery dates, BOM requirements, available material, current production and capacity constraints to suggest priorities and material needs.
Receivables Forecasting
Apply machine learning to historical customer, invoice, bill-submission and payment patterns to estimate likely receipt dates and collection risk.
AI Insight Assistant
Create a controlled chatbot that can answer authorised business questions, explain dashboard movements and help users explore the data without writing queries.
Forward-Looking Alerts
Move beyond showing what has already happened toward identifying likely shortages, delayed collections, cost pressure and operational bottlenecks.
AI and machine learning can create significant value, but only when the underlying records are sufficiently complete, consistent and meaningful. A forecasting model cannot repair poor transaction discipline. A chatbot cannot produce trustworthy insight if permissions, definitions and source data are unclear.
That is another reason I started with the ERP foundation. Before asking software to predict the future, I wanted it to represent the present accurately.
What This Journey Has Already Taught Me
Domain knowledge is a technical asset
Understanding a business process is not separate from software design. It shapes the data model, workflow, validations, reports and controls.
AI reduces the entry barrier, not the responsibility
It can accelerate learning and implementation, but the person using the software must still understand what can go wrong.
Small, testable changes outperform giant prompts
The project advanced most reliably when I defined one focused rule, supplied the surrounding context and tested the result before continuing.
Data design matters more than visual polish
A beautiful dashboard cannot compensate for incomplete, duplicated or incorrectly connected transactions.
Reversals reveal whether a process is truly designed
Creating a transaction is usually easier than cancelling or correcting it while preserving quantities, values and history.
Security arrives earlier than expected
As soon as more than one person uses a system, identity, authority, safe errors, logs and protected actions become business requirements.
Learning through a real problem changes the motivation
Every new technical concept had an immediate purpose. I was not learning migrations, services or permissions for an examination; I needed them to solve a visible problem.
What This 15-Part Series Will Cover
This article is the beginning, not a victory lap. In the remaining parts, I will document the architecture, business rules, mistakes and trade-offs behind the application. I will explain what AI generated, what I had to understand, what failed and what I would design differently today.
- Part 1: How I built a manufacturing ERP with AI—one weekend at a time
- Part 2: Why I chose a custom ERP as my learning project
- Part 3: My practical AI-assisted development workflow
- Part 4: Learning Flask through blueprints, services and migrations
- Part 5: Designing masters, transactions and ledgers
- Part 6: BOM, production and weighted-average inventory costing
- Part 7: Customer PO to payment and receivables
- Part 8: Job work, partial receipts and vendor-held inventory
- Part 9: Daily wages, piece rates and labour-linked production
- Part 10: Dashboards that support management decisions
- Part 11: Debugging, migrations, testing and technical debt
- Part 12: Roles, permissions, security and audit controls
- Part 13: Preparing the Flask ERP for production deployment
- Part 14: What AI could not decide without business judgement
- Part 15: Can non-programmers build serious software with AI?
Key Takeaways
- I started the ERP as a weekend learning project, not as a claim that I could replace a software team.
- My Chartered Accountancy background helped me define processes, controls, reconciliations, costs and management information.
- AI accelerated coding, explanation and debugging, but it frequently needed context, correction and verification.
- The project grew into connected modules for inventory, production, sales, receivables, job work, labour, dashboards and access control.
- The next phase is intended to add production planning, receivables forecasting and an authorised AI insight assistant.
- The most important lesson is that business software begins with clear business meaning—not with code.
Frequently Asked Questions
Did AI build the entire ERP automatically?
No. AI generated and explained a significant amount of code, but I defined the business rules, supplied project context, integrated the changes, tested workflows, corrected assumptions and remained responsible for the result.
Were you already a software developer?
No. I began with basic programming knowledge. I learned Flask, SQLAlchemy, templates, database migrations, testing, permissions and deployment concepts while solving problems in the project.
Is the ERP already a commercial product?
No. It is an extensive learning project and production-oriented application approaching deployment. It still requires the same disciplines that any serious system needs, including security review, backup and recovery, monitoring, maintenance and controlled user adoption.
Can another finance professional build software with AI?
Yes, a finance professional can use AI to learn and build useful applications, especially when the problem is closely related to their domain. The practical scope should match the risk, and critical systems still require proper testing, security, maintenance and professional technical review.
A question for finance and business professionals
Which process in your work still depends on disconnected spreadsheets and repeated manual follow-up?
Map that process before thinking about software: identify the source data, the approvals, the exceptions, the outputs and the decisions it should support. That exercise alone often reveals where automation can create real value.
No comments:
Post a Comment