What Enterprise Consulting Taught Me About Software
Enterprise consulting teaches you lessons that are impossible to learn in a startup environment. You see systems at a scale that reveals every flaw in design, every gap in governance, and every shortcut that seemed harmless at the time. You see what happens when software meets reality — the messy, unpredictable, high-stakes reality of organisations that depend on their systems to operate.
The first lesson is that data models are destiny. In every enterprise engagement I have worked on, the success or failure of the system was determined by the quality of the data model. Systems with clean, well-normalised, carefully constrained data models aged gracefully and adapted to changing requirements. Systems with ad-hoc, denormalised, constraint-free data models became progressively harder to maintain and eventually required expensive replatforming.
This is why every neart.ai product starts with the data model. Before we discuss features, interfaces, or user experience, we design the data. Every table, every relationship, every constraint, every index. The data model is reviewed by people who were not involved in designing it. Only when the data model is solid do we move to the logic layer and then to the interface.
The second lesson is that integration is where systems fail. Individual components usually work. The complexity — and the failures — emerge at the boundaries where components interact. API contracts that are ambiguous, data transformations that lose precision, error handling that assumes the happy path. Enterprise consulting exposed me to integration failures that cost millions of pounds and months of delay.
Our approach to integration is defensive. Every external API interaction is specified completely, including error scenarios. Every data transformation is tested with edge cases. Every integration has retry logic, circuit breakers, and fallback behaviour. We treat integrations as the most fragile part of the system and engineer them accordingly.
The third lesson is that compliance cannot be retrofitted. In financial services, I repeatedly saw organisations attempt to add audit trails, access controls, and data governance to systems that were not designed for them. The result was always the same — a bolted-on compliance layer that was expensive to maintain, incomplete in coverage, and brittle under change. The organisations that got compliance right were the ones that built it in from the start.
The fourth lesson is about team dynamics and knowledge management. Enterprise projects involve many people over long periods. Team members join and leave. Requirements evolve. The only thing that preserves continuity is documentation — specifically, living technical documentation that is maintained alongside the code. Specifications, architecture decision records, and operational runbooks are not optional. They are the memory of the system.
The fifth lesson is that testing is not quality assurance — it is risk management. In enterprise consulting, I saw the full spectrum of testing approaches. The teams with comprehensive automated test suites deployed confidently and recovered quickly from issues. The teams that relied on manual testing deployed nervously and spent weeks investigating problems. The return on investment in automated testing is not debatable — it is a fundamental engineering requirement.
The sixth lesson, perhaps the most important, is that technology serves people. Every system I built in consulting existed to help someone do their job better — process a claim faster, approve a transaction more safely, report a result more accurately. The technology was always the means, never the end. This sounds obvious but it is frequently forgotten in the excitement of building something technically impressive.
These lessons — data models matter, integrations fail, compliance is foundational, documentation is essential, testing is mandatory, and technology serves people — are not enterprise-specific truths. They are universal truths that I now apply to every product at neart.ai. The same principles that make enterprise systems reliable make small business tools trustworthy. The difference is scope, not rigour.