Every project I take on follows the same rough shape, whether it is a one-page site or a full e-commerce build. The steps are unglamorous but they are what separate a website that ships on time and performs, from one that drags for months and still disappoints.

Here is the process, start to finish.

1. Discovery call

Before I quote anything I want to understand the business. On a 30–45 minute call I ask:

  • What does the business actually do, and who pays for it?
  • Who are the customers and what are they comparing you against?
  • What does the website need to accomplish — leads, bookings, sales, credibility?
  • What is the tone? Minimal? Playful? Formal? Technical?
  • What has not worked on previous sites?

Without clear answers to these, no amount of design polish will produce a useful result. If the client is not sure, we slow down here rather than rush forward with assumptions.

2. Content and structure

Design without content is decoration. Before opening Figma I draft a rough outline of every page:

  • What does each page need to say?
  • What order should it say it in?
  • What is the single action we want the visitor to take on that page?

The client either supplies the copy or we write it together. If copy is not ready, I use realistic placeholder text based on the brief — never Lorem ipsum. Lorem hides problems that only show up after launch when real words are plugged in.

3. Design in Figma

Once structure is agreed, I design in Figma — desktop and mobile side by side, from the start. Mobile first is not a slogan, it is the discipline that keeps the layout honest. If something only works at 1440px wide, it does not really work.

The client sees a live Figma link and can leave comments directly on the design. We iterate until it feels right. Changes at this stage take minutes. Changes in code take hours. Every revision here saves real money later.

Typical output from this stage: fully-specced desktop + mobile designs, a small style guide (colors, type scale, spacing), and a sign-off from the client.

4. Build

Only now do I write code. The stack depends on the project:

  • Plain static site or SPA → React + Vite + Tailwind.
  • Content-heavy or SEO-criticalNext.js.
  • E-commerce or dynamic → Next.js + Supabase (or Shopify Storefront API for bigger catalogs).

Tech choices are driven by what the project actually requires, never by what is trendy. I wrote about that selection process in React vs Next.js for Small Business Websites.

I work in small, reviewable commits. The client gets a staging URL from day one and can follow progress in real time.

5. Performance and SEO pass

Before any launch I run a structured QA pass:

  • Performance: Lighthouse and PageSpeed Insights for every page. Target: 95+ on mobile. See What Makes a Website Fast for what that means in practice.
  • SEO: Meta tags, canonical URLs, Open Graph, Twitter cards, schema markup, sitemap.xml, robots.txt, proper heading hierarchy.
  • Accessibility: Keyboard navigation, alt text on every image, labels on every form field, color contrast.
  • Cross-browser: Chrome, Safari (desktop and iOS), Firefox, and Edge. Real devices, not only simulators.
  • Link integrity: Every internal link, every form submission, every redirect.

Nothing ships until this passes cleanly.

6. Deployment

I deploy on Vercel (or Cloudflare Pages for pure static sites). Both give global edge networks, instant rollbacks, and free HTTPS. I handle the domain setup, DNS, email records, and analytics wiring so the client never has to touch a DNS panel.

For most projects the client ends up with:

  • A live production URL on their own domain.
  • Automatic deploys on every git push (via a private repo I can hand over).
  • Basic analytics dashboard.
  • A short handover document with how to update content, contact info, and common fixes.

7. After launch

A website is not done at launch. It is just starting. I offer ongoing support at an honest hourly rate for small content updates, bug fixes, and performance checks. Bigger changes — new sections, new features, redesigns — are scoped separately.

For clients who want to be able to update content themselves, I wire in a lightweight CMS (Sanity or Supabase-backed admin) during the build. No more calling the developer to change a phone number.

Work with me

If this process sounds like what you want for your project, the contact section on the homepage is the fastest way to get in touch, or email info@tonibarisic.com directly. I reply to every inquiry within 24 hours.