I came into this as a graphic designer, not a software engineer. I didn't have a computer science background, and a lot of what BrandStack needed — authentication, databases, payments, deployment — was new territory for me when I started.
What made it possible wasn't some shortcut. It was breaking the problem down into pieces I could actually learn: how user accounts work, how a database should be structured so one person's data never leaks into another's, how to move from test payments to real ones without breaking checkout for actual customers.
I made real mistakes along the way. Early on, every user shared the same underlying brand data because I hadn't scoped the database correctly to each account — a serious bug that I only caught by testing with two separate accounts myself. Finding and fixing that taught me more about proper application architecture than any tutorial could have.
I don't think being a designer first is a disadvantage for building product. If anything, it means the interface and the experience get real attention, not just the backend logic. But it does mean being honest about what you don't know yet, and being willing to slow down and actually understand a problem instead of copying a fix you don't understand.
BrandStack is still a work in progress. But it's a real, working product — built by someone who had to learn most of this from scratch, in public, one bug at a time.
Top comments (1)
Multi-tenant data isolation is one of those things that seems trivial until it bites you. I went through something similar — shared state between users that I only discovered when I tested with two accounts side by side.Being a designer first is actually a huge advantage. Most solo SaaS products fail because the UX is terrible, not because the backend is weak. You're starting from the opposite problem.What's the stack looking like under the hood? Always curious what designers end up choosing when they build from scratch.