Skip to content
Build in Public

Day one of an empty repo (the good kind of scary)

There's a specific feeling to an empty repository. Anyone who's started something from nothing knows it. It's the same feeling as a blank page, a fresh…

SD
Shubham Datarkar
· 3 min read
Updated

There's a specific feeling to an empty repository. Anyone who's started something from nothing knows it. It's the same feeling as a blank page, a fresh notebook, the first morning of a trip. Total possibility and total terror in the same breath. Nothing is broken yet. Nothing is decided yet. Everything you type today, you'll be living with for months.

I ran the command. npx create-next-app. First commit. A folder appears with my product's name on it and absolutely nothing inside that matters. The dev server boots, a default page renders in the browser, and I just sat looking at it like an idiot. Hello. Day one.

And then immediately, the decisions start, and they don't stop.

The first real one: folder structure. Where does the marketing site live versus the actual app versus the admin panel? This sounds trivial. It is not. Get it wrong and in two months every new feature fights the layout. Book A Sloth has three distinct worlds — the public pages a stranger sees, the dashboard a host logs into, and the admin tools I use to run the platform. I sketched out how those three would live side by side before I wrote a single feature, because retrofitting structure later is one of the most expensive mistakes you can make. Cheap now, brutal later.

Then I set up the Supabase project and immediately had to wrap my head around the thing that trips everyone up: the two keys. There's an anon key that's safe for the browser, and a service-role key that has full power and must never leave the server. Getting this mental model right on day one matters, because it decides who's allowed to touch the database and from where. I drew it on paper. The browser gets the weak key and can basically only check "who's logged in." My server gets the powerful key and does all the real work. Server is the gatekeeper. Browser is a guest. (This decision comes back to bite me later — foreshadowing — but on day one I felt very smart about it.)

Next, the data. Not the whole schema, just the three tables everything else hangs off: profiles (the hosts), services (what they sell), bookings (the whole point). Three tables. I resisted the urge to model everything — payments, plans,

notifications, badges, all of it. That's a trap. On day one you model the spine and nothing else, because you don't yet know enough to model the rest correctly. You'll guess wrong. Guess less.

One more thing I locked in early, almost on instinct: the public URL shape. bookasloth.com/:username. Every host gets their name as their page. I decided that on day one and never touched it again. Some decisions you want to make early and freeze, so you stop spending energy on them.

Then — the small win. The whole reason day one is good and not just scary. I wired up real Supabase data, threw it onto a page, and saw an actual record render in the browser. Not a default template. Mine. My data, my page, my product, breathing for the first time.

It does almost nothing. No payments, no auth, no booking. Just a name on a screen that came from a database I set up an hour ago.

But it's alive. And on day one, alive is the only milestone that counts.

Tomorrow: I build the first page that actually looks like something — the public profile — and have my first "oh, this could be nice" moment.

by Shubham DatarkarBuild in Public

Reactions

How was this article?

Newsletter

Never miss the next one

Get the latest playbooks, build logs, and the occasional unpublished idea straight to your inbox. One signal a week — no noise.