The scale of the project provides context
I built an entire enterprise system on my own. And do you know what the hardest part was? It was not coding.
In the technical documentation dated September 29, 2026, the project inventory recorded 13 functional modules, 347 HTTP route declarations, 37 SQL migration files and 93 test files, along with hundreds of functions and methods across its core components. CRM, operations management, contracts, finance, integrations and automation were all part of the scope. I had to give all of it a coherent structure.
Those figures describe the documented structure of the project at that point in time. The real complexity lay in the relationships between its parts: how information moved, which rule governed a decision and what needed to happen for different departments to work within the same platform.
Understanding the business changes the implementation
I had to understand business rules, interpret internal policies and model financial processes. That meant understanding what each step represented for the people doing the work. A screen could look simple while the process behind it involved decisions, exceptions and responsibilities shared across several departments.
When a sale creates work for operations, and completing that work has financial consequences, every handoff needs to make sense. Sales needs to know what it is handing over. Operations needs enough context to carry out the work. Finance needs to understand where the amounts come from and the conditions under which they can be recorded. The architecture needs to preserve that coherence throughout the process.
That work gave software development another dimension. Before deciding how to implement a feature, I needed to understand the decision it represented, the information supporting that decision and how its outcome would affect the rest of the business.
A small change can reach across the system
A contract rule can affect a financial calculation. A status change can trigger an automation. Information changed at its source can appear in an integration, a report or another team's daily workflow. The impact of a change depends on those relationships, even when it takes very little code to implement.
You also need to define what happens when things do not follow the ideal path. An integration may receive the same request more than once. An operation may fail after completing only part of its work. A retry needs clearly defined behavior so it does not repeat effects that have already occurred. Building the solution means thinking through these situations and making its behavior understandable to the people using it.
That is why complexity cannot be measured simply by the amount of code written. Often, the hardest decision is understanding a dependency and designing a consistent rule before writing the implementation.
Features need to make sense in day-to-day operations
Knowing how to develop software does not necessarily mean knowing how to build a business solution. There is a substantial difference between implementing a feature and understanding the economic and operational impact of what it delivers. Assessing that impact requires looking at the complete process the system supports.
A calculation needs to retain the context that explains its result. A workflow needs to make clear who can move it forward and under what conditions. An integration needs to keep the systems involved consistent with one another. Tests, documentation and validation with the people running the operation help establish whether those decisions have been represented correctly. The goal is for departments to trust the information and keep their work moving.
Team size cannot replace an understanding of the problem
This experience connects directly to how I assess technology professionals, projects and teams. Having fifty developers achieves little if no one understands the problem that needs to be solved. The ability to write code needs to go hand in hand with the ability to interpret the business and make decisions about the solution.
A lean team can also deliver complex systems when it has technical expertise, a view of the system as a whole and an understanding of the business. Any assessment needs to consider the coherence of the architecture, how the operation works and the ability to maintain and improve what has been delivered. Counting people, files or lines of code in isolation leaves out an essential part of that work.
Ultimately, the value of a system is not determined by its lines of code. It is determined by the ability to turn complexity into something that actually works.