When we started Lojik Labs, the default shape of a consumer product team was six to twelve people — a backend engineer, a mobile engineer, a frontend engineer, a designer, a product manager, plus the PM tax. That team could ship maybe one major feature a month, service 50k users, and break even on $30k MRR.

We now ship the same feature in a week. One person.

What "one builder per vertical" actually means

Every product in our portfolio has exactly one engineer. Not "tech lead plus a contractor." Not "me plus my cofounder doing design." One person owns the schema, the API, the UI, the infra, the ops, the support queue.

The only shared resource is the infrastructure layer — Supabase org, Vercel team, Sentry project, the auth/billing pattern library we copy into every new product.

Why this works now

Three things changed at the same time, and they compound:

1. AI collapsed syntax cost. Writing CRUD code, wiring up auth, porting between APIs — this is 80% of an engineer's week at most companies. Claude does it in minutes. What you spend time on is judgment: what to build, what to cut, what to defend.
2. Infrastructure got free. Supabase, Vercel, Clerk, Stripe — the boring parts of software used to cost a platform team. Now they cost $50/month per product until you have real revenue.
3. Distribution got weirder. Niche markets stopped being reachable by ad spend. They got reachable by WhatsApp, by Reddit threads, by one well-placed Twitter post. That rewards operators who understand the niche, not marketing teams who optimize funnels.

What it doesn't work for

Horizontal SaaS with a million competitors. Anything where the moat is sales muscle. Anything that needs 24/7 human support from day one.

It works for vertical software — clinic scheduling in Spanish, bar-crawl coordination on a specific college campus, sportsbooks in Mexico. Markets too small for a16z but big enough for one engineer to live well off.

The studio model

Lojik Labs is the meta-layer: shared Supabase org, shared auth pattern, shared design system, shared Claude Code workflows, shared legal. Each product gets one builder who keeps 25–40% of their vertical's upside.

We're testing the hypothesis that a well-run studio of solo builders outperforms a single well-staffed startup at this scale. The portfolio is eleven products deep so far. We'll tell you in 2027 how it went.

The mental model

Claude Code is a team, not a tool. The main conversation is the orchestrator — it routes, decides, and synthesizes. Specialized agents do the work in isolated contexts. MCPs handle service calls. Skills encode workflows.

If I'm reading files or writing Python, something's wrong with my routing.

The four-tier hierarchy

What this looks like in practice

"Ship the new booking flow" isn't me writing code. It's:

1. /ship skill routes me through test → review → commit → PR
2. security-reviewer agent audits the diff in parallel
3. mcp__plugin_supabase_supabase__apply_migration runs the schema change
4. mcp__plugin_vercel_vercel__ triggers the preview deploy
5. I read the agent reports, approve or iterate
6. Main context writes a handoff note to tasks/session-state.md for the next session

Total time from "ship it" to merged PR: roughly 20 minutes for a typical feature. Most of that is me reading agent output.

The rule that actually matters

Delegate before you explore. The default trap is to start reading files to "get context" before routing. By the time you're oriented, you've burned 40% of your session on grep output that a subagent could have produced in parallel.

If a task will touch 2+ files, spawn an agent. If it needs deep codebase exploration, spawn an Explore agent. You write the prompt, it does the reading, you read the summary.

What I don't use Claude Code for

• Naming variables. I name things; AI picks boring names.
• Product decisions. AI has no skin in the game.
• Writing this post. I write the ideas, AI edits for tightness.

The skill ceiling of this workflow isn't "prompt better." It's "understand your own product better, so your taste scales." AI is leverage on judgment, not a substitute for it.

MediVoz picks up that WhatsApp thread, books the appointment, syncs to the clinic's calendar, and sends a reminder the day before. In Spanish, with the regional courtesies. No human involved unless something unusual happens.

Why US healthtech can't serve this market

Rectangular economics. A typical US healthtech sale is $8–15 per patient per month, contracted annually, routed through a Zocdoc or SimplePractice sales team. That motion doesn't make sense for a 2-doctor clinic in Tepic charging 600 pesos per consult.

The actual ACV we can hit is ~$40/month per clinic, pay-as-you-go, WhatsApp-first onboarding. No US cap-table company is going to build that stack.

The architecture

• Voice layer: Twilio SIP trunk into a Deepgram streaming ASR, Claude Sonnet for intent + response, ElevenLabs for TTS. Median latency around 700ms with barge-in detection so the agent yields when the patient starts talking.
• WhatsApp layer: Twilio's WhatsApp Business API. Same Claude prompt, different modality.
• Calendar layer: Supabase Postgres with RLS scoped per clinic, integrated with Google Calendar so doctors see appointments in whatever tool they already use.
• Ops: Sentry + PostHog for per-clinic observability, BullMQ for appointment reminders.

What took the longest

Not the voice stack. Not the prompt. The hard work was the cultural part — training Claude to handle the specific formalities Mexican patients expect ("Con mucho gusto", "Para servirle"), to recognize when a patient is in distress vs just confused, and to know when to escalate to a human operator.

We spent two weeks labeling conversations. The voice pipeline took three days.

What I'd tell another solo builder

Find the market where the product is "technology US companies already have, but adapted for a context US companies don't understand." That's not one-off work. That's every Spanish-speaking country, every language, every underserved vertical.

It requires you to care about the niche — to have family in Guadalajara, to text in Spanish slang, to know why a clinic that takes solo efectivo can't use Stripe. Taste is a moat. So is location.

The naive approach (don't do this)

You put 241 <img> tags in the DOM, each with position: absolute. You toggle opacity as the user scrolls. It looks fine on a MacBook and dies on an iPhone — layout thrashing, memory bloat, GPU stalls while compositing two hundred layers.

What we do instead

One <canvas>. Draw one frame at a time. Two-stage load: critical batch first (covers state-1 and state-2 entry), then 6 parallel workers chew through the rest in the background.

function loadFrame(idx) {
  return new Promise((res) => {
    if (images[idx]) return res();
    const img = new Image();
    img.decoding = "async";
    img.onload = () => { images[idx] = img; res(); };
    img.onerror = () => res();
    img.src = `/frames/frame_${String(idx + 1).padStart(4, "0")}.webp`;
  });
}

Plain new Image(), not createImageBitmap. Safari stalls on bitmap creation; the decoded image cache is fast enough after the first paint.

The lerp that sells it

A raw scroll-to-frame mapping feels stepped. You scroll half a line and the canvas jumps two frames.

The fix is a lerp between a scroll-derived target and a rendered value that chases it:

function tick() {
  const diff = targetFrame - renderedFrame;
  if (Math.abs(diff) < 0.01) {
    renderedFrame = targetFrame;
    lerpRunning = false;
  } else {
    renderedFrame += diff * 0.14;
  }
  const idx = Math.round(renderedFrame);
  if (idx !== cur && images[idx]?.complete) {
    draw(idx);
    cur = idx;
  }
  if (lerpRunning) requestAnimationFrame(tick);
}

A lerp factor of 0.14 at 60fps is roughly a 6-frame settle. Any faster and you lose the tactile weight that hides frame stepping. Any slower and it feels laggy.

File format

WebP at quality 78. Ran the sequence through cwebp with -q 78 -m 6 and it took the total from 33MB (JPEG) to 4MB. On real 4G connections the critical batch (first 40 frames) lands in under 1.5s.

The blend-mode trick

The source video had a grey volumetric-light haze around the glass subject. Straight image rendering showed the haze competing with page background.

The fix: mix-blend-mode: screen plus an aggressive filter: brightness(0.55) contrast(1.75). Screen-blend drops dark pixels into the page bg. Crush the grey haze to near-black before the blend and only the bright glass plus the light shaft paint through. Costs one GPU layer composite. Looks expensive, isn't.

Reduced motion

On prefers-reduced-motion: reduce, we skip the whole system — replace the canvas with a single static image at frame 120, collapse the 300vh runway to auto, show only the first text state. No rAF loop, no scroll listener, no accessibility violation.

Framework-less doesn't mean primitive. It means you understand every line.