RC-00 · Six stations · one path

Process —how a Crayont project runs, from spec to hand‑over.

You get a written spec before any design, working software early, and a live build link every week. Performance, accessibility and SEO budgets are agreed up front, and nothing ships until it's inside tolerance.

Spec
Written, before any design
Staging
Live link, updated weekly
Progress
Written note every Friday
Fix window
30 days after launch

S-01Toolpath

Six stations. One path.

Every project runs the same route. Each station ends at a gate you sign off, so the next one never starts on a guess.

  1. ST-01 · OP 010

    Brief

    A 30-minute call and a short written brief: what it is, who it's for, what 'done' means, and your budget band. You get an honest yes, no or 'not yet' within one working day.

    What you get
    • An honest yes, no or 'not yet' within one working day
    • A reply from the people who build it, not a ticketing system
    How long
    30-min call · answer within 1 working day
    You provide
    • What it is and who it's for
    • What 'done' means to you
    • Your budget band and any fixed dates
    • Links, a Figma file or a voice note

    Gate 01Fit confirmed

  2. ST-02 · OP 020

    Spec

    A written specification before any design: scope, pages or features, timeline, price, and the tolerances we'll ship inside (load time, Core Web Vitals, accessibility, SEO).

    What you get
    • Scope: pages or features, in writing
    • Timeline and a fixed price
    • Tolerances: load time, Core Web Vitals, accessibility, SEO
    • Named specialists, if the project needs any
    How long
    About 1 week[Founder to confirm]
    You provide
    • Access to your current site, analytics and Search Console (redesigns)
    • Brand assets and existing content
    • One person who can sign the spec off

    Gate 02Spec signed by you

  3. ST-03 · OP 030

    Prototype

    The riskiest part gets built first, in the browser, so you react to real software instead of static mockups.

    What you get
    • The riskiest part, built first, in the browser
    • A link you can open on your own devices
    • Decisions made on real software, not static mockups
    How long
    Weeks 1–2[Founder to confirm]
    You provide
    • Real content samples, so it is tested with real words
    • Your reactions, on the prototype link

    Gate 03Approach approved

  4. ST-04 · OP 040

    Build

    Production code from week two, with a live staging link updated every week and a short written progress note every Friday.

    What you get
    • Production code from week two
    • A live staging link, updated every week
    • A short written progress note every Friday
    How long
    From week 2 · length fixed in the spec
    You provide
    • Content on the dates agreed in the spec
    • Feedback on the staging link
    • Decisions flagged in the Friday note

    Gate 04Feature-complete on staging

  5. ST-05 · OP 050

    Measure

    Performance, accessibility and SEO are tested against the spec on real devices. Nothing ships until it's inside tolerance.

    What you get
    • Performance tested against the spec's budgets, on real devices
    • Accessibility checks against the agreed standard (typically WCAG 2.2 AA)
    • SEO checks: metadata, structured data, redirects
    • Fixes until every number is inside tolerance
    How long
    Final week, plus checks during build[Founder to confirm]
    You provide
    • Final content sign-off
    • Access to domain and DNS for launch

    Gate 05Inside tolerance

  6. ST-06 · OP 060

    Hand over

    Launch, a dated measurement report, documentation and full ownership of code and accounts. A 30-day fix window is included; a care plan is optional.

    What you get
    • Launch
    • A dated measurement report
    • Documentation
    • Full ownership of code and accounts
    • A 30-day fix window; a care plan is optional
    How long
    Launch day + 30-day fix window
    You provide
    • Hosting, domain and CMS accounts in your company's name, so ownership is clean

    Gate 06You own everything

S-02Weekly rhythm

A week inside a build.

From week two, the software is live on a staging link you can open any time. Every Friday you get a short written note: what shipped, what's next, what we need from you.

Timing diagram · one build week Now, IST
BuildWorking days
Staging linkLive all week · updated every week
Friday noteWritten progress note
Your inputComment any time on staging

Working days and hours: [Founder to confirm]. Weekends are quiet unless a launch says otherwise.

  • W-01

    Working software from week two. Production code, not mockups, on a staging link that stays live.

  • W-02

    A written note every Friday. Short, dated, and in your inbox, so progress never depends on a meeting.

  • W-03

    Decisions with dates. If something needs you, the note says what, and by when, so nothing stalls quietly.

Friday note · Week 04Format

To: you · From: Crayont · Project: [Your project]

Shipped this week
What merged to staging, each with a link.
Next week
What's planned, against the spec.
Needs from you
Decisions or content, each with a date.
Tolerance check
LCPmeasuredvs budget in specCLSmeasuredvs budget in specA11ychecks runvs agreed standard
Template · not a real project

S-03Engagement models

Three ways to engage.

Every model starts with the same brief and ends with measured numbers. Scope and starting ranges are on the services pages.

Engagement models compared
ModelBest forStarts withPriceEnds with
EM-01ProjectBuild or redesignNew sites, redesigns, 3D/WebGL sites and web-app phasesA brief, then a written specFixed, agreed in the specHand-over, report and a 30-day fix window
EM-02AuditPerformance & technical SEOSlow sites, failing Core Web Vitals, pre-redesign checksAccess to the site, analytics and Search ConsoleFixed fee [Founder to confirm]A prioritised fix list, with measured baselines
EM-03Care planAfter launchSites and apps that need a senior engineer on callA baseline measurementMonthly [Founder to confirm]A measured report every month

Scope, deliverables and starting ranges

S-04Tolerances

What tolerance means here.

In a machine shop, a tolerance is how far a part may drift from its drawing and still be accepted. On a Crayont project the drawing is the spec, and the tolerances are numbers.

12.03 · Accepted12.07 · RejectedExample: a 12 mm part, ±0.05 mm. Anything from 11.95 to 12.05 passes.

Same idea, different units. Before design starts, the spec fixes the numbers your site has to hit. Before launch, they're measured. If a number is out of tolerance, it doesn't ship.

The limits below are typical examples. Core Web Vitals use Google's published thresholds for a good experience; the real set for your project is agreed in writing, in the spec.

  1. TOL-01Largest Contentful Paint≤2.5 sLoad · 75th percentile of real visits
  2. TOL-02Interaction to Next Paint≤200 msResponsiveness · 75th percentile
  3. TOL-03Cumulative Layout Shift≤0.1Visual stability · 75th percentile
  4. TOL-04Accessibility=WCAG 2.2 AAAutomated checks + keyboard and screen-reader passes
  5. TOL-05Redirect coverage=100%Redesigns · every indexed URL mapped
  6. TOL-06JavaScript budget≤Per specThis site's own budget: 100 KB before 3D loads

Try it · the gate

3.4 s

Out of tolerance: fix, re-measure, then ship.

S-05Questions

Straight answers.

The questions people ask on the first call, answered first.

10 checks logged

Q-01What is Crayont?

Crayont is an independent design-engineering studio based in India and working with clients worldwide. It designs and builds websites, website redesigns, web apps and 3D/WebGL websites, and builds its own products under Crayont Labs.

Q-02Who will I actually work with?

The people who design and code your project, directly — on the first call, in the design files and in the code. No account managers. When a project needs a specialist such as a 3D artist, copywriter or backend engineer, we bring in someone we have worked with before, and you'll know their name and role from day one.

Q-03Where can I see your past work?

On the Work page: Himalaya Offset, an online print shop for a Vellore printing press, and Madrasa Rahmaniya, a donation website. Each case study links to the live site, with the stack and the numbers it launched with.

Q-04How much does a project cost?

[Founder to confirm]Projects are fixed-price after a written spec. Typical starting ranges: websites and redesigns from {X}, web apps from {Y}, 3D/WebGL sites from {Z}. Care plans are monthly.

Q-05How long does a website or web app take?

[Founder to confirm]Most marketing sites take 4 to 8 weeks, redesigns with SEO migration 6 to 10 weeks, and web app phases 8 to 16 weeks. The spec fixes the timeline before work starts.

Q-06Will a redesign hurt our Google rankings?

Not if it's migrated properly. Every redesign includes a URL audit, a full redirect map, preserved metadata and structured data, and post-launch monitoring in Google Search Console.

Q-07Does 3D/WebGL make a site slow?

It doesn't have to. The page content loads first, 3D loads afterwards only on devices that can handle it, and every scene has a static fallback. Performance targets are agreed in the spec.

Q-08Which technologies do you use?

Typically Astro, TypeScript, React where interactivity needs it, Tailwind CSS, GSAP and Three.js, deployed on Vercel, with a headless CMS for content. Existing stacks are fine for web app work.

Q-09Do you work with clients outside India?

Yes. Most clients are in Europe, North America and the Middle East [verify]. Working hours in IST (UTC+5:30) overlap with European mornings and US evenings, and every week includes a live staging link and a written update.

Q-10What happens after launch?

You get a dated measurement report, documentation, full ownership of code and accounts, and a 30-day fix window. Monthly care plans cover updates, monitoring and small features.

ST-01 · Your project starts here

Start at station 01.

A 30-minute call and a short written brief. Within one working day you'll know whether it's a yes, a no or a "not yet", and why.