Perhaps the biggest lessons in my career haven’t come from a line of code I’ve written, but from developing the ERP for a manufacturing company. As far as I’m concerned, in corporate software development, especially for systems like ERP, the software side is often just the tip of the iceberg. The real issue lies in understanding that organizational flow, the people, and the business processes.
After all these years, I’ve seen that the success of an ERP isn’t about how fast you write an API or which modern framework you use, but how accurately you reflect the company’s “purchase/produce/ship/invoice” flow. In fact, sometimes, trying to force the software onto an unclear flow itself invites the biggest mistakes.
Not Code, But Flow and Human Stories
When I started an ERP project, everyone’s eyes were on the code, the screens, the reports. I was also focused on building a robust infrastructure with the PostgreSQL, FastAPI, and Vue/React frontend trio. I was wrestling with technical topics like AI-driven production planning modules, operator screens, and iSCSI supply chain integrations.
However, over time, I realized that the real challenge was finding the answers to questions like “Why is the late shipment report always missing?” in a manufacturing ERP. The root of this problem was often hidden not in a technical bug, but in organizational gaps, such as an operator on the floor skipping data entry, lack of communication between the warehouse and production, or delays in the approval mechanism during the purchasing process. The software was merely a mirror reflecting this flow.
The Hidden Cost of Saying “Yes”
One of the most expensive mistakes in my career was the word “yes.” Saying “yes” to a request that seemed technically feasible but didn’t fit the workflow could lead to unforeseen complexity later on. In a client project, a seemingly simple request for “real-time warehouse count visibility” turned into a months-long marathon of data cleansing and process improvement due to inconsistencies in the existing inventory management processes.
At that moment, I understood that software architecture is often not about software, but about organizational flow. If the organization’s own flow is unclear or contradictory, no matter how clean your code is, the system will eventually break somewhere. This situation showed me how architectural patterns like transaction outbox, event-sourcing, or eventual consistency could lead to disaster without clear business processes.
Data Integrity and the Necessary Flow
While I was proficient in topics like index strategies (B-tree, GIN, BRIN), connection pool tuning, and replication (logical vs. physical) when using PostgreSQL on the database side, the real challenge was ensuring data consistency between different modules. Specifically, how data coming from a production planning system would integrate with supply chain and invoicing processes was a vital issue.
Sometimes, when designing a real-time dashboard, finding answers to questions like “Who will update this data?” or “What is the single source of truth for this information?” in the workflow was more difficult than solving “traps” like optimistic vs. pessimistic lock choices in the database or the N+1 query explosions of an ORM. Because if the workflow doesn’t naturally ensure data integrity, no matter how hard you, as a developer, try, an inconsistency can seep in from somewhere.
Operational Realities and the Feedback Loop
The work didn’t end after the system went live. Topics like CI/CD reliability, blue-green deploy strategies, feature flag usage, and rollback automation were indispensable for the system to run smoothly. Meanwhile, we were monitoring the system’s pulse with observability (metrics, logs, traces) and trying to detect potential issues in advance with SLO and error budget management.
For example, a small delay on an operator’s screen could cause minutes of downtime on the production line, directly impacting the company’s profit margin. These feedback loops led us not only to make technical corrections but sometimes to completely redesign screen layouts or even simplify a step in the workflow. These processes reinforced that software development is not just about writing code, but a continuous journey of improvement and adaptation.
The biggest lesson I learned while developing ERP was that technology is just a tool. The real power lies in understanding the people within the organization, their ways of working, and shaping the software accordingly. An ERP project is an attempt to digitize a company’s soul, and this requires empathy and business knowledge far beyond technical skills.
What are your experiences on this topic? When did you learn the biggest lesson in a corporate software project? I’m eager to hear your thoughts in the comments.