Noveno

Noveno (نوونو) is a customer-acquisition system for small and medium service businesses in Iran. Its job is singular: turn scattered visits — from Instagram, Google, referrals, prior customers or ads — into a single, trackable path from attention to inquiry, registration and measurable follow-up. Every request is stored with source, status and next step.

The public site is noveno.ir. This case study is not a duplicate of that sales site. It is the founder view from my side: what problem space Noveno targets, what system is being built, how the customer journey is considered, and what product and implementation decisions that forces — without pricing, packages or lead-form funnels repeated here.

The failure is rarely lack of visits. It is what happens after a visit: a message stays in a DM, a phone call is never logged, follow-up relies on memory, and no one knows which channel produced which request. Business owners see interest but lose the thread between attention and a registered, actionable lead.

• Requests are scattered across channels — DM, phone, message, introduction — with no canonical place.
• Source of entry is unrecorded; follow-up depends on whether someone remembers to chase it.
• Result is opaque to the decision-maker: no comparable funnel, no bottleneck visibility.
• Local conditions matter: mobile-first users, unstable internet, tools that are actually available, and interfaces that degrade gracefully.

Noveno treats this as a system problem, not a traffic problem. Buying more attention before fixing the path after attention is waste — more spend, same leak. The first step is therefore diagnosis, not delivery.

The system is organized as six stages every inbound attention must pass through until a registered, trackable request exists:

A compact version appears on the live site as Attention → Request → Registration → Follow-up. The point is ordering, tracking and the ability to compare — without requiring the owner to draw a diagram themselves.

How the journey is considered

Joining this journey means fixing the second half before amplifying the first. A typical early engagement starts with بررسی مسیر جذب (acquisition-path review) — a low-friction diagnosis of where requests leak today: messaging, landing/CTA, phone path, and the visibility of source. Only then is the system scoped to the actual problem; not every component for every business.

The offers are not a long service menu — three defined paths chosen depending on the business’s situation. Everything on the site is either truly built or explicitly labeled “concept — نمایشِ مفهومی” when it is a scenario.

I am the founder and product owner. I own problem definition, business-system thinking, and the web implementation that proves the philosophy on its own site. The work is deliberately business-first — technology serves the business problem, not the opposite — and measurable wherever comparison is practical.

• Product thinking: narrowed the system to one fixable idea (leak after attention), defined the four-to-six stage framing, and made “no guaranteed sales” the non-negotiable honesty line — indicators are defined and measured from real data, results reported only to the extent data allows.
• Business systems: scoped collaborations so the audit precedes system build, and monthly accompaniment stays bounded. The system segments visible work (landing, log) from the harder work (message path, phone/message route, lead registration by source, status-bound follow-up).
• Web implementation: built the production website as a static, Persian-first, RTL-first product that itself implements the philosophy — registration, attribution measurement and staged follow-up — without inventing dashboards.

Noveno remains clearly separate from my personal professional identity. This portfolio presents it as Building Noveno, not as a services page or duplicate pricing funnel. The live site remains the canonical commercial source; this page links to it rather than competing with it.

The website is an Astro 7 + TypeScript site, statically rendered and deployed to Cloudflare Pages — no SSR. There is no client UI framework (no React/Vue/Svelte); interactivity is framework-free TypeScript modules (src/scripts/: theme, menu, audit form state machine, analytics).

• Content: Astro Content Collections for work entries with mechanically enforced honesty types: project (real, no outcome claims), concept (scenario — metrics forbidden, goals/KPIs required), case-study (verified client + verified metrics with source). A test suite rejects fabricated proof.
• Fonts: Estedad (display, 800) + Vazirmatn (body) as self-hosted variable woff2 under public/fonts/, ~165 KB total, font-display: swap, metric-matched Tahoma fallback for CLS ≤ 0.1.
• Theme: Persian-first, RTL-first, light (“روز کاری”) and dark, system default with persisted override — no theme flash on first paint.
• Lead delivery: No database. Leads are delivered as email via Web3Forms — the sole lead destination. Attribution (UTM / referrer / landing) rides in the email, not a database.
• Analytics: Cloudflare Web Analytics (baseline) plus a Pages Function events endpoint (/api/events with Analytics Engine binding NOVENO_EVENTS) for custom acquisition events.

Why this shape

• Static by default. Marketing sites rarely need SSR. Static generation plus CDN gives the fastest path for mobile RTL users without runtime infrastructure.
• One function, not a backend. The audit form is the only business-critical write path — isolating it as functions/api/audit.ts minimizes attack surface and operational cost. The secret (TURNSTILE_SECRET_KEY) lives only in Pages secrets; build-time publics (PUBLIC_TURNSTILE_SITE_KEY, PUBLIC_WEB3FORMS_ACCESS_KEY) never carry secrets.
• Email-only delivery was a deliberate choice. The 2026-10 founder decision removed Supabase entirely. Free-tier Web3Forms requires client-side posting, which trades direct-POST risk for zero database ops. Mitigation is an HMAC validation receipt so the inbox can distinguish validated leads; a future migration (D-01 in the repo) removes the direct-POST vector entirely — explicitly documented as debt, not hidden.
• No secrets in bundle, no logs with content. The site never commits values; Pages Function logging excludes lead content; analytics is Cloudflare-native so no third-party PII store is introduced.

• No client framework. The sales surface does not need React — framework-free TS modules cover theme, menu, form state and analytics with far less JS. The constraint avoids hydration cost on the landing.
• No flowchart visual language. Founder rejection (2026-08-14): drawn routes, stations and node-and-line diagrams are rejected because they feel technical, small, noisy and weak in hierarchy. The system is communicated via typography, real product UI and editorial numerals instead — the word “مسیر” survives only as product vocabulary.
• Real product UI over stock photography. The 2026-09 product-led pass retired contextual business photography. Hero became an original inline-SVG brand artwork (scattered → ordered system, ~4 KB, no raster), and proof moved below the hero to real product screenshots capped at 4–7 media moments per long page.
• Honesty mechanically enforced. The work content schema rejects a metric without verified: true + source, and forbids metrics on concept entries entirely. Rendering (tags, dashed concept borders, “نتیجه: در دست اندازه‌گیری” for projects) is automatic — authors only fill frontmatter honestly.
• Free-tier compatible. Pages free tier is the constraint: Web3Forms email, Analytics Engine and Pages Functions are chosen for compatibility, not because they are theoretically optimal at scale.

AI coding tools were used for implementation, research, debugging, repetitive tasks, and iteration. Requirements, architecture, verification, testing, and final responsibility remained explicit parts of the development process.

For Noveno that meant: scaffolding Astro components and Pages Functions, explaining Cloudflare Turnstile and wiring siteverify, iterating on Persian typography and RTL layouts, and speeding up repetitive wiring without adding a heavy runtime. No step was gated on a model — validation, turnstile secret handling, Web3Forms delivery success (and the honest “not available” fallback with direct-contact options when keys are absent) and the measurable-with-evidence rule remained human decisions.

• Communicating a system without drawing it — after rejecting diagrams, the site had to prove systematism through editing, ordering and real interfaces alone.
• Building for real Iranian conditions — mobile, unstable internet, available tools and replaceability — without inventing an idealised tool stack that would immediately break on re-entry.
• Keeping the personal site and the commercial site clearly separated so one does not become the funnel for the other — hence “Building Noveno” framing, not a duplicate offer page.
• Handling lead delivery without a database while retaining honest error semantics — the user reaches /audit/thank-you only after Web3Forms confirms acceptance; server validation alone never presents success, and duplicates remain distinguishable via submission_id.
• Maintaining Persian editorial quality at a premium level under the rejected-photography, no-framework, no-WGL, no-glassmorphism constraints.

The main gates are npm run check (Astro check — types + content schema), npm run build (static + prebuild image-manifest, OG validation, sitemap), and node --test tests/*.test.mjs (content honesty contract, sitemap/page correspondence, product-specific invariants) — composed as bash scripts/verify.sh. Prebuild enforces image manifests and OG assets; failures are build-breaking, not warnings.

Manual checks prove the audit boundary: without PUBLIC_TURNSTILE_SITE_KEY + PUBLIC_WEB3FORMS_ACCESS_KEY the form still validates locally and shows the honest “not available” fallback with direct-contact options (phone, WhatsApp, Telegram, email). With keys, the flow is validated → posted → confirmed before success. Accessibility and contrast are measured against WCAG 2.2 AA (light #070808 on #f9fafa 19.2:1, etc.) and performance budgets stay ≤200 KB for fonts, no heavy JS.

The flagged production-equivalent build — Astro app, all public routes, the audit flow plus Pages Function trust boundary, Turnstile + Web3Forms delivery, analytics, SEO/production artifacts, visual redesigns (typography + real product UI, brand artwork, وبلاگ) and the email-only architecture — is committed and verified as bash scripts/verify.sh per the repository’s own plan. The site proves the same philosophy it sells: scattered attention → a single registered place → status-bound follow-up → measurement within a defined scope, with AI helping and a human deciding.

What is still open before launch is founder provisioning: Cloudflare Pages secrets for Turnstile and Web3Forms, DNS wiring, a preview-deploy smoke, and final approval of privacy/terms copy. No visits, conversion rates or lead counts are claimed — the work entry for the production site itself is type project with outcome: measuring and no metric until real data exists. A real, verifiable case study will be added to src/content/work only when a client and citable source both exist.

Because this case study must not duplicate the sales site, media here is restrained and honest. The personal site deliberately avoids repurposing Noveno’s marketing photography as portfolio proof. The frames below are the media slots that will receive real product imagery — and the link to the live product remains the primary way to see it.

Primary external destination: noveno.ir ↗— Persian, RTL, light/dark, no invented metrics. Open in a new tab.

The canonical commercial presence is noveno.ir — services, process, blog, about and audit. The code lives in a private repository (noveno-website), with escaped secrets, signed boundaries and sitemap-gated proof. Every statement here should be traceable to one of those two places.

No pricing, form or package is mirrored from the sales site here. If you are evaluating product thinking, this page is the read; if you are evaluating a purchase, the live site is the read.