The best starting point? A little less infrastructure.
Before choosing a database, a dashboard, or another service, ask what your project actually needs to do.
Every new project begins with a tempting list: a database, a content management system, an authentication service, a queue. Each has a purpose. The question is whether that purpose exists in your project today.
A small publication has a simpler first job: put useful writing in front of a reader. That is enough to guide the first round of decisions.
Begin with the reading experience
A visitor needs a page that loads, a headline that makes sense, and text that is comfortable to read. They need to find the next article and get back to where they started. None of those requirements automatically demands a database.
Static pages can meet those needs. The content is prepared during a build and served as files. When an article changes, another build produces the updated pages.
Let a real need introduce the next service
This does not mean that every site should remain static. Comments need somewhere to live. Accounts need an identity system. A large media library may benefit from separate storage.
The useful distinction is between a feature that exists on a roadmap and a feature that a reader can use today.
Start with what must work. Add complexity when it earns its place.
Keep a short list of the capabilities you are postponing and the conditions that would justify adding them. That makes a simple beginning a deliberate decision, rather than an accidental limitation.
A practical first milestone
For a publication, the first milestone might be a homepage, an article template, topic pages, and an author profile. Make those work on a small screen. Check that links lead somewhere useful. Then publish a real article.
You will learn more from that complete reading experience than from an impressive collection of services with nothing to read.