After working in a manufacturing ERP for over five years, while also developing my own side products, I've frequently encountered the contradictions brought by corporate standardization. Specifically, I've observed a significant tension between the predictability provided by ERP on one hand, and the flexibility and rapid innovation I seek in my own projects on the other. This post will explain how these two worlds clash and how I address this situation.
Enterprise systems, especially ERPs, are built on standardizing business processes and running them in a structured manner. This approach is indispensable for large organizations, but it can be an obstacle for side products that require flexibility and rapid prototyping. In my opinion, this situation forms the basis of the question every tech person asks at some point in their career: "Couldn't I have moved faster and more freely?"
Advantages of ERP Standardization: Why Do We Go This Route?
Standardizing Enterprise Resource Planning (ERP) systems offers many advantages at first glance. Running all business workflows, from financial reporting to supply chain management, through a single system increases internal consistency and efficiency. While working in a manufacturing company's ERP, I repeatedly saw how critical this standardization was during IFRS integration and monthly closing processes. For example, having cost accounting processes run with the same template and rules every month minimizes error rates and simplifies audit processes.
This structure reduces operational risks, especially in large and complex organizations. Instead of different departments using their own systems, a central ERP ensures data integrity and increases coordination between different units. This allows core flows like "purchase, produce, ship, invoice" to be managed predictably. Last year, in a client project, when inventory from 15 different locations needed to be monitored from a single center, I once again realized the value of the centralization provided by a standard ERP module.
ℹ️ The Value of Standardization
Standardization of enterprise ERP systems is vital for data consistency, operational efficiency, and compliance, especially in large-scale and regulated industries. This minimizes risks while ensuring the stable execution of core business processes.
However, this robust structure can also be a straitjacket. The more precisely business processes are defined, the harder it becomes to deviate from those definitions. It is at this point that problems begin to arise for side products that require rapid change and customization. I have often questioned how this rigid framework imposed by ERP affects my creativity and my "let's try something quickly" philosophy.
First Signs of Flexibility Loss: The Prototyping Phase
When an idea comes to mind or I want to develop a quick solution to a problem, the first thing I think about is "how can I get a prototype out as fast as possible." In my own side products, this process is quite simple: with a FastAPI backend, a PostgreSQL database, and perhaps a Vue/React frontend, I can get something working in a few hours. However, when I try to apply the same approach in a scenario that needs to be integrated with an ERP system, things instantly become complicated.
For example, let's say I want to develop an AI-powered operator screen for production planning. This screen needs to read existing production orders from the ERP and write back new work orders. While a simple GET /orders and POST /orders API is sufficient for me, in the corporate world, this means a series of security policies, data transformation layers, authorization mechanisms (JWT/OAuth2 patterns), and audit logs. Recently, when I wanted to pull 50,000 rows of data from the ERP for a simple reporting tool, I had to retrieve this data not directly from the database, but through a specific API gateway, paying attention to rate limits, and passing through a special authentication flow. This process took me 3 days instead of 3 hours for a simple prototype.
# Simple data retrieval in my side product
import requests
response = requests.get("http://localhost:8000/api/production_orders")
orders = response.json()
print(f"Number of orders fetched: {len(orders)}")
# Similar operation in corporate ERP integration (simplified)
import requests
import jwt
# 1. OAuth2 token acquisition
token_url = "https://erp.example.com/oauth/token"
client_id = "my_client_id"
client_secret = "my_client_secret"
auth_payload = {"grant_type": "client_credentials", "client_id": client_id, "client_secret": client_secret}
auth_response = requests.post(token_url, json=auth_payload)
access_token = auth_response.json().get("access_token")
# 2. API call with Authorization and Rate Limiting
headers = {"Authorization": f"Bearer {access_token}", "X-Correlation-ID": "my-app-123"}
api_url = "https://erp.example.com/api/v1/production_orders?page=1&limit=1000"
erp_response = requests.get(api_url, headers=headers)
if erp_response.status_code == 429:
print("Hit rate limit, wait and retry.")
elif erp_response.status_code == 200:
erp_orders = erp_response.json()
print(f"Number of orders fetched from ERP: {len(erp_orders)}")
else:
print(f"Error occurred: {erp_response.status_code} - {erp_response.text}")
This difference has a direct impact on the speed of bringing a simple idea to life. In my small projects, when I see a problem or want to add a new feature, I can deploy and test it within a few hours. However, the strict integration rules imposed by ERP severely limit this flexibility. For me, the ability to "do things quickly" is a source of professional satisfaction. When I encounter these obstacles, I feel my motivation drop, and sometimes even good ideas fall victim to bureaucracy.
Data Access and Integration Challenges
One of the biggest problems with ERP systems is the difficulty of accessing the data within them. Corporate software architecture typically prioritizes data integrity and security, which restricts direct external access. When I wanted to develop an anomaly detection system for one of my side products using sensor data collected from production processes, accessing the raw data in the ERP's database became a real struggle. Instead of connecting directly to PostgreSQL, I had to retrieve data either through complex views or via specific ETL (Extract, Transform, Load) processes.
This situation also stems from the inflexibility of the data model. ERPs typically use tightly coupled schemas consisting of thousands of tables. While I only needed 10-15 fields for my project, I had to JOIN 5-6 different tables and write complex queries to access this data. This both reduces query performance and extends development time. Once, a query I wrote to pull basic information needed for a delayed shipment report joined 7 different tables and took 15 seconds on a 500,000-row dataset. I knew I could pull this data in under 100ms in my own system with an optimized index strategy (B-tree/GIN/BRIN).
⚠️ Data Access and Performance Limitations
Rigid data models and security policies in ERP systems can make fast and flexible data access, which is necessary for side products, difficult. This leads to complex queries, performance issues, and extended development times.
Furthermore, patterns like idempotency and transaction outbox in data integration become even more critical in an ERP environment. While I can implement a simple retry mechanism in my own system when an API call fails, when writing data to an ERP, I need to consider much more detailed scenarios to prevent the same operation from running multiple times. This also extends development and testing processes. Data security is another challenge; security layers like kernel module blacklists or SELinux/AppArmor profiles make direct access to the ERP database by an external application almost impossible.
Technological Dependency and Pace of Innovation
ERP systems are typically built on a specific technology stack, and this stack can remain unchanged for many years. This poses a significant restriction, especially for side product developers who want to use newer and more efficient technologies. In a client project, when I wanted to use the latest PostgreSQL features required by an AI model for production planning, it wasn't possible due to the old PostgreSQL 11 version the ERP was running on. Upgrading the ERP was a months-long project requiring testing hundreds of different modules, and expending that much effort for my small AI project was meaningless.
This technological dependency directly affects the pace of innovation. When I want to try a new language, a framework, or a database technology, I have to adapt to the ERP's ecosystem. While I can quickly spin up different databases or services with Docker Compose in my own side products, for ERP integration, I have to comply with the limitations of existing virtual machines, network segmentation (VLAN segmentation), firewall policies, and even existing Linux services (systemd units). This restricts me from making fine-tuned adjustments for performance-critical applications, such as choosing Redis's OOM eviction policy or dealing with PostgreSQL's WAL bloat issues.
🔥 Technological Shackles
The outdated technology stacks of ERPs create a significant innovation barrier for side products seeking new and more efficient solutions. Adapting to existing infrastructure often prevents making the best technological choices.
This often pushes me to look for the "ERP-compatible" solution, not the "best" solution. While I'm doing native package integration with Flutter and experiencing the latest Play Store publishing processes in my own mobile app (an Android spam blocker), having to integrate with an old Java-based middleware on the corporate side clearly demonstrates the technological gap. Such situations make me wonder, "Wouldn't it be better if I built my own system with this much effort?"
Operational Burden and Support Costs
When developing a side product, the process of deploying it live and then maintaining it is also affected by ERP standards. While I can deploy my applications in seconds using container orchestration (Docker Compose) on my own servers (my own VPS), this process is much longer and more cumbersome in a corporate environment. Modern DevOps practices like ensuring CI/CD reliability, implementing blue-green or canary deploy strategies, and doing dark launches with feature flags become almost impossible to apply due to the ERP's rigid change management processes and testing protocols.
When I integrate a part of my side product into the ERP, the operational burden of that part also becomes subject to the ERP's operations team or procedures. While I can check journald logs and cgroup limits when an error occurs in my own system, for a problem arising from ERP integration, I have to go through complex support processes. For example, I don't have the authority to check the ERP's Nginx reverse proxy settings for a timeout issue in an API integration, and it can take days to resolve this problem.
💡 Operational Decoupling
When developing side products, minimizing integration points with the ERP and ensuring as much operational independence as possible reduces maintenance burden and allows for faster problem resolution.
This situation can lead to side products or custom solutions being seen as "expensive" or "unnecessary." This is because the resulting operational burden and potential support costs can negatively affect the project's initial return on investment calculations. In my side products, such as my financial calculators or task management applications, since there are no such operational obstacles, I can code an idea within a few hours and deploy it live within a few days. This speed is unimaginable in a corporate environment. This also creates a personal space of freedom for me.
A Solution for Side Products: Strategic Decoupling
After discussing so many downsides, what do I do then? My approach has been to adopt a strategic decoupling model for side products while using the power of ERP for core business processes. That is, I see the ERP as a data source and the main processing engine, but I create my own "bounded contexts" where flexibility and rapid iteration are required.
This usually works as follows:
- Data Copying and Synchronization: I copy critical ERP data to a more flexible database for my side product (e.g., with custom partitioning strategies in PostgreSQL). This copying is done either with event sourcing patterns (listening to events from the ERP) or with ETL jobs that run at specific intervals. Thus, my side product can use its own optimized data model independent of the ERP's complex schema.
- Asynchronous Integration: When I need to write data to the ERP, I usually do so via asynchronous queues (message queues). My side product puts the necessary data into the queue, and ERP integration is handled by a separate service. This allows the side product to run without sacrificing performance, while also managing the processing load on the ERP side. When doing AI-based production planning in a manufacturing ERP, instead of writing the proposed plans directly to the ERP, we would put them into a "plan approval" queue. The ERP's own integration service would read from this queue and process the data. This way, the AI model's response time was not dependent on the ERP's integration speed.
- Microservice Approach: I usually develop my side products with a microservice architecture. Each small functionality is spun up as a separate service. These services use their own databases and communicate with the ERP only where needed, through minimal APIs or messaging. This way, changes made to one service do not affect others, and different technology stacks (e.g., FastAPI, Golang, Node.js) can be used easily.
- Observability and Monitoring: The biggest challenge of decoupled systems can be getting a holistic picture. That's why I establish a strong observability (metrics, logs, traces) infrastructure in all my side products. I collect metrics with Prometheus, store logs centrally with Loki, and do distributed tracing with Jaeger. This way, when a problem arises, I can quickly find the answer to "Which service encountered an error while communicating with the ERP?" I once experienced a routing flap issue in a distributed system, and this kind of monitoring was vital to understanding BGP routing decisions.
This approach, of course, brings its own challenges: data consistency risks, a heavier distributed system management load, and potential security vulnerabilities. However, for me, it's worth taking this trade-off to maintain the robustness offered by corporate ERP in core business processes while not losing the flexibility and innovation speed of my side products. I clearly see the benefits of this decoupling in my anonymous Turkish data platform or my Android spam application.
Conclusion
ERP standardization is an indispensable source of stability and efficiency for large organizations. However, this structure can impose significant restrictions on side products seeking rapid prototyping, technological innovation, and flexible data access. In my experience, this is not an "either/or" situation, but a trade-off that needs to be managed intelligently.
My personal philosophy is built on supporting the strong and slow ship of the corporate world with my own small and fast boats. While core and critical business processes flow standardly and securely within the ERP, I bring my niche needs and innovative ideas to life in my own separate, flexible, and rapidly developed systems. Finding this balance allows me to fulfill my corporate responsibilities and also feeds my passion for technology and my desire to "build things." In summary, ERP standardization reduces flexibility, but it is possible to manage the impact of this flexibility loss on side products with the right architecture and strategic decoupling. This has become part of my career, a journey that requires continuous learning and adaptation.
