It all starts with an email. Whenever a potential client reaches out to me about starting a new project, they set into motion a process that I’ve refined over multiple projects. This article details how I work with clients to bring their ideas to life on the web from start to finish.
Phase 1: Understanding Client Needs
Most clients know they need a website, but the actual specifics of what they want or are envisioning are fuzzy. My first goal is always to work with the client to actually discover why they want a website, and be able to turn these fuzzy ideas into actual product requirements (unless they already have these in mind). In the words of my Discrete Math professor,
“We’ve gotta turn the squishy into rigid logic.”
Here are some questions that I always like to ask:
- What’s the primary goal? Is this going to be an informational site, a lead generation tool, an e-commerce platform, a community hub, etc.?
- Who’s the audience? In other words, who are we building this for? Who are your customers/users?
- What’s the timeline? Are we working toward a hard launch date (event, product release, etc.) or is this more flexible?
- What’s the maintenance plan? Will you be updating content regularly? Do you have someone technical on staff, or will you need a CMS?
- What does your brand look like? Coming from a marketing background in high school (and now taking it in college), I often end up adapting people’s existing branding to the web (as well as writing copy in their brand voice). This usually involves asking for logos, color schemes, fonts, and any existing marketing materials. Sometimes, clients don’t really have brands yet, in which case I work with them to establish a basic visual identity.
Why this matters: A swim team site has completely different requirements than a nonprofit book exchange. The Book Nook Project was just a basic info site/lead generator, while Tritons Swim required clear meet schedules, record keeping, and registration information. Same “we need a website” starting point, totally different solutions.
Phase 2: Choosing the Right Tools
“Choose the right tool for the job, not the other way around.”
My decision framework:
I usually “bucket” projects into three categories:
- Web “Brochures” : Basic info, a few pages, minimal updates. (e.g., The Book Nook Project)
- Content-heavy sites: Regular updates, blog posts, events, etc.
- Web Apps: Interactive features, user accounts, complex workflows.
For each bucket, I have a go-to stack:
- Web Brochures: Astro (with Svelte or React), Tailwind CSS, Bootstrap, deployed on Vercel or Netlify, maybe even GitHub Pages.
- Content-heavy sites:: Back in the day, this would be a SPA built with Vite. Nowadays (since frameworks are being pushed towards meta-frameworks like SvelteKit or Next.js) this wouldn’t be that viable. Nowadays, I would create a single route app with Next.js and then use Tailwind CSS and Bootstrap and then deploy on Vercel or Netlify.
- Web Apps: I always reach for Next.js for these sites. If we need to pull in a backend, I always pull in Firebase (becuase it’s the best featured and easiet to manage for clients). Tailwind CSS and Bootstrap for styling, Vercel for deployment.
- Pro tip: If it is a smaller scale web app (i.e. needs interactivity/database but doesn’t have complesx workflows), I sometimes still use Astro to build it, especially if it is more content focused.
- Super pro tip: Have the client sign up for firebase on their own account, and then just add me as a collaborator. This way, they own their data and backend, and it makes handoff easier.
- Pro tip: If it is a smaller scale web app (i.e. needs interactivity/database but doesn’t have complesx workflows), I sometimes still use Astro to build it, especially if it is more content focused.
Real example: For Tritons Swim, I categorized this as a content-heavy site with some interactive features (schedules, records). I used Next.js with Tailwind CSS and Bootstrap. This site only had one truly interactive feature (the sign-up form), which I handled by deploying on Netlify and using their built-in form handling. No need to overcomplicate with a full backend. The other things could be handed with static assets (downloading files, looking at hardcoded records, etc.)
Phase 3: Design!
This is where I leave the technical world and step into UX/UI design. Usually, I start with Canva to import the clinet’s branding assets and create mockups. They have an easy website builder that is integrated into the website that allows me to quickly mockup designs and share them in real-time (often collaboratively) with the client. Once we settle on a desing, we move to development.
Phase 4: Development
Now that designs are approved, it’s time to turn them into code. Now that we are fully in the “vibecode” era of proramming, I usually like to start with v0 (what a perfect name). The problem with v0 is that it writes exclusively in react and pulls in shadcn/ui, which I am against. So usually, what I end up doing is screenshotting the Canva designs we worked through, giving them to v0 to get a rough scaffold of what the site would look like in code, and then use Claude Code to refactor these components to fit whatever tech stack we are using (Astro, Next.js, SvelteKit, etc.) and then restyle them with Tailwind CSS and Bootstrap to match the design exactly.
This abstraction (espcially with styling) allows me to create a “control center” for the design system, which either me or the client can easily update later on, with chnages taking place sitewide. It also allows the componetns to be updated automatically with npm updates. No need to use codemods to update your own project code. I always believe that you should be npm installing your design system, not copying and pasting code from a design system library.
Once the full site is scaffolded out, I go back and add in any interactive features (forms, modals, dynamic content loading, etc.) and ensure everything is responsive and works well on all devices. I then make the tiny adjustments that Claude Code just could not figure out on its own. Once we have a MVP version of the site, I send it to the client for review and feedback.
This starts the development-feedback loop, where I make adjustments based on client input until we reach a final version ready for testing.
Phase 5: Testing & Refinement
Once client needs are met, I rigorously test the site across multiple dimensions to ensure a smooth user experience. I usually do not use automated testing for client projects, and instead opt to do manual testing as I am developing the site. These checks at the end are more of a final sweep to catch anything I might have missed during development.
My testing checklist:
Functional testing:
- Every link works
- Every form submits correctly and validates input
- Navigation works on all pages
Cross-browser and device testing:
- Chrome, Firefox, Safari at minimum
- Mobile (iOS and Android)
- Tablet layouts
- Common screen sizes and edge cases
Performance testing:
- Lighthouse scores (aim for 90+ across the board)
- Actual load times on real networks
- Asset sizes and optimization opportunities
Content review:
- Spelling and grammar
- Pro top: just pass off the site files to your favorite AI and tell it to proofread everything.
- Consistent voice and tone
- This usually requires touching base with the client again to ensure that the copy matches their brand voice (becuase usually, I’m the one writing the copy).
- All placeholder content replaced
- Also sometimes requires touching base with the client to get final images, bios, etc.
Phase 6: Launch & Handoff
After final approval, it’s time to launch the site. I usually like to do a soft launch first (unlisted URL) (pro tip: use the auto generated URL that Vercel or Netlify gives you when you first spin up the project) so the client can do a final review in a live environment before going public. Once they sign off (first we pray) then, we move to the production URL and make the site live.
Once the site is live, I provide the client with all necessary documentation and training to manage their new site. This includes:
- Documentation for how to update content
- Training session (recorded for future reference)
- Contact information for ongoing support
- Clear expectations about maintenance and hosting
- Week 1: Daily monitoring
- Week 2-4: Regular check-ins
- Month 2+: Available for questions and minor updates
Conclusion
In reality, this is a highly simplified overview of how I approach client web projects. Each project has its own unique challenges and requirements, but this framework provides a foundation to ensure that I deliver high-quality, functional websites that meet client needs. Some of my design patterns stick between projects, but many decisions are made on a case-by-case basis depending on the client’s specific situation.
What matters most is constantly staying in contact with the client, working with them, accepting feedback, and iterating until we reach a final product that everyone is proud of. But that doesn’t mean you have to bend to the client’s dream. I’ve learned that sometimes a client’s wishful thinking can add a lot of unnecessary complexity to a project. A lot of the time, simple feature requests can add exponential amounts more work and code overhead. It’s my job to guide the client toward the best solution, even if that means saying “no” to certain requests for the sake of simplicity, maintainability, and budget.
If this process interests you and you’d like to discuss a potential project, feel free to take a look at my portfolio or reach out via email (or fill out the form on my site).
