Editorial storefront design
The landing page is built around airy whitespace, restrained motion, and botanical illustration instead of loud ecommerce banners. The interface tries to feel curated rather than cluttered.
About Botanika
A botanical storefront shaped like a calm, modern studio.
Botanika was designed as a college project that treats plants, prints, and home styling as one connected experience. Instead of building a generic store, the project leans into editorial storytelling, a soft natural palette, and a cleaner account flow that feels more like a studio visit than a crowded marketplace.
The goal was to prove that a zero-funded frontend can still deliver thoughtful UX: curated product cards, a protected admin surface, customer profiles, order history, and a Firestore-backed data model that keeps the project lightweight enough for student hosting constraints.
Zero-funded
The project intentionally uses Cloud Firestore only, avoids Firebase Storage, and stores small image uploads as base64 so the whole system can run within a student-friendly budget.
What the project is trying to show
- A multi-page storefront can still feel premium without a heavy framework.
- Realtime product and account flows are possible with a minimal Firebase footprint.
- Interface polish matters just as much as backend connectivity in a college submission.
Project pillars
Three decisions shaped the entire build.
Every major feature in Botanika had to support one of these goals: a strong presentation layer, a realistic customer journey, and an architecture that is cheap enough to run for a student project.
Real shopping flow
The storefront includes profiles, cart state, order history, admin product control, and provider-based auth so the experience behaves like a real commerce product instead of a static mockup.
Budget-aware engineering
Using Firestore only keeps infrastructure simple. The tradeoff is that image size must stay small, security rules matter a lot, and the data model has to be scoped carefully to user ownership.
Build timeline
How the experience was structured.
Craft the public brand layer
The project starts with the landing page because it sets tone, hierarchy, typography, and the emotional quality of the brand before any account or admin logic appears.
Connect customer flows to Firestore
Products, carts, orders, and profiles were moved into Cloud Firestore so that customer state survives refreshes and can later be managed from the admin dashboard.
Separate the admin surface
The admin area was intentionally kept distinct from the storefront to show role-based UX, protected inventory controls, and a clearer mental model of what belongs to staff versus customers.
Technology choices
Chosen for clarity, not trend chasing.
Why plain HTML, CSS, and JavaScript
- The code stays readable for grading, demos, and future iteration.
- The project can be deployed as a simple static site on Netlify.
- Each page can be reasoned about without framework-specific tooling.
Why Cloud Firestore only
- No paid infrastructure is required for the current project scope.
- Data can update in realtime without building a custom backend.
- Careful rules can still separate public catalog reads from protected user data.
Next steps
Explore the project like a user, then like an operator.
You can browse the storefront publicly, review the care guidance, and then move into account creation or admin testing once Firestore rules are published and an admin user has been promoted.