This project is going to be big, so I wanted to do research first, but I keep hearing that there's no right/wrong way of doing things, so I guess it'll mostly be a matter of figuring out a way to do it that's relatively clean and call it good. lol
The only good way of implementing things is the way it works... for you ;-)
In case you are new to Pascal/RAD/OOP, and have the luxery of having enough time to accomplish the task is to analyse a 'big' project beforehand and put some things on paper first (well, you can do that digitally as well, but you hopefully get the gist)
Try to make a list of all the different topics/subjects that your project requires, and try to get yourself familiar with these topics by making small (stand alone) experiments. That way you are able to easy spot your weaknesses and strengths, getting yourself familiar with things and how they work in/with FPC/Lazarus. In case you encounter issues, you can ask for help (or find an already existing answer) with asking relatively small simple questions that should be easy to answer and/or understand (also for yourself).
The biggest issue with splitting up big projects into smaller parts (sub projects) is that you don't get lost and loose sight on the bigger picture. You have to make it possible for the smaller parts to be 'connected' once you come to it. But, also that is a matter of hands on experience.
Back in the day one learned how to program big projects using flow-chart diagrams, splitting up each chart that harbours too much functionality into several sub-diagrams. That way you can still keep an eye on the bigger picture while concentrating on smaller parts of the project.
But, my comments are common goods for using whatever programming language. Still, i do believe it is good advise, especially when introducing yourself with new concepts and/or programming language. I realize it might not work for everybody out there (f.i. some rather develop on the flow).