Building My First Freelance Website

Overview

This project marked an important milestone for me because it was my first freelance website for a real organization. The stack itself was familiar, but the context was completely different. Up until then, most of my work had been personal projects where I was building for myself, making my own decisions, and defining success on my own terms.

This project felt different from the start. It was one of the first times I was building something client-facing and truly production-ready. The goal was not just to make something that worked, but to deliver something polished, maintainable, and useful for the people who would actually rely on it.

Goals of the Project

The site needed to do more than simply exist online. It had to present the organization professionally, work reliably across real devices, and be easy for the client to maintain after handoff.

That meant thinking about the project from two sides. From the organization’s perspective, the website needed to be clear, polished, and functional. From the client’s perspective, it needed to be manageable without requiring constant developer involvement for every content update.

That became one of the defining goals of the build: not just delivering a finished site, but delivering something that worked well for the client long after launch.

Backstory

What made this project meaningful was not just the work itself, but what it represented. Until this point, most of my experience had come from personal projects, where experimentation was part of the process and the stakes were mostly my own.

This was different. There was a real client, real expectations, and real users on the other end. My code was no longer living in a personal sandbox. It was going into an actual production environment where people would interact with it and form an impression of the organization through it.

That shift made the project feel more serious in the best way. It pushed me to think beyond just building features and start thinking more carefully about trust, clarity, and reliability.

Working With a Client

One of the biggest lessons from this project came from the client side of the work. Building for someone else is very different from building for yourself. With personal projects, you can change direction whenever you want, make assumptions quickly, and optimize around your own preferences. Client work forces you to slow down and listen more carefully.

A big part of the process was understanding requirements, translating non-technical requests into technical decisions, and making recommendations that served the client’s actual needs. That also meant thinking about revisions, feedback, and long-term maintainability. It was not enough to build something that looked good from a development perspective. It had to make sense to the client and support how they would use it in practice.

This project helped me understand that development is not only about writing code. It is also about communication, planning, and making thoughtful tradeoffs.

Technologies Used

The core stack for the project was familiar territory for me, which helped keep development grounded. The more important decision was the CMS.

For this website, I chose Sanity because it felt like the right fit for a client-facing project. Unlike a personal project, where I might prioritize my own preferences as the developer, this decision had to account for the editing experience of someone else. The CMS was not just a backend tool. It was part of the product the client would interact with after the site launched.

That changed how I thought about the build. The right tool was not simply the most interesting one technically. It was the one that made content management clearer and more approachable for the client.

Building for Production

This project also changed how I thought about production code. On personal projects, it is easy to focus on getting features working and refining things over time. With a freelance project, the standard feels different because other people are depending on what you ship.

I found myself thinking more carefully about code structure, reliability, deployment, responsiveness, and edge cases. Production code is not just code that runs. It is code that needs to be dependable, understandable, and maintainable once it is live.

That mental shift was one of the most valuable parts of the experience. It made me more intentional about what I was building and how I was building it.

Challenges and Tradeoffs

Like most real projects, this one involved tradeoffs. One of the biggest was balancing speed with quality. There is always pressure to move quickly, but client work raises the cost of cutting corners.

Another challenge was structuring content in a way that made sense both technically and from the client’s perspective. A CMS can add a lot of flexibility, but that flexibility only helps if the content model is intuitive for the person using it. That forced me to think more carefully about organization, editing workflows, and how much flexibility the site actually needed.

There was also the challenge of balancing polish with practicality. It is easy to keep refining details forever, but at some point the project has to ship. Learning how to make those calls without losing sight of quality was part of the process.

What I Learned

The biggest lesson from this project was that client work is just as much about communication as it is about coding. Writing the code is only one part of the job. Understanding goals, setting expectations, and making good recommendations are just as important.

I also learned that production work changes how you think about quality. You become more aware of maintainability, reliability, and the experience of the people using the site after launch. That includes not only visitors, but also the client managing content behind the scenes.

Most of all, this project reinforced that tool choices should match the people using them. A CMS is not just a technical integration. It is part of the user experience, and in client work that matters a lot.

What I Would Do Differently

Looking back, I would spend more time upfront clarifying requirements and thinking through editing workflows earlier in the process. I would also refine the content model even further so that handoff and future updates feel as smooth as possible.

More generally, I would think earlier about scalability, not necessarily in terms of massive traffic or complexity, but in terms of how the site could continue to evolve without creating friction for the client.

Those are the kinds of lessons that only become obvious after shipping something real, and they are part of what made this project so valuable to me.

Final Thoughts

This project was an important step in my growth as a developer because it was one of the first times I built something not just for myself, but for a real organization with real expectations.

It taught me that freelance and production work require a different mindset. You are not just building features. You are building trust, clarity, and something another person can genuinely rely on.

And that is what made this project feel like more than just another website.