It Started as Just a Window
At first, I only wanted to build a Store Window.
A small space inside a desktop-style website to display products. Nothing more than that. There would be product cards, categories, product detail, and maybe cart and checkout. Visually, it should still feel like part of the same world: window, toolbar, traffic lights, panels, and interactions that do not drift too far from the macOS-style language I had already been building.
But a store has its own way of becoming serious.
Once a product begins to have a price, stock, discount, photos, sizes, checkout, payment, shipping, tracking, and order status, I started to realize that this was no longer just a window.
It was becoming a system.
And when a feature becomes a system, the question changes.
It is no longer only:
How do I make it look good?
It becomes:
How do I keep it organized when the data grows?
How do I keep it comfortable for the user?
How do I make it manageable for the store owner?
How do I make it serious enough to accept real orders without making it feel like a stiff dashboard?
At that point, Store Window stopped being a visual experiment. It became a small exercise in how e-commerce can live inside a personal website without losing its character.
A Store Is Not Only a Place to Display Products
The easiest mistake when building a store is to think of it as a product page.
In practice, the product is only the surface.
Behind one simple product card, there are many small decisions:
- what should the product be called?
- which category does it belong to?
- is it still in stock?
- is it currently discounted?
- should the sale price look different?
- does the product have more than one photo?
- does it need size or variant options?
- can it be shipped from every branch?
- should the product still be viewable when it is out of stock?
These questions look ordinary, but they shape the shopping experience.
An out-of-stock product can be hidden. But for the user, it may still be useful to see the detail. They may want to understand the shape, the normal price, or simply wait for a restock. So the "Out of Stock" badge is not just a label. It is a way for the store to speak honestly without cutting off the user's curiosity.
Discounts are similar.
A crossed-out price is common, but it is not always the best fit. For a store that wants to feel clean, showing the sale price in a different color can feel calmer. A discount badge does not need to shout. It only needs to be clear enough.
This is where I began to feel that a good store is not only about showing products.
A good store is a conversation between visuals, data, and trust.
Front Office and Back Office
As Store Window started to grow, I began to separate two sides that are actually very different.
The first side is the front office.
This is what the user sees: product list, categories, product detail, cart, checkout, order detail, tracking, and every interaction that happens when someone wants to buy.
The second side is the back office.
This is what the store owner sees: which products are active, which categories exist, how much stock is left, what the price is, whether there is a discount, which photo is used, which branch becomes the shipping origin, which order has been paid, which shipping detail needs attention, and so on.
The two sides are connected, but they should not feel the same.
The front office should feel light, clear, and reassuring.
The back office should feel organized, accurate, and editable without becoming intimidating.
In many systems, the back office immediately becomes a large dashboard full of tables, buttons, and technical labels. That is not wrong. For many businesses, it is probably the right approach.
But for a personal website that has been built with a desktop-style language, that approach can feel like something attached from the outside.
So the more interesting question appeared:
Can the store CMS live inside Settings Window?
Not as a foreign dashboard, but as a natural part of the same system.
Settings Window as a CMS
At first, Settings Window was not that important.
It mostly contained small preferences, cosmetic controls, and functions that did not deeply affect the main system. But as the store became more serious, Settings Window became the most reasonable place for the back office.
Because settings, in a broader sense, are not only about appearance.
Settings are where a website is managed.
Inside it, the store owner can see the general summary, orders, store config, branches, categories, products, and eventually maybe users or inventory in more detail. With that, Settings Window changes from a cosmetic window into a control room.
What I find interesting is that this is not only a feature change. It is a change in meaning.
Settings Window no longer only answers the question:
What visual preferences does this website have?
It also answers:
How does this website operate?
For a small e-commerce system, that feels more honest. The store does not need an admin panel that feels too enterprise from the beginning. It needs a space that is serious enough, but still connected to the character of the website.
That is why I became more interested in making Settings Window the CMS, instead of creating a separate dashboard whose design feels detached from the main world.
A CMS does not always have to look like a CMS.
What matters is that it is secure, clear, and usable.
The Hard Part Is Not CRUD
Technically, CRUD is not the hardest part.
Creating a product, editing a price, changing a category, uploading a photo, or saving data to Firestore can be explained quite directly.
The harder part is making all of it feel like part of the same product.
Row height has to stay consistent.
Typography has to feel like it belongs to the same family.
The edit button should not suddenly feel like a button from another admin page.
The toolbar needs the same rhythm.
The plus, refresh, filter, and search icons need to feel familiar.
Product detail inside Settings Window should follow the feeling of Product Detail inside Store Window, because both are talking about the same object from different perspectives.
These are small details, but this is where a system starts to feel mature or patched together.
CRUD makes the feature work.
Consistency makes the feature trustworthy.
And in e-commerce, trust matters.
Users may not know whether the row height matches Finder. They may not use terms like "inline editor" or "data model". But they can feel whether an interface is calm, intentional, and well kept.
The same is true for the store owner.
If the admin area feels messy, editing products becomes tiring. If the editor is too far from the product display, the owner has to imagine the final result again and again. But if the editor follows the shape of the product detail, editing feels closer to what the user will actually see.
That is why inline editing became interesting to me.
Not because it looks advanced.
But because it reduces the distance between managing data and seeing the product.
The Data Model Starts Demanding Discipline
When products are still static, the structure can feel simple.
But once products move to Firestore and images move to Storage, the data model starts demanding discipline.
A product cannot only have a name and a price.
It needs a stable slug, category, stock, price, salePrice, imageAssets, shipping dimensions, content, and active status. Product photos should not only be an array of URLs. It is better to have metadata that is clear enough: fileName, url, storagePath, and an order that can be controlled.
Categories also need thought.
Should category only be a field inside the product?
Or should category have its own collection?
For a store that may grow, a category collection feels healthier. It can store label, active status, product count, and later maybe ordering or other metadata without guessing everything from products one by one.
Branches are similar.
A branch is not just an address. It is a shipping origin. It has areaId, latitude, longitude, contact, and a direct relationship with shipping rates. If stock per branch is introduced later, the branch becomes an important part of the checkout decision.
The further the store grows, the clearer it becomes that data cannot be arranged only so it works today.
Data has to be arranged so the next decision remains possible.
That is one of the most important lessons from building a small store: do not make the data model too large too early, but do not make it so narrow that every small improvement becomes a painful migration.
Payment and Shipping Change the Seriousness of the Store
A store begins to feel real when payment and shipping enter the system.
Before that, it can still feel like a catalog.
But once the user can check out, pay, receive an order number, see payment status, choose shipping, and open tracking, the system enters the territory of trust.
Here, the UI cannot only be beautiful.
It has to be clear.
If payment is pending, the user needs to know they can continue payment.
If payment is paid, the user should be taken to the relevant order.
If an order has a tracking link, the user needs to see it in the right place.
If an instant delivery order has driver name, phone, plate number, and photo, that data should appear neatly in order detail, not stay hidden inside Firestore.
Shipping also has its own complexity. A rate is not only a number. It is affected by origin, destination, courier, service type, areaId, weight, dimensions, and coverage. If an external integration changes, the UI needs to be flexible enough not to be visually locked to one vendor forever.
At this point, I felt even more clearly that e-commerce is not only about transactions.
E-commerce is a small trust system.
Every status, label, order detail, email, notification, and tracking link contributes to that trust.
Why Not Just Make a Regular Dashboard?
This is a fair question.
Why not build a regular admin dashboard?
The simple answer is: I could.
And for many businesses, that may be the best choice.
But in the context of this website, I want the store to feel like part of the same world. The user sees Store Window. The owner manages it from Settings Window. Both still live in the same visual language.
That makes the system feel more whole.
It does not mean everything has to be cute or experimental. In fact, the opposite is true: the more playful the surface is, the more disciplined the foundation needs to be.
Store Window can feel elegant.
Settings Window can feel like part of the desktop.
But payment has to be safe.
Shipping has to be accurate.
Orders have to be stored correctly.
Webhooks have to be reliable.
Email has to be clear.
Statuses have to be mapped from the right source.
So the difference is not between "serious" and "playful".
The difference is between a system that has character and a system that loses it.
I want the first one.
A CMS That Feels Connected to the Product
There is one thing I like about this approach: the CMS does not stand as another world.
When editing a product, I want the shape to stay close to product detail. The photos still feel like a carousel. The product name remains in a familiar position. Price, discount, description, details, size chart, and shipping are still read as parts of the product, except they become editable when edit mode is active.
This way, the editor does not feel like a long form that is far from the final result.
It feels like the product is being opened layer by layer.
For photos, the logic also needs care.
In Add Product, photos should stay as a draft first. The user can preview, reorder, remove, and only when the product is created should the files be uploaded to Storage and the URLs saved to Firestore.
In Edit Product, the approach can be more flexible, but it should still feel safe: local preview matters, at least one image should remain, and changes should be clear before they are saved.
Small details like this decide whether a CMS feels comfortable or exhausting.
Because a good CMS is not only about being able to change data.
A good CMS makes change feel controlled.
Lessons from Store Window
The more I built Store Window, the more I felt that even a small e-commerce system needs serious architecture.
Not a massive architecture.
But an architecture with clear boundaries.
Front office and back office need to be separated.
Data display and data editing need to stay closely related.
Product detail for the user and product detail for the owner need to feel like they belong to the same family.
Category, product, branch, order, payment, and shipping need their own places.
External integrations like payment gateways and shipping APIs need to follow official documentation, not guesses from trial and error.
SEO still needs to be protected, because products and writing are part of the public surface of the website.
And just as important: the UI should not lose its feeling.
Because for an indie store, feeling is part of the brand.
People do not only buy from a system.
They buy from an experience that makes them trust.
Closing
Building Store Window made me see e-commerce a little differently.
A store does not have to immediately feel like a large dashboard.
It can begin as a small window.
It can grow slowly.
It can have clean product cards, serious checkout, clear order detail, and a Settings Window that works as a CMS.
It can remain personal without becoming careless.
It can be playful without losing discipline.
It can feel like a natural part of the website, not a feature attached later.
In the end, Store Window is not only about selling products.
It is about how a personal website begins to accept transactions, manage data, protect trust, and still keep its own character.
And to me, that is far more interesting than simply making another ordinary store page.
