How I Built My First SaaS Project — Lessons, Mistakes, and What I'd Do Differently

About two years ago I had an idea for a tool that I thought would be useful for freelance developers. It was a simple client portal — a place where you could share project updates, upload deliverables, and collect feedback without having to manage everything through email and Slack.

The idea was not original. There were probably fifteen tools that already did roughly the same thing. I knew this. I built it anyway, partly because I genuinely needed something like it for my own freelance work, and partly because I had been reading about micro-SaaS and wanted to experience the process.

Here's what actually happened over the following eight months.

The Part Where I Over-Built the First Version

The first mistake I made was a classic one. I spent six weeks building features before I had a single user to validate whether any of them mattered.

I built a full authentication system with email verification and password reset flows. I built a notifications system. I built a file upload feature with thumbnail generation. I built a billing integration with Stripe before I had any paying customers.

At the end of six weeks I had something impressively complex and entirely unvalidated. I had made technical decisions based on what I imagined users would want rather than what I had heard real people ask for.

The right approach — which I learned expensively — is to build the absolute smallest version that lets you answer one question: will anyone pay for this?

My version one should have been: a page where clients can see project updates and leave comments. That's it. No file uploads, no notifications, no billing. A simple CRUD application with a nice UI. I could have built that in a weekend.

The Technical Stack I Chose and Whether It Was Right

I built with Next.js, MongoDB, and deployed to Vercel. This was the right choice. The stack was familiar, deployment was seamless, and the full-stack nature of Next.js meant I wasn't maintaining separate frontend and backend repositories.

Where I made questionable decisions was in the database design. I used MongoDB for everything, including data that had strong relational properties — user-organization relationships, project-member permissions, billing plans per organization. These relational concepts fit into documents awkwardly and I ended up writing application-layer code to enforce relationships that a relational database would have handled automatically.

If I were starting the same product today I would use Supabase (PostgreSQL) for the relational data and the Row Level Security it provides for user permission management, and only reach for a document database if specific features genuinely benefited from flexible schema.

Getting the First Users

The first five users came from a post I made in a freelance developer community I was already part of. I described what I was building and asked if anyone wanted early access. Ten people responded. Five actually signed up and used it.

Those five users gave me more useful product feedback in two weeks than I could have generated by thinking about the product for months. One of them told me that the feature I was most proud of — a project timeline visualization — was something they would never use. Another told me that the one thing they desperately wanted was the ability to add an approval/rejection flow to deliverables, which I hadn't thought to build.

This is the part where I learned why "build something people want" is cliché but not wrong. The product I imagined people wanting and the product early users actually wanted were noticeably different.

The Monetization Conversation I Dreaded

I spent too long not charging anyone. I told myself I was still in beta. I told myself I needed more features first. The truth was I was afraid of rejection — afraid that when I asked people to pay, they would say no and I would have to confront that the product wasn't valuable enough.

Eventually I sent an email to the users who had been active. I said the free period was ending and I was launching paid plans at $19/month for freelancers and $39/month for teams. I expected most of them to unsubscribe.

Three of them replied within an hour. Two converted to paid. One asked if they could pay annually.

The lesson was not that charging is always easy. The lesson was that the only way to learn whether people value something enough to pay for it is to ask them to pay for it. Avoiding the question delays the answer indefinitely.

What I Wish I Had Known Before Starting

The biggest thing I underestimated was distribution — getting people to discover and try the product. Technical skills don't solve the discoverability problem. Building an audience or having an established network is more valuable in the early stages than technical polish.

I also underestimated support. Even with a small number of users, questions arrive regularly. Bugs appear in edge cases I didn't test. Features work differently on specific browsers. Managing support takes significant time and is invisible in all the "I built a SaaS in a weekend" posts.

The thing I got right was building on a stack I knew well rather than using the project as an opportunity to learn new technologies. The product decisions were hard enough without fighting unfamiliar tools at the same time.

Would I Build a SaaS Again

Yes. The experience of building something with paying users is different from anything you build for clients or as a personal project. You are accountable to the product in a way that changes how you think about technical decisions.

The income from this first SaaS never reached the levels I hoped for — the market was more crowded than I initially thought and my distribution was weaker than I needed. But the things I learned in eight months of building it have been worth more to my career than any client project I've worked on.

If you're a developer thinking about building a SaaS, start smaller than you think you should. Validate before you build. Talk to potential users before you write a line of code. And charge earlier than feels comfortable.