Insights · 5 min read
Enterprise software development is won or lost on integrations, permissions, and audit trails, not the demo screen. Here is where the real schedule lives.
By GGP Editorial
Most enterprise software projects are sold with a demo and delivered on a spreadsheet. The demo shows a clean dashboard. The spreadsheet, if you read it honestly, shows six months of integrations, migrations, and permissions nobody put on the first slide.
I have built enough enterprise systems to know the demo is the easy fifth. The other four fifths are the boring parts, and they are the parts that decide whether the project ships. Get them right and the demo is the easy part. Get them wrong and the nicest UI in the world still misses the deadline.
An enterprise does not start from a blank page. It already runs on an ERP, a few databases that predate the current team, and a folder of spreadsheets that are somehow load-bearing.
The new system has to talk to all of it. That is usually where the real calendar lives, because every integration carries assumptions: field mappings that do not match, a legacy API that only speaks a dialect from 2008, a nightly batch job that has to keep running while the new system boots up next to it. We budget for integration as its own workstream, not as a footnote on the UI estimate.
Legacy migrations also move slower than anyone expects. You are not just moving rows; you are moving meaning. A "customer" in the old system might be three records in the new one, or the reverse. We run a parallel phase where the old system keeps working while the new one proves itself against it, then cut over once the numbers match to the last cent.
Screens get redesigned every couple of years. The data model is what you are stuck with. Get the entities wrong and every future change costs twice as much, because you are not editing a form, you are migrating records that already matter to someone.
For financial and property management systems, the model has to carry the rules that make the business legitimate: a ledger that balances, a lease that knows its start and end, a payment that can be traced back to its source. We build those systems on Java and Spring Boot with MySQL for the ledger, because when something is money-adjacent, the last thing you want is a framework that treats your schema as an afterthought.
For a property leasing system, the model has to capture things like prorated rent, a deposit tracked separately from rent, and a lease that can be renewed or terminated early without breaking the payment history. For a financial system, it is the double entry: every number has to trace to another number, and the audit has to survive a regulator poking at it two years later. None of that shows up in a dashboard demo.
Ask a vendor for an enterprise estimate and watch where they get vague. It is almost always these three lines.
| Line item | Why it eats the budget |
|---|---|
| Roles and permissions | Every department wants a slightly different view of the same data |
| Audit trails | Who changed what, when, and why, and can you prove it later |
| Reporting | The report the CFO wants is never the one you designed |
Permissions are the classic. Finance sees one set of fields, operations another, and the person who manages both sees a third. Doing that properly means modelling access at the data level, not hiding buttons in the UI. It is tedious, and it is exactly the kind of thing that turns a "finished" system into a security review failure.
Reporting deserves its own warning. The first report a stakeholder asks for is rarely the one you built. The CFO wants a cash flow view, operations wants aging, and they both want it exportable to a spreadsheet. If reporting is bolted on at the end, every new request becomes a code change. If you model the data cleanly up front, most reports become a query.
We are a software firm with more than 40 engineers who have shipped over 300 projects, and our core stack is Java, Spring Boot, Spring Cloud, MySQL, Redis, and Nginx, with Vue and React on the front. We have built financial systems, property management and leasing systems, and online payment flows, and we deliver to clients in Brazil, South Africa, Singapore, and the US.
The part of that I would draw your attention to is not the stack. It is that enterprise work rewards the team that asks about the legacy ERP on day one, not week ten. We would rather start with the boring parts and let the demo take care of itself.
Tell us what you are building and where you are today. We typically reply within 24 hours.
