Standard Objects vs Custom Objects

Almost every business that could ever use Salesforce has customers, contacts, and (often) sales opportunities or support cases — so Salesforce builds Account, Contact, Opportunity, and Case into every single org from day one, pre-loaded with sensible fields, page layouts, and even some automation. This saves every customer from reinventing the same wheel.

You never had to create the Account object — it was already there when the org was created, which is exactly what let you build the HelloWorld class in Module 1 without first "setting up a database."

No standard object exists for, say, a university's Course_Enrollment__c, a manufacturer's Production_Batch__c, or a bank's Loan_Application__c. For these, you create a custom object — you design its fields, its relationships, everything, from scratch through Salesforce's point-and-click Object Manager (no code required to create the object itself).

A custom object's API name always ends in __c (for "custom") so Apex and the platform can always tell it apart from a standard one.

A university on Salesforce might use the standard Contact object for students (a person is a person, and Contact already has Name, Email, Phone) — but build a custom Course__c object and a custom Enrollment__c object to link students to the courses they're taking, since nothing like that exists out of the box.

• Always check whether a standard object already fits before building a custom one — reinventing Contact as Person__c is a classic beginner mistake that creates years of avoidable maintenance work.
• Custom objects are not a lesser or "hacky" option — plenty of serious, well-architected Salesforce orgs are built mostly on custom objects, because most businesses have needs standard objects were never designed for.