Uses
The tools Doyel Labs builds with.
An itemized list of what we actually use, updated when the stack moves. Nothing aspirational, no affiliate links, no "we're thinking about migrating to." Just the tools that are on our machines right now.
Editor + AI tooling
Our AI-native workflow lives here. AI drafts, humans decide — every commit is authored by a person, every diff is read before merge.
Primary IDE (VS Code fork with a first-class AI agent)
One editor for code, chat, agent actions, and terminal — no context-switching to a separate AI window.
Primary drafting model for code, tests, migrations, copy
Reliably conservative on unsafe code paths. Good at reading a codebase and matching its style.
Inline autocomplete inside Cursor
Fast in-line completions where a full agent turn is overkill.
Framework + language
Web builds default to a static-first stack. When a project needs a full backend, we reach for the same shape (Cloudflare Workers + edge functions).
TypeScript
Default language for anything web-shaped
Strict mode on every project. Types are documentation that also fails the build.
Web framework
Static export by default; RSC where it helps; no lock-in on either.
React 19
UI library
Runtime validation of untrusted input
Every form payload / API body goes through a Zod schema before it touches anything else.
Node.js 24
Local build and script runtime
Backend + storage
Backends are chosen per-project. We prefer edge-first, per-operator-scoped storage that a client could migrate off of easily.
Cloudflare Workers + Pages Functions
Serverless runtime for public API routes
Low-latency edge execution, zero cold-start problem, KV bindings for rate limits.
Cloudflare KV
Rate limiting, feature flags, small key/value data
Netlify Blobs
Per-operator storage for the SteadFast payroll workspace
Each operator gets a scoped namespace — no shared-tenant risk.
Firebase (Auth + Firestore + Storage)
ConnectionLoop backend
SQL when a project needs it — sparingly
Serverless Postgres with branching for staging environments.
Deployment + CDN
Static output at the edge for marketing sites. Everything ships from Git.
Primary hosting for doyel-labs.com and every marketing site we ship
First-class custom headers, edge functions, and free HTTPS at scale.
CLI for Cloudflare Workers + Pages deploys
Netlify
Hosting when a client already runs there (SteadFast site + operator workspace)
Source hosting, PR-based reviews, Actions where useful
Comms + email
Client email lives on Google Workspace. Transactional email goes through Resend.
Google Workspace
Real email + calendar + Meet for orientation calls
Transactional email — contact-form delivery, stub emails from operator domains
Clean API, deliverability that actually works.
Zoom
Alternative to Meet for the one-hour orientation, if you prefer
Weekly async video walk-throughs during a build — clients open on their own time
Auth + payments
WebAuthn (passkeys)
Primary sign-in on payroll workspaces and BAI
Phish-resistant. No shared passwords.
PBKDF2-SHA256 / Argon2id
Password hashing where a password path is still supported
Anti-bot on the contact form (invisible to real users)
Replaces reCAPTCHA. No Google-owned cross-site tracker on our forms.
Payment processing when a build has billing (never for anything we sell directly today)
Card numbers live at Stripe. We only hold the last 4 and the subscription state.
Analytics + monitoring
Every marketing site we ship uses Plausible only, or no analytics at all if the client prefers.
Cookieless analytics for doyel-labs.com and client marketing sites
No cookies, no cross-site profile, no PII collected. GDPR-friendly by default.
Cloudflare Web Analytics
Secondary check on edge traffic for our own site
Sentry
Client-side error reporting when a build genuinely needs it
Turned off by default; only on when the client asked.
Design + assets
Sharp
Node-native image processing for optimization (mozjpeg, WebP)
Ships transitively with Next.js. Our optimize-images script uses it directly.
SVG by hand
Logo, icon, favicon, and every four-square mark render on the site
Vector, tiny, and colorable via CSS variables. No design-tool export needed.
next/og
OpenGraph card generation at build time
Inter
Sans-serif font family (system fallbacks handle everyone else)
JetBrains Mono
Monospace family for eyebrows, code, and small mono-typed labels
Legal + ops
Cloudflare Registrar
Domain registration for doyel-labs.com
At-cost pricing, no auction sniping, native DNS + WAF integration.
Wyoming (LLC)
Company jurisdiction — Doyel Labs LLC is a Wyoming LLC
MDX for legal drafts
Terms, Privacy, Payroll-data, and BAI Risk drafts live in content/legal/*.md
Counsel can redline them without touching TSX. Rendered by src/components/legal-page.tsx.
What we don't use
What we refuse, and why.
A tech stack tells you what a shop can do. A refusal list tells you what a shop values. These are patterns and tools we've deliberately kept out of every client build.
Google Analytics / Meta Pixel
Cross-site trackers. Every client site ships without them by default. Plausible covers what a small operator actually needs to know.
Session-replay tools (Hotjar, FullStory, LogRocket, Microsoft Clarity)
They record what your users type into forms. That's a privacy footgun that isn't worth the marketing insight. On our own contact form, we'd rather not have those keystrokes.
Chat / support widgets (Intercom, Drift, HubSpot chat)
The point of the /support/ page is that you email a real person. A widget suggests we'd rather triage you than answer.
Newsletter pop-ups + exit-intent modals
We ship one RSS feed and a real contact form. Anything else is a dark pattern.
Growth hacks (referral loops, gated content, tripwires)
If you can't sell the software honestly, growth hacks won't save it long-term.
Custom fonts for the sake of it
System fonts and Inter cover 99% of what we need. Every additional font is a network request plus a FOUT risk.
When we deviate
Your project may end up with a different stack.
The list above is our defaults. Client projects sometimes land on different tools because the client already owns them (an existing HubSpot instance, a WordPress site they don't want to migrate off, an AWS account they're committed to). We build against what you have, not against what we prefer.
You already own it
Your rules require it
Something is genuinely better
Curious about a specific tool?
Ask on the orientation.
We're happy to walk through why any tool on this list ended up in the default stack, or what we'd use instead if your project has a specific constraint. Bring the question to the orientation call — it's a good use of the hour.
This list moves as the stack does. When we adopt or drop something in production, it lands here first — this is the canonical answer to "what do you build with?"