The creation of qaryon: from solution architect to founder

After more than twelve years working for telecom integrators and operators, I founded qaryon in April 2026. It was not an impulsive decision — it was the logical consequence of a recurring observation: telecom integrators need senior expertise on the ground, not buried in an org chart.

This post tells the story of why, how I built the website, and what qaryon concretely means for an integrator or operator looking for a solution architect.

The problem: an industry that outsources expertise

The pattern is always the same. An integrator signs a UCaaS deployment contract for a 10,000-seat client. The pre-sales phase was led by a senior engineer who knows Microsoft Teams, AudioCodes SBCs, the subtleties of SIP routing, and the client's network constraints. The client signs with confidence.

Then the project kicks off, and the senior engineer moves to the next deal. The integrator assigns a more junior profile to the deployment. Not out of bad faith — out of structure. Seniors are scarce, expensive, and over-solicited. The result: projects that slip on SBC configuration issues, quality of service problems, or multi-vendor integration challenges that only an experienced profile would have anticipated.

I have lived this pattern from both sides. On the integrator side, designing architectures that others had to deploy. On the field side, stepping in on troubled projects to get them back on track. The gap between design and execution is the central problem of the trade.

qaryon exists to bridge that gap. A senior expert who designs and deploys. No handoff to a junior. No subcontracting. The same person from scoping to production go-live.

Why a website, and why now

Starting a consulting practice is first and foremost about being visible. In the B2B telecom ecosystem, LinkedIn is the primary channel, but you need a professional anchor point. A site that shows what you do, how you do it, and lets people get in touch.

I could have used a traditional CMS or a page builder. But I am a developer as much as a telecom architect. Building the site myself was both a matter of control and a demonstration of competence: if I claim to deliver technical solutions, the website should be one.

The tech stack: Next.js 16, React 19, Tailwind CSS 4

The site runs on a modern, minimal stack:

{
  "next": "16.2.3",
  "react": "19.2.4",
  "tailwindcss": "^4",
  "next-intl": "^4.9.0",
  "next-mdx-remote": "^6.0.0",
  "shadcn": "^4.2.0"
}

Next.js 16 and the App Router

Choosing Next.js 16 with the App Router was deliberate. The App Router brings Server Components by default — every page is server-rendered with no unnecessary JavaScript shipped to the client. For a B2B showcase site, this is exactly what you need: fast pages, strong SEO, and a minimal client bundle.

The routing structure follows the src/app/[locale]/ convention with next-intl for bilingual routing:

// src/i18n/routing.ts
import { defineRouting } from "next-intl/routing"

export const routing = defineRouting({
  locales: ["fr", "en"],
  defaultLocale: "fr",
  pathnames: {
    "/": "/",
    "/services": "/services",
    "/about": "/about",
    "/contact": "/contact",
    "/portfolio": "/portfolio",
    "/blog": "/blog",
  },
})

Each page receives the locale via params (a Promise in Next.js 15+) and calls setRequestLocale to configure the translation context:

// src/app/[locale]/page.tsx
export default async function HomePage({ params }: Props) {
  const { locale } = await params
  setRequestLocale(locale)
  // ...
}

Why bilingual from day one

qaryon targets integrators and operators in France, but also in Switzerland and internationally. The site has been bilingual French/English since the first commit. next-intl handles translations via JSON files in messages/fr.json and messages/en.json, with the useTranslations hook in components:

export function HeroSection() {
  const t = useTranslations("home.hero")
  return (
    <h1>{t("title")}</h1>
    // FR: "Architecte Solutions."
    // EN: "Solution Architect."
  )
}

This choice has an upfront cost — every piece of text must exist in both languages — but it would have been far more expensive to retrofit internationalization later. The routing architecture, SEO metadata, Open Graph images: everything depends on the locale.

Tailwind CSS 4 and shadcn

Tailwind CSS 4 with PostCSS provides the design system. UI components come from shadcn/ui (v4), which generates React components directly in the project rather than importing them from a package. This allows full customization with no external dependency.

The theme uses two fonts loaded via next/font/google: Raleway (weight 300) for the logo and brand, Inter for body content. The primary color is a purple (#a855f7) that runs through the entire site, from the hero section to the Open Graph images.

Site architecture: Server Components everywhere

The homepage is composed of six sections, all Server Components except the waitlist form which requires client-side interactivity:

// src/app/[locale]/page.tsx
<HeroSection />
<ServicesPreview />
<WhyQaryon />
<CtaSection />
<Testimonials />
<SaasTeaser />  {/* "use client" — contains the form */}

This split is intentional. A Server Component ships zero JavaScript to the browser. For a showcase site, the vast majority of content is static: headings, descriptions, service lists. Only what requires user interaction (the contact form, the waitlist, the theme switcher) is marked "use client".

The result: a fast initial load, a high Lighthouse score, and native SEO since all content is in the initial HTML.

The blog: MDX without a CMS

The blog uses MDX via next-mdx-remote with files stored in content/blog/. No CMS, no database, no external API. Each post is an .mdx file with YAML frontmatter:

---
title: "The creation of qaryon"
description: "..."
date: "2026-04-13"
tags: ["qaryon", "next.js"]
locale: "en"
---

The gray-matter library parses the frontmatter, and next-mdx-remote renders the MDX content in a Server Component. Posts are filtered by locale — an .en.mdx file only appears on the English version of the site.

This choice is consistent with the project philosophy: no external dependencies, no third-party services, a simple deployment on Vercel via git push.

"We design, we deploy" — not just a tagline

The "Why qaryon" section on the site presents three pillars:

Direct senior expert — no intermediary, no subcontracted junior
Deliverables-driven — every engagement produces concrete results (documentation, architectures, configurations)
We design, we deploy — not just consulting, but end-to-end delivery

This third pillar is the core proposition. In traditional telecom consulting, the expert produces an architecture document and hands it off to the project team. With qaryon, the expert who designed the architecture is also the one configuring the SBCs, testing SIP flows, and validating quality of service in production.

This is exactly what this website does: I designed, developed, optimized, and deployed it. The 45 commits in the repository reflect an iterative process — from the initial Next.js setup to Open Graph image optimization for LinkedIn, through content adjustments after my own reviews.

What comes next

qaryon is today a consulting practice. The site already announces what is coming: a SaaS platform for telecom integrators, designed to simplify the management, deployment, and monitoring of communication infrastructures.

The waitlist is open on the homepage. The form uses Resend for email delivery, with Zod validation server-side and react-hook-form client-side — the same technical rigor as a VoIP deployment.

In the meantime, the work continues: consulting engagements, technical articles on this blog, and continuous improvement of the site. Forty-five commits in four days is a start. The next chapter is being written in production.

qaryon — Consulting, audit, and training for unified communications. Get in touch.