16 Lessons From Building Business-Critical Software for Growing Companies
Sixteen years of building software that businesses run on teaches you things no course covers. Not the technology itself, but the decisions around it. What to do before the first line of code is written. What breaks a project that looked solid on paper. What separates software that gets adopted from software that gets worked around.
These are the lessons that shaped how we work at 2Base. They come from projects delivered across the globe, across industries including logistics, finance, professional services, healthcare, and operations. Some were learned the easy way. Most were not.
This is not a list of best practices from a textbook. It is a record of what we have seen happen, repeatedly, when software projects go well and when they do not.
16 years of building business-critical software across the globe. These are the lessons that shaped how we deliver
The most expensive software mistakes are not technical. They are organisational. The code is rarely where the problem lives
Before You Write a Line of Code
The decisions made in the first few weeks of a project determine more of the outcome than anything that happens during development. These lessons are about what has to be true before building begins.
1. Understand the operation before designing the solution The biggest source of rework in software projects is a requirements document written before the business process was properly understood. Before designing anything, spend time with the people who actually do the work. Watch how they do it. The system they describe in a meeting is rarely the system they actually use day to day. |
2. Define what done looks like in business terms, not feature terms A project without a clear business outcome definition will never officially finish. It will just accumulate scope. Before development begins, write down what success looks like: what takes less time, what no longer requires manual effort, what a manager can now see that they could not before. Features are the means. Outcomes are the measure. |
3. Map the dependencies before you scope the build Every business system has more connections than anyone remembers. Data flows, manual bridges, spreadsheet exports that other teams rely on, integrations that were built years ago and never documented. These dependencies are where projects break at go-live. Find them before you scope, not after. |
4. The data problem is almost always bigger than the software problem In the majority of legacy modernisation projects, the data has not been maintained with the same discipline as the system. Duplicates, inconsistencies, fields used for purposes they were not designed for, records that exist in one system but not another. The data audit should happen before migration planning begins, not during it. |
Signs the preparation work has been skipped
• The project kick-off happens before the current process has been fully mapped
• Success is defined as 'the new system is live' rather than a measurable business outcome
• The data migration plan is described as 'we will move everything across'
• No one has asked who owns the decision when scope needs to change
During the Build
Development is where the plan meets reality. These are the lessons about how to manage that gap without losing the project.
5. Scope will change. How you handle it determines the outcome Scope change is not a sign that something has gone wrong. It is a sign that the business and the development team now understand the problem better than they did at the start. The projects that struggle are not the ones where scope changes. They are the ones where scope changes are handled without documentation, without a decision on what to drop, and without honest conversation about what the change costs. |
6. Build for the person who will maintain it, not just the person who will use it Software written to impress at demo rarely survives contact with a team who needs to extend it two years later. Business-critical systems get modified, extended, and handed over. The code that serves a business longest is the code that another developer can understand, change, and trust without needing to speak to the person who originally wrote it. |
7. Test against real business scenarios, not just technical requirements A system can pass every technical test and still fail in production because no one tested it against the edge cases the business actually encounters. Commission arrangements that change mid-year. Orders that come in at 11:58pm. Customers who exist in two systems with slightly different spellings of their name. These are the scenarios that break software. They need to be in the test plan. |
8. Visible progress is not the same as real progress A project that reports green every week and then struggles at go-live is more common than a project that flags problems early and addresses them. Weekly demos of working software against real business scenarios are more valuable than status reports. If something is not working the way the business expected, that information needs to surface in week two, not week twelve. |
A system that works in the demo and breaks in production is not a technical failure. It is a testing failure. Real business scenarios need to be in the test plan from day one.
Go-Live Is Not the End
The go-live date is not the finish line. It is the point at which the project becomes real. These lessons are about what happens after the system is switched on.
9. Adoption failure causes more lost ROI than technical failure The most consistent cause of software that does not deliver its expected return is not a bug or a missing feature. It is a team that found ways to work around the new system and quietly reverted to the old habits. Adoption requires a plan, not just training. It requires understanding why people resist change and addressing that directly, before go-live rather than after. |
10. A controlled pilot saves more than it costs Going live with one business unit, one process, or one geography before full rollout is one of the highest-return decisions a project sponsor can make. It surfaces integration issues, data problems, and adoption friction in a contained environment where they can be fixed without affecting the whole business. Every hour spent on a pilot saves multiple hours of crisis management post-launch. |
11. The transition period productivity dip is real and should be budgeted for Every system replacement has a period after go-live when productivity is lower than it was before. People are learning new workflows, encountering edge cases, and rebuilding habits. If this is not planned for, it creates pressure to cut corners, roll back features, or declare the project a failure when it is actually progressing normally. Plan for the dip and communicate it to stakeholders before it happens. |
12. Document the decisions, not just the code The knowledge that makes a software system trustworthy over time is not only in the code. It is in the decisions: why a particular calculation works the way it does, why a specific workflow was designed with that constraint, what the business rule is that sits behind a particular validation. When that knowledge exists only in the memory of the person who built the system, it leaves with them. |
From the field : insurance marketing organisation, United States
When we started working with a national insurance marketing organisation, the brief was to rebuild an aging platform that had reached its performance and scalability limits. What the discovery phase revealed was that the real complexity had nothing to do with technology.
The compensation logic that governed how thousands of producers were paid had never been fully documented. It lived in a combination of partially hardcoded rules, spreadsheet-managed overrides, and institutional memory held by a small number of long-tenured staff. The carrier integration layer was documented for standard cases but was dependent on manual intervention for a long tail of edge cases that occurred frequently enough to consume significant time. Licence validation across thousands of producers was handled through a manual checking process with no automated safety net.
None of this was visible in the initial brief. It only emerged because the team spent significant time mapping the business logic before touching the architecture. That mapping changed what was built and the order in which it was built. The result was a platform built around the business's actual complexity rather than a faster version of the system it replaced. Lesson: the business logic is always more complex than the brief suggests. The teams that find this out before the build begins are in a fundamentally different position from the ones that find it out during it.
The Long View
The businesses that get the most value from their software over time are not always the ones that built the most sophisticated systems. They are the ones that made better decisions about what to build, how to maintain it, and when to change it.
13. Build for where the business is going, not just where it is now Software built precisely to the current state of a business often becomes a constraint within two years. The design decisions that create the most long-term value are the ones that account for growth: data structures that can accommodate new product lines, workflows that can be extended without a full rebuild, integrations designed with future connections in mind. This is not about over-engineering. It is about not designing yourself into a corner. |
14. The cost of not deciding is not zero Many technology decisions that get deferred do not disappear. They accumulate. A database that was not cleaned two years ago is harder to clean today. A system that was not designed to support a new business model will need to be rebuilt rather than extended. The cost of inaction compounds in software the same way technical debt compounds in code. Deferring a decision is a decision with its own cost. |
15. The right technology choice depends on the business, not the trend The best technology for a given business problem is the one that the team can build, maintain, and extend reliably over the life of the system. The most modern framework is not always the right answer. The newest AI capability is not always the appropriate investment. Technology decisions made to follow industry trends rather than to solve specific business problems produce systems that are impressive to describe and unreliable to depend on. |
16. A good delivery partner asks about operations before they ask about technology After 16 years, the clearest signal that a software engagement will go well is this: the partner spends more time in the first conversations understanding how the business operates than explaining what they can build. The technology is rarely the hard part. Understanding the business well enough to build the right thing is where the work actually is. A partner who gets to technology before they understand operations will solve the wrong problem efficiently. |
The lessons in summary
• Understand the operation before designing the solution
• Define success in business outcome terms, not feature terms
• Map dependencies before scoping the build
• The data problem is almost always bigger than the software problem
• Scope change handled well is a sign of a healthy project
• Build for the person who will maintain it, not just who will use it
• Test against real business scenarios, not just technical requirements
• Visible progress is not the same as real progress
• Adoption failure causes more lost ROI than technical failure
• A controlled pilot saves more than it costs
• Budget for the transition period productivity dip
• Document decisions, not just code
• Build for where the business is going, not just where it is now
• The cost of not deciding is not zero
• The right technology choice depends on the business, not the trend
• A good delivery partner asks about operations before technology
Take the Free Operational Technology Readiness Assessment
We offer a structured 30-minute operational technology assessment for growing businesses over the globe. In that conversation, we will help you identify where your current systems are creating friction, where your data gaps are, and whether your current setup is a foundation for growth or a barrier to it.
What the assessment covers
• Where manual effort is substituting for what your systems should do automatically
• Where your data gaps are relative to where the business is going
• Whether your current setup is ready for AI investment or needs foundational work first
• What a realistic, prioritised improvement path looks like for your specific situation
The assessment stands on its own. Book your free 30-minute review at assessment link
