Company: Personal Project Role: Solo Developer & Architect Duration: 10 months (March 2024 - December 2024) Team: Solo developer
Tech stack: Next.js 15, React 19, TypeScript, Tailwind CSS 4, DrizzleORM, PostgreSQL, Better Auth, shadcn/ui, Cloudinary, Arcjet, @dnd-kit, TanStack Query
The Moment
March 2024. I'm staring at npx create-next-app and I haven't pressed enter yet.
I've been on feature teams for years. Good ones. I've built auth flows, dashboards, API layers -- clean, well-tested slices of larger products. And every time, I'd finish my piece and wonder what it actually feels like to hold the whole thing. Not a vertical slice. The whole thing. From empty directory to something a stranger could sign up for and use.
So I pressed enter. No designer. No PM. No backend team to hand things off to. Just a blank Next.js scaffold and a vague idea: a creator platform. Think Linktree, but with actual ambition. Profile management, 55+ social platform integrations, drag-and-drop link ordering, AI-powered bio generation.
The idea wasn't the point. The point was finding out what happens when there's nobody to blame but you.
Ten months later, I have some answers. And some new questions I didn't expect.
Fifty Decisions Before Lunch
When there's no designer, you make fifty small design decisions before lunch. Border radius. Spacing. Whether that button should be primary or ghost. Whether the empty state needs an illustration or just a sentence. Nobody reviews these choices. You ship them and live with them, and somewhere around month three you realize you've developed opinions you didn't know you had.
When there's no architect to say "that's over-engineered," you find out for yourself. I built abstractions I later ripped out. I wrote a custom hook for something TanStack Query already handled. I spent a full afternoon on a caching strategy for a page that gets hit maybe twice a day. These aren't mistakes you make twice.
When there's no PM to say "not this sprint," you say yes to everything. Celebrity account claiming. Username reservation. AI bio generation. Verification badges. You build it all because it sounds cool, and then you realize why PMs exist. Scope isn't a constraint imposed on you. It's a gift.
And here's the part nobody warns you about: you get faster at switching contexts, but you never get deep enough in any single one. A designer who designs full-time will always out-design you. An architect who reviews systems all day will catch things you miss. Solo work teaches you breadth. It also teaches you exactly how much depth you're missing.
I thought that tradeoff would feel empowering. Mostly it felt humbling.
Decisions That Reveal What You Actually Believe
On a team, tech stack choices go through an ADR process, a committee, maybe a proof of concept. Solo, every choice is just you in a room deciding what you actually care about. No audience. No interview answer to optimize for.
The DrizzleORM decision is my favorite example of this.
I picked Drizzle over Prisma because I care about type safety more than convenience. Prisma generates types from your schema. Drizzle makes your schema the types. The difference sounds subtle until you refactor a database table and watch TypeScript catch every downstream breakage at compile time, before anything runs. That matters to me more than a nicer migration CLI. I didn't know that about myself until I had to choose with no one watching.
Better Auth instead of rolling my own. I'm good enough to build auth. I've done it before. But auth is where "good enough" gets people hurt. One edge case you miss, one token you don't invalidate, and you've got a real problem. Better Auth exists because smart people already thought about the things I'd forget at 11pm on a Tuesday. Knowing when not to build something yourself -- that's a skill solo work forces on you fast.
Cloudinary for images. Image processing is a trap. You think it's simple: resize, crop, serve. Then you need responsive variants, format negotiation, CDN delivery, and suddenly you've burned a week on infrastructure that has nothing to do with your product. I recognized the trap. I moved on.
@dnd-kit for drag and drop. I tried building drag and drop from scratch once. Once. The browser's drag API is a horror show, and accessibility alone makes it worth using a library. Pair @dnd-kit with TanStack Query's optimistic updates and links reorder instantly on screen while the server catches up in the background. It feels native. That's the goal.
Each of these choices pointed at the same lesson from a different angle: know where your effort creates value and where it doesn't. Building your own ORM teaches you nothing your product needs. Picking the right one and moving on does.
But Here's the Thing
I went into this project thinking the lesson would be about ownership. About what it means to hold every piece of a product and feel the full weight of it. And sure, I learned that. When the build breaks at midnight, you fix it. When a user hits a bug, it's your bug. You feel every dependency you add because you're the one who'll debug it at 2am. You understand why tests matter because there's no QA team between you and production.
You also develop a sense for the true cost of features. On a team, a feature request is a Jira ticket. Solo, a feature request is three days of your life. You start asking "is this worth building?" in a way that's impossible when someone else is prioritizing your backlog.
But the real lesson wasn't about ownership. It was about silence.
Nobody told me my API design was drifting inconsistent around month five. Nobody pointed out that my component naming convention changed halfway through. Nobody said "this error message is confusing" because nobody was reading my error messages. I missed things a fresh pair of eyes would've caught in five minutes.
Worse -- I caught myself building features I wanted to build instead of features the product needed. On a team, someone pushes back. Solo, you're the person with the idea and the person who approves it. That loop is dangerous, and I didn't notice I was in it until I looked up and realized I'd spent two weeks on a verification badge system for a platform with no users.
I expected solo work to teach me self-reliance. It taught me something closer to the opposite: how much I'd been taking for granted the people who tell you no.
The Question of Done
There's no deadline on a personal project. No client waiting. No sprint review. The temptation is to polish forever -- one more feature, one more refactor, one more edge case handled.
The platform works. Profiles render. Links reorder smoothly. The AI generates bios that are actually useful. Social platforms detect and display correctly. Auth works. Images upload and serve. It does what it set out to do.
But "done" on a personal project isn't about feature completeness. It's about whether you learned what you came to learn. I came to learn what it's like to own a whole product. I learned that. I learned where I'm strong -- architecture, data modeling, making things work -- and where I'm weak: visual design, scope discipline, knowing when to stop.
So now I know what it feels like to hold the whole thing.
What I still don't know is whether that knowledge makes me better on a team, or just more dangerous. Whether the instinct to own everything helps when you're supposed to own a slice. Whether ten months alone made me a sharper collaborator or just a more opinionated one.
I built FYP to find out what I'm made of. I got an answer. I'm just not sure it's the one I was looking for.