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 (3)
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.
Genuinely relieved to hear I'm not the only one who's hit that exact bug. It's such a sneaky one too, everything looks fine until you're testing with two accounts side by side and suddenly realize you've been staring at the same data the whole time.
Appreciate the point about designer-first being an advantage. I think there's something to that, a lot of solo technical founders build something functional but rough, and a lot of solo designers get stuck before shipping at all. Landing in between those two failure modes seems to actually work out okay.
Stack-wise: Next.js on the frontend, Supabase (Postgres) for the database, Clerk for auth, Stripe for payments, all deployed on Vercel. Went with that combination specifically because each piece has genuinely good documentation and pre-built components, which mattered a lot given I was learning most of this as I went.
That stack is a solid pick for someone learning — Supabase docs are genuinely some of the best in the industry right now. Clerk + Stripe is also the path of least resistance for auth/payments.
"Landing in between those two failure modes" is a great way to put it. The solo technical founder ships fast but rough, the solo designer ships polished but gets stuck pre-launch. You're threading that needle.
Curious how Postgres row-level security worked out for multi-tenancy. Did you go with RLS policies or handle isolation in the app layer?