What actually makes a custom software project bigger than it looks?

Count edges, not screens

When people describe a project they describe screens, because screens are what they can picture. But a screen is largely a solved problem. What consumes the work is every place the system touches something it does not control.

Each external system adds authentication, rate limits, error handling, a data model that does not match yours, a sync strategy, and a plan for what happens when it is down. Two integrations are not twice one integration, because now you also have to decide which one wins when they disagree.

The four drivers that matter most

• Integration count. Every system you read from or write to is its own small project with its own failure modes.
• Role count. Three roles with different permissions means three sets of rules, three test paths, and an admin surface to manage them.
• Statefulness. A report that reads live data is simple. A system that stores state and must keep it correct through edits, reversals and backdated changes is a different class of problem.
• Exception density. The real question is not what the process is, but how many legitimate variations exist. Multi-location businesses usually discover they have more than they thought.

The requirements that hide until late

Three things reliably surface after a project is underway and reliably expand it: audit history (who changed what and when), permissions that vary by location or role, and the need to correct past data without destroying the original record.

None of these appear in an initial description because nobody thinks of them as features. They are assumptions. Asking about them during scoping is the single highest-value hour in the whole engagement, which is why serious development work starts with those questions rather than with wireframes.

How to make a big project smaller

You reduce scope by cutting edges, not features. Deliver against one integration first and add the second later. Ship with two roles instead of five. Make the first version read-only against the source system so you do not have to solve write conflicts on day one.

This is also how you find out whether the thing is useful before you have paid for the hard parts. A read-only custom dashboard built on real data answers most of the questions a full application would, and it tells you which of the remaining features people actually reach for.