I know a couple guys in here who will tell you they just jump in and start writing code. I do that myself sometimes, and it's actually a legit technique called 'rapid prototyping'. The best way for you to approach it really depends on a number of things, like how many people will be working on it, what is the time frame to finish it, etc. A Software Engineering course will take you through a number of methods, but when you are first starting out, they like to have you draw up some plans before writing any code.
Object-Oriented programming (OOP) courses typically use
UML to organize their software. For database design, the most common way to model is with
ER Diagrams. You will need to understand (but may not need to know in great detail) how to normalize the DB model, but since your software involves dealing with bid amounts in real time, you will need to understand a bit about SQL transactions- essentially, how to configure your DB to make sure when 2 or more people pull the same record, they see the same data.
If you decide to go the OOP approach, here's a very brief overview of how they teach it:
Think of all the 'things' in your software that you will need to be able to describe. At this stage, it doesn't have to be formal, just use something like a mind mapper, where you could group related items together. Each of these things you identify could be a class.
For example, your platform has Users. It has Buyers and Sellers. So you could draw a circle for User, then 2 circles for Buyer and Seller that each connect to User. A Buyer needs to work with certain data, like which items have open bids, etc. A Seller has its own data that is unique to a Seller; but Buyers and Sellers are also Users. The User works with information that is common to both, like username, password, contact info.
By structuring your program in such a way (the fancy name is commonly called 'inheritance'), you can keep from having duplicate code in your Buyer and Seller, and ensure that the Buyer cannot access the sensitive data of the Seller, and vice versa.
Another item in your program could be a Bid, where the Bid might contain an offer amount, a reserve amount, the age of the Bid, the name of the Buyer who produced it, the name of the Seller who received it. You could also have a BidManager, whose main job is to collect bids and determine which one is the highest...
Once you have this stuff mapped out, converting it to formal UML and ER models is much easier. In the UML diagram, you will also lay out the functions that each class needs. This is where you will start thinking about the logic of how the different classes interact with one another.
After that, you could even write the empty classes and their method/function signatures, and put the comments in. And when you get to this point, you will be able to outsource the coding, and they will love you for giving them something that is well-spec'd out.
If you are doing it all in-house, take a look at some of the PHP frameworks, like CodeIgniter.
