I Learned to Code to Launch a SaaS. Here’s 10 Lessons I Learned Along the Way.

I Learned to Code to Launch a SaaS. Here’s 10 Lessons I Learned Along the Way.

Featured on Hashnode

For years before learning to code, I had ideas for websites, apps and projects. However, without having the skills to actually build them, that's all they were - ideas. In September 2020, several months after the pandemic first started, I did what many others did: I decided to learn to code.

I had worked with HTML and CSS since my teens (I'm 33, by the way...) and made websites with almost every CMS around, but I'd never ventured into full-blown programming; instead, I fell into the world of design. The pandemic was a tricky time in so many ways, but it gave me the time and space to finally explore something that had interested me for so long.

So, I committed to learning to code, and decided to make one of my ideas a reality; a simple tool that would help teachers write progress reports for students more quickly. I would build it as I went along. Each time I would learn something new, I would it into practice and add it to my project, in the hope that eventually it would be a fully functioning software-as-a-service tool (or SaaS), complete with a backend, authentication, subscriptions, a payment gateway, and more. It was ambitious, but gave me something to aim for.

It's 18 months since I started on this path, and I've just launched my SaaS, Reportr, into public beta, so now feels like the perfect time to look back on what the experience has taught me.

This article isn't just written for coders thinking about building their own SaaS, but rather for anybody considering learning to code, in the hope that my words might save others time and headache, regardless of where they are on their learning journey.

🗺️ 1. A roadmap will keep you on track

I'm lost I'd love to say that I had it all planned out when I first started out; a clear plan of which languages I was going to learn, the stack I wanted to have, and the coding concepts that underpinned my SaaS idea, but this would be lying.

I was looking forward to getting stuck in, but was focused on learning languages I could actually use to build my SaaS. I didn't want to fall into the trap of aimlessly picking up shiny new tech without a big picture in mind, so I needed to decide where I wanted to head.

After reading a few articles, Reddit posts, and Twitter threads, I decided to start with JavaScript; it was versatile, a gateway-language to other languages, and paired well with HTML and CSS. It seemed like the perfect place to start. ...But then what?

I took my time and put together an outline of what I wanted to learn. Plotting my roadmap would mean I would learn more efficiently, and with greater focus. If I had a final destination in mind, the journey wouldn't feel endless and meandering. I could measure progress, I could set myself targets along the way, both long-term and short-term.

Just a few weeks after picking up JavaScript, I knew roughly how I wanted the following 18 months to look; 6-12 months of pure JavaScript, 6 months of React, and then I would focus on backend technologies unless something else came up along the way (spoiler: it did).

I knew I needed a strong coding base to build on top of, so the entire 18 months would be spent immersing myself in core principles, fundamental concepts and whichever tech would (a) be of use in building my SaaS and (b) versatile enough to build others projects with in future.

🏃‍♂️ 2. It’s a marathon, not a sprint.

Pace yourself I knew I wasn't going to learn to code overnight. This was something I had committed to it for the foreseeable future, and something for which I knew the learning would never really end.

I knew there would be ups and downs along the way, and times when my progress would slow, but so long as I was still making steps towards my goal, that's all that mattered.

It's cliche to say consistency is key, but it really underpins the approach I have taken to learning to code. I have a full-time job as a teacher, so finding time each and every day to code hasn't - and isn't - easy.

Some days I would make next-to-no progress at all, and other days, take a giant leap forward. Some days I'd write hundreds of lines of code, other days I'd spend what little time I did have, reading. It's all part of the process, and whatever happens, come back the next day and keep moving forward.

🧰 3. You’ll build your SaaS, then build it again.

Let it all burn to the ground About 6 months after first delving into JavaScript, keen to practice what I had learned, I started building a rudimentary version of my SaaS. No frameworks, no backend, just HTML, CSS and some JavaScript.

The code was long-winded, bloated, ugly, inefficient, but the most basic functionality was there. But basic really is the operative word to describe what I built at that time. No frameworks, no backend, just HTML, CSS and JavaScript. It combined almost I had learned up to that point, cemented my learning, and showed me that I was ready for the next step.

I put this project to one side, confident I had a good grip on the fundamentals of JavaScript, and turned towards React. I was excited to see what all the fuss was about, but still unsure of exactly what it was and what it made it so special.

As I always do when learning something new (coding or otherwise), I spent a few days familiarising myself with basic concepts and terminology; learning what React was all about.

It was exciting, but also a little demoralising, because once I'd wrapped my head around the benefits of React, I just knew I was going to have to practically rebuild my SaaS from the ground up.

Little did I know, but this rebuilding process would happen again - but admittedly to a lesser extent - when I would add Tailwind CSS to my stack. Then again when I found Next.js. As is often the case, I would upgrade my skills, and see new ways of approaching the project that I didn't even know were there, and a simple refactor just wouldn't be enough.

Be ready to build, rebuild, and then build it all over again.

🔥 4. Having multiple projects helps you avoid burnout.

Well I have to keep it interesting for myself Along the way, my motivation to work on my SaaS fluctuated. Even at times when it was all going well, too much of a good thing is a real thing. While my SaaS project was my primary focus, it was important to keep things interesting.

After hitting important milestones along the way, I would take some time away from my SaaS idea to build other projects. Sometimes it would be days; other times, weeks.

In the time between that first version of my SaaS and now, I developed and launched three projects: a tool to help developers find colour palettes for their next project, called ColorHub; a simple site that creates image cards for Twitter profiles, Yodlr; and an open source tool called ProfileMe.dev, that lets users quickly design - and get auto-generated markdown code for - their GitHub profiles.

Not only was this a great way to avoid getting tired of working on one project, it was also a great way to get a stronger grip on the new technology, techniques and approaches I had picked up.

To outsiders, it likely seemed like I was procrastinating over creating my SaaS, but I was in fact building up my skills so I could confidently create what I had in mind, not hack something together while having only a tenuous grip on the code behind it.

🐞 5. You’ll encounter bugs you think are unsolvable. Embrace these moments, because they are when you learn the most.

I can't do it Each time I picked up a new technology, language, concept or framework along the way, I was careful to get comfortable with it before applying it to my SaaS project.

At times, I was working right at the tip of the spear of my skills, struggling through tutorials, encountering issues I never saw coming, with no idea where to start in solving them. I really can't stress how frustrating these times were; it was like I had something stuck between my teeth that I just couldn’t shift.

I would step away from my computer and it would be on my mind; I’d find myself running through logical steps in my head, looking to understand the problem and think of a conceptual solution. Eventually, I would find a solution, and with it would come a eureka moment and (more importantly) a big upgrade in skills, too.

Expect to hit walls, and a lot of them, but know that it’s inevitable that you'll find a way around, even if it takes a while.

👷 6. Building in public is invaluable

Little girl building I joined Twitter about 5 months in, and decided to start sharing my ups and downs and project progress with other developers.

I originally joined to expand my network, to hold myself accountable, to learn from those in the tech Twitter community and to get over a fear of sharing my work (a topic I wrote about here). What I wasn't expecting, however, was to find a community as willing to give support when I hit a wall, motivation when I had lost my own, and advice on how to solve issues when I came across them.

Through sharing my work, I got regular feedback on the direction I was heading, the UX/UI's I was developing, and the approach I was taking. Oh, and I soon got over my fear of sharing what I was building, too.

🖥️ 7. Low-code tools can ease you into the world of backend

This might be easier than I expected Getting to the stage where I had built a one-page React version of my SaaS was demanding in itself, but I soon realised it had none of the features that would actually make it a SaaS. No backend, no authentication, no payment gateway, no storage, and only basic versions of the features I wanted it to have.

If the user refreshed the page, they were right back at the beginning. ...It needed a backend.

My first instinct was to research backend languages and frameworks that paired well with my Next/React/Tailwind stack. I spent a week or so dabbling with Node and Express (part of the MERN stack), and they seemed like a logical next step.

Conscious that I didn't want to dive into backend before I had a strong grip on my frontend stack, I decided to look at alternative paths. Supabase offered a low-code solution that would help me understand how backend technologies work without having to learn an entire stack of backend languages to do so.

Using Supabase was a fantastic way to get my head around some fundamental backend concepts (CRUD, etc), so if you're in a similar position, I'd recommend starting with a low-code solution, you can pick up the rest further down the line.

🧩 8. You are building a template for future projects.

That's convenient Building my first SaaS meant a lot of firsts. My first time using GitHub, my first time using React components and hooks, my first time figuring out how to add authentication to my project, and many more.

As with learning anything new, the first time often doesn't run smoothly, and takes a little while to get your head around. With coding, though, each time you create a feature or solve a logical issue, you're creating snippets that you'll use again in future. You'll be able to 'install' features into your projects that took days, weeks or longer to create, but seconds to plug in to a fresh project.

Reminding myself of this periodically helped me to look at my journey as a long-term one that would progressively get easier, rather than more difficult, even if the code itself got more complex.

👨‍💻 9. You’re developing more than just coding skills.

Skills As any developer knows, coding is more than just hammering out syntax. It's a complex and unpredictable game that involves problem solving, creativity and perseverance, but learning to build a SaaS broadens the skills you're developing even more.

Creating a SaaS allowed me to lean on my design skills for the UI and use them in combination with more recent passion for coding, but it also challenged me to develop skills in so many other areas: how to brand and market a product, how to write copy, how to design a subscription structure that incentivises sign-ups, how to improve overall UX, and so much more.

💭 10. Imposter syndrome is inevitable

Skills When I began this journey, I'd heard so much about imposter syndrome, but been lucky enough not to really experience it in any major way. I was careful not to compare myself to others, not to overthink the process of learning and building projects; conscious that I didn't want to encourage feelings of inadequacy or anything that could hinder my productivity and motivation.

It didn't really matter.

It's natural for imposter syndrome to flare up and rear its ugly head, no matter how much you try to avoid it. It's normal to doubt yourself when you've spent days trying (and failing) to fix a bug, or can't seem to get something that seemed so simple to just... work. It's normal to feel that way, but the difficult part is not listening to it.

When imposter syndrome would kick in, I would try to remind myself that it would pass with time, and could only slow my progress if I let it. I'm sure you can do the same.

To conclude

Learning how to build - and actually building - a SaaS has been one of the most challenging things I've ever done, but it's also been one of the most rewarding. The journey to get here was long, and as fun as it was stressful. It's only now that I've launched my SaaS into public beta, I'm able to look back and see how far I've come. Whether or not this SaaS generates revenue is to some degree irrelevant, because what I learned along the way is truly invaluable.

If you enjoyed this article and want to see more content about development, design, creativity and learning, then follow me on Twitter at @danielcranney.

If you'd like to see my work, check out my portfolio or visit my SaaS at Reportr.io.

If you'd like to support me to make more content, check out my BuyMeACoffee page. Buy Me A Coffee