You are not seeing the big picture here. Do you know the difference between London's "Big Ben" clock and a cheap Timex wrist watch? The size of the gears - but not the complexity. There is no difference in complexity for clocks that tell time on the 12-hour or 24-hour clock - both have gears that do 60:1 reduction for minutes and for seconds. But some are huge because they drive big "hands" while some are tiny because they are small enough to wear on your wrist.
Similarly, a "small" database that acts as a "general ledger" package is just as complex as one that drives a 50,000 employee factory. The mistake is confusing physical size of the company and procedural complexity of the corresponding package requirements. You use the same process for ONE transaction as you do for 10,000 transactions.
In the end analysis, it is your project, your problem. I can only cheer you on from the sidelines and offer advice. My first level of advice is to take the time to develop a procedural specification before you do any coding. My second level of advice is to clarify to the managers that your product will not be fully functional for a long time, and the size of the company has NOTHING to do with the complexity of the project.