DEV Community: Pavlina Stavreva

Your freelance hourly rate is probably too low – here is the math, step by step

Pavlina Stavreva — Wed, 11 Nov 2026 12:10:05 +0000

The most common way to pick a freelance rate is to take the salary you want and divide it by the hours in a year.

€50,000 ÷ (52 weeks × 5 days × 8 hours) = €24 per hour.

It looks reasonable, and it is almost three times too low. That number assumes you never take a holiday, never get sick, pay no tax, have no costs, and bill every single hour you sit at your desk.

Here is the same calculation done properly, one step at a time. I use these exact numbers as the defaults in a free rate calculator, so you can follow along with your own.

1. Start with what you want to keep

Your goal is the money you want after tax, not your revenue. In this example: €50,000 a year.

2. Add the tax back

If about 30% of your profit goes to income tax and social contributions, you need to earn more before tax:

Profit before tax = 50,000 ÷ (1 − 0.30) = 71,429

Use your own country's rate. If you're not sure, a rough guess is better than ignoring it.

3. Count the days you can really work

A year has 52 weeks, but you won't work all of them:

52 weeks × 5 days        = 260 days
− 5 weeks of holiday     = −25 days
− 9 public holidays      =  −9 days
− 5 sick days            =  −5 days
= 221 working days

4. Not every working hour is billable

This is the step most people skip. As a freelancer you also write proposals, answer emails, send invoices, do your bookkeeping, update your portfolio and learn new things. Nobody pays for those hours.

A realistic billable share for a solo freelancer is somewhere between 50% and 70%. With 60%:

221 days × 8 hours × 60% = 1,061 billable hours

That is very different from the 2,080 hours the naive version assumed.

5. Add your business costs

Software, hosting, a laptop that needs replacing, insurance, an accountant, your phone. Even a lean setup adds up. Here: €310 a month, so €3,720 a year.

Revenue needed = 71,429 + 3,720 = 75,149

6. Divide

Minimum hourly rate = 75,149 ÷ 1,061 = €70.84
Day rate (8 h)      ≈ €567
Monthly revenue     ≈ €6,262

€70.84 instead of €24. Same income goal, same person. The difference is only that the second number includes the parts of freelancing that aren't client work.

7. See what the billable share does

The billable share moves the result more than anything else:

Billable share	Minimum rate
50%	€85.01
60%	€70.84
70%	€60.72
80%	€53.13

If you're just starting and still looking for clients, you'll be closer to 50% than 80%. Price for that, not for your best month.

A few notes

This is a minimum, not a market rate. It tells you the price below which freelancing costs you money. What clients will pay depends on your niche, experience and where they are. If the market pays more, charge more.
VAT comes on top. If you're VAT-registered, add it to the rate you quote. It isn't income.
Recheck once a year. Costs, tax and the number of clients change, so the rate should too.

Try it with your numbers

I put the whole calculation into a free one-page calculator: northpeak-rate-calculator.pages.dev. It works in English and German, in light and dark mode, and shows where your year goes (billable work, unpaid work, holidays). No sign-up, no cookies, and your numbers never leave the browser.

If you'd rather keep it in a spreadsheet, the same formulas are in the Freelancer Business Kit on Etsy, together with a client and project tracker (Freelance Desk), an invoice tracker and a simple business budget.

What billable share do you actually reach in a normal month? I'd be curious to hear in the comments.

What I learned building a WordPress block theme for hair salons (and getting it ready for WordPress.org)

Pavlina Stavreva — Thu, 29 Oct 2026 14:11:26 +0000

Most small salons I looked at have the same setup: an Instagram account, a booking link (Treatwell, Fresha, Booksy, Planity) and no website of their own. When I asked myself what a salon site actually needs, the list was short: prices with durations, the team, recent work, opening hours, and a big "Book" button.

So I built Atelier Mira, a full site editing (block) theme for hair salons and beauty studios, and a free Lite version that I submitted to the WordPress.org theme directory. This post is what I learned on the way.

Live demo: https://atelier-mira-wp.pages.dev
Free Lite version (GPL, on GitHub): https://github.com/polyastavreva/atelier-mira-lite

1. A block theme is mostly `theme.json`

There's no page builder and no options panel. Colors, fonts, spacing and layout widths all live in theme.json, and the owner changes them later in Appearance → Editor → Styles.

I named the palette after things you'd find in a salon rather than "primary/secondary", so the names still make sense to the person editing:

"color": {
  "palette": [
    { "slug": "plum",  "color": "#2B1B2A", "name": "Plum" },
    { "slug": "rose",  "color": "#F3E3DE", "name": "Rose" },
    { "slug": "blush", "color": "#E9C9C0", "name": "Blush" },
    { "slug": "paper", "color": "#FCFAF9", "name": "Paper" },
    { "slug": "olive", "color": "#6E7A4C", "name": "Olive" },
    { "slug": "sage",  "color": "#DCE3C9", "name": "Sage" }
  ]
}

2. Ship the fonts with the theme

Loading Google Fonts from Google's servers is a GDPR problem in Europe, and most of my target salons are in Europe. Block themes can register local font files directly in theme.json, so the browser never contacts a third party:

"fontFamilies": [{
  "fontFamily": "\"Instrument Serif\", ui-serif, Georgia, serif",
  "slug": "serif",
  "name": "Instrument Serif",
  "fontFace": [{
    "fontFamily": "Instrument Serif",
    "fontWeight": "400",
    "fontStyle": "normal",
    "fontDisplay": "swap",
    "src": ["file:./assets/fonts/instrument-serif-latin-400-normal.woff2"]
  }]
}]

I split each font into latin and latin-ext files with unicodeRange, so a visitor only downloads the subset the page needs. The OFL licence files sit next to the fonts.

3. A price menu made only from core blocks

The section I care about most is the price list. Clients want three things on one line: the service, how long it takes and the price. I didn't want a custom block for this, because custom blocks are one more thing to maintain and one more thing the salon owner can break.

Each row is a core Group block with three Paragraphs inside. The layout is plain CSS grid on a class:

.am-item {
  display: grid;
  grid-template-columns: auto 1fr auto; /* name | duration | price */
  align-items: center;
  gap: 4px 10px;
  padding: 16px 0;
  border-top: 1px solid var(--wp--preset--color--line);
}
.am-item__time {
  justify-self: start;
  font-size: 0.8rem;
  border: 1px solid var(--wp--preset--color--olive);
  border-radius: 999px;
  padding: 0 9px;
}
.am-item__price {
  text-align: right;
  font-variant-numeric: tabular-nums; /* prices line up */
}

To add a service, the owner duplicates a row in the editor and types. tabular-nums is a small thing that makes a long price list look printed instead of typed.

4. Motion that never flashes and respects "reduce motion"

The hero photos rise in one after another, and gallery photos fade in on scroll. Two problems with that kind of animation:

If the "hidden" state is applied by JavaScript after load, the photos flash visible and then disappear.
Some visitors ask their system for less motion.

The fix is a tiny inline script in <head> that adds a class before the first paint, and only when the visitor hasn't asked for reduced motion:

function atelier_mira_lite_motion_flag() {
  wp_print_inline_script_tag(
    "if(!window.matchMedia||!matchMedia('(prefers-reduced-motion: reduce)').matches){document.documentElement.classList.add('am-anim');}"
  );
}
add_action( 'wp_head', 'atelier_mira_lite_motion_flag', 1 );

All animation CSS is scoped under .am-anim, so without JavaScript, or with reduced motion on, the photos are simply there:

.am-anim .am-reveal { opacity: 0; transform: translateY(32px); transition: opacity .9s, transform .9s; }
.am-anim .am-reveal.is-in { opacity: 1; transform: none; }

An IntersectionObserver adds is-in when a photo scrolls into view.

5. What the WordPress.org review checks (and what caught me out)

Getting a theme into the official directory is stricter than selling it elsewhere. Things I had to change for the Lite version:

Text domain = theme slug. Every __() and esc_html_e() uses atelier-mira-lite, and you don't call load_theme_textdomain() any more, WordPress loads translations itself.
Images must be GPL-compatible. My paid demo uses Unsplash photos. Those can't go into a GPL theme, so the Lite version ships soft placeholder images I made myself, marked "Your photo", in the right size for each spot.
Required templates. archive.html and search.html need to exist even on a one-page theme, and the 404 page needs a search form.
Screenshot 1200×900, under the size limit, showing the theme as it really installs.
Readme credits for every bundled font and image, and at most one link to a paid version.
Theme Check in WP-CLI catches most of this before a human reviewer does:

wp theme-check run atelier-mira-lite

6. Lite vs Pro

The Lite version is a complete one-page salon site: hero, scrolling services band, studio intro, price menu, opening hours with a booking button, plus blog/archive/search/404 templates.

The paid version adds team, gallery and review sections, an appointment request form, and WooCommerce styling for selling gift cards and products. If you want to see it:

Gumroad: https://stavreva68.gumroad.com/l/atelier-mira-wordpress-theme
Etsy: https://www.etsy.com/listing/4604925781/salon-website-template-for-wordpress

If you build sites for salons or other small local businesses, I'd love to hear what sections your clients always ask for. And if you spot something in the Lite code you'd do differently, issues on GitHub are very welcome.

How I built a multilingual Nuxt 4 site for local businesses (EN/DE/FR, hreflang, no CMS)

Pavlina Stavreva — Wed, 21 Oct 2026 06:31:21 +0000

I live in Switzerland, where a painter in Bern may get customers who speak German, French or English. Most website templates for local businesses are English-only, and adding languages later usually means duplicated pages and broken SEO.

So I built Handwerk, a Nuxt 4 + Tailwind CSS v4 site for trades, with three languages from day one. Here is how it's put together, and what I'd do the same way again.

Live demo: https://handwerk-nuxt-demo.netlify.app
Free Lite version (MIT): https://github.com/polyastavreva/handwerk-nuxt-lite

1. i18n: one config, correct URLs, correct hreflang

I use @nuxtjs/i18n with the prefix_except_default strategy. English lives at /, German at /de, French at /fr:

// nuxt.config.ts
i18n: {
  baseUrl: site.url,
  defaultLocale: 'en',
  strategy: 'prefix_except_default',
  locales: [
    { code: 'en', language: 'en-GB', name: 'English', file: 'en.json' },
    { code: 'de', language: 'de-CH', name: 'Deutsch', file: 'de.json' },
    { code: 'fr', language: 'fr-CH', name: 'Français', file: 'fr.json' },
  ],
  detectBrowserLanguage: { useCookie: true, cookieKey: 'lang', redirectOn: 'root' },
}

Two details matter for SEO:

language with a region (de-CH, fr-CH) ends up in the hreflang tags, so Google can show the Swiss German page to Swiss users. The module also emits the generic de and fr tags next to them, so German speakers in Germany or Austria still land on the German pages (check the rendered HTML: you should see both de and de-CH).
baseUrl must be your real domain. Without it, the alternate links are relative and search engines ignore them.

In app.vue one line wires it all up:

const head = useLocaleHead({ seo: true })

useHead(() => ({
  htmlAttrs: { lang: head.value.htmlAttrs?.lang },
  link: [...(head.value.link || [])],
  meta: [...(head.value.meta || [])],
}))

That gives every page <link rel="alternate" hreflang="…"> for all three languages plus x-default.

2. UI strings in JSON, business content in TypeScript

I split text into two kinds:

Interface strings (buttons, labels, error messages) live in i18n/locales/*.json.
Business content (services, prices, projects, reviews, FAQ) lives in typed data files.

The data files use a tiny helper type so every entry must have all three languages:

export type Locale = 'en' | 'de' | 'fr'
export type L<T = string> = Record<Locale, T>

export interface Service {
  slug: string
  image: string
  priceFrom: number
  text: L<{ name: string; short: string; intro: string; points: string[] }>
}

If someone adds a service and forgets the French text, TypeScript complains before the site ships. A composable picks the current language:

export function useTx() {
  const { locale } = useI18n()
  const tx = <T>(obj: L<T>): T => obj[locale.value as Locale] ?? obj.en
  return { tx }
}

In templates that reads naturally: {{ tx(service.text).name }}. No CMS, no API, and the whole site still generates as static HTML.

3. The feature local customers actually use: a postcode checker

The first question a visitor has is "do you even work where I live?". So the hero has a small form: type your postcode and get an answer, including whether there's a travel fee.

export const towns: Town[] = [
  { name: 'Bern', postcodes: range(3000, 3030), zone: 'free' },
  { name: 'Thun', postcodes: ['3600', '3602', '3603'], zone: 'fee' },
  // …
]

export const findTown = (code: string) =>
  towns.find((t) => t.postcodes.includes(code.trim()))

The result is announced in an aria-live region and links straight to the quote form with the postcode prefilled (/contact?pc=3600). It's a few lines of code, and it answers the question that would otherwise be a phone call.

4. Structured data from the same config

All business details live in one site.ts, which also feeds the JSON-LD:

useHead({
  script: [{
    type: 'application/ld+json',
    innerHTML: JSON.stringify({
      '@context': 'https://schema.org',
      '@type': site.schemaType, // HousePainter, Electrician, Plumber…
      name: site.name,
      telephone: site.phone,
      address: { '@type': 'PostalAddress', /* … */ },
      aggregateRating: { '@type': 'AggregateRating', ratingValue: 4.9, reviewCount: 137 },
    }),
  }],
})

Changing schemaType from HousePainter to Electrician is the only thing needed to reuse the site for another trade.

5. Motion without hiding content

For the scroll reveals I used a small directive, but content is only hidden after JavaScript runs:

.reveal-on .reveal { opacity: 0; transform: translateY(28px); transition: … }
.reveal-on .reveal.is-in { opacity: 1; transform: none; }
@media (prefers-reduced-motion: reduce) {
  .reveal-on .reveal { opacity: 1; transform: none; transition: none; }
}

The plugin adds reveal-on to <html> on the client. If JS fails or the visitor prefers reduced motion, everything is simply visible.

What I'd tell myself at the start

Decide on languages before writing content. Retrofitting i18n is where most of the time goes.
Keep business content out of components. Buyers (and clients) edit data files, not Vue templates.
Region-specific locales (de-CH) cost nothing and help local SEO.

The Lite version (English, home + service pages + contact) is free and MIT on GitHub: https://github.com/polyastavreva/handwerk-nuxt-lite

The full version with German and French, more pages and the animations is on Gumroad: https://stavreva68.gumroad.com/l/handwerk-nuxt-template

I'd love feedback on the i18n setup, especially from anyone running multilingual Nuxt sites in production.