Lane
- Status
- Private beta
- Case type
- Founder-built SaaS / AI-native product strategy
- Build mode
- Solo, AI-assisted development
- Timeline
- ~4 months
- Stage
- Working product
Lane is an AI-native design operations platform built from a lived design-leadership problem.
Product teams often manage design through engineering-shaped task tools. Jira, Linear, Asana, and Notion make work visible as tickets, tasks, and updates. But design work is not only task completion. It is framing, questioning, exploring, rejecting, deciding, and proving.
Lane is my attempt to build the operating system I wished existed for design teams.
- ~4 months
- Solo private-beta build
- 40+
- Product screens
- 20+
- Core workflows
- 60-70K
- Lines of code
- 1 wedge
- AI Intake Gate
Design work was being managed through the wrong model.
Engineering teams have Linear. Design teams need Lane.
Most workflow tools assume work equals tasks. That works for engineering because much of the work can be broken into discrete, binary tickets.
Design does not work that way.
The most valuable design work is often invisible to a tracker: understanding, reframing, exploring alternatives, killing weak directions, aligning stakeholders, and deciding what should be built.
When designers are managed only through task movement, they optimize for visible progress instead of better decisions.
Work is not the unit. Decisions are.
Jira and Linear optimize for task movement. Lane optimizes for decision quality.
The thesis behind Lane is simple: design operations should not only show what moved. It should improve what gets worked on, how it gets framed, how decisions are made, and whether shipped work created impact.
Lane treats design as a decision system, not a ticket factory.
Surveillance produces performance. Support produces truth. Lane optimizes for truth.
The wedge: AI Intake Gate
The AI Intake Gate is Lane's riskiest and most important product bet.
Before a request enters the system, Lane checks whether it is problem-framed or solution-specific.
A request like "add a dark-mode toggle" does not pass just because it looks actionable. Lane asks for the problem behind it.
The product moment is simple: block the solution, preserve the signal, and help the requester reframe the work before it reaches design.
Built broadly. Launched narrowly.
Lane was built as a full design operating system, but the private-beta launch surface is intentionally smaller.
The hardest product decision was not building more. It was hiding most of the product to validate the riskiest assumption first.
The full system includes Predesign, Design, Build, Track, a non-linear design pipeline, Prove gates, Figma sync, PM calibration, weekly digest, morning briefing, Design Radar, and impact tracking.
But the v1 launch focuses on one question:
Can an AI gate change how PMs frame work before it enters the design pipeline?
Lane is an AI-native design operations platform: an operating system for design teams.
It replaces solution-driven ticket intake with a problem-first workflow designed for how design thinking actually works: iterative, non-linear, and exploratory.
End-to-end model
- PM identifies a problem
- AI gate checks the framing
- Org shapes and bets on it
- Designer explores through scientific stages
- Developers build
- PM measures actual impact
AI runs the operations layer. Humans make the decisions.
PM + org
Predesign
Requests are framed, enriched with context, shaped, and either bet on, killed, or deferred.
Designers
Design
Designers move non-linearly through Sense, Frame, Diverge, Converge, Validate when needed, and Prove.
Developers
Build
Handoff-ready work moves into a developer kanban, with design QA required before completion.
PMs
Track
After launch, PMs log actual impact so predicted impact can be compared with reality.
The Intake Gate classifies every request before it becomes work.
Verdicts
- problem_framed
- solution_specific
- hybrid
Actions
- Use rewrite
- Edit description
- Request admin override
If a request is problem-framed, it passes.
If it is solution-specific or hybrid, Lane blocks it and explains why. The system keeps the problem signal but separates it from the prescribed solution.
Gate message
“This looks like a solution, not a problem. Lane works best when designers understand the WHY before the WHAT.”
The original design included a soft 'submit anyway with justification' escape. It was removed because soft escape valves erode strong forcing functions. The override still exists, but it requires admin approval and leaves a visible audit trail.
Lane's strongest product principle is that design teams do not produce better thinking when they feel watched.
The product deliberately avoids individual utilization scores, last-active timestamps, designer speed rankings, timers, and automatic escalation of designer silence.
Instead, Lane supports private nudges, team-level health, capacity, reflections, transparent AI reasoning, and human override.
This is not a marketing principle. It is a build constraint.
Never build
- Individual utilization %
- Last active / last seen timestamps
- Per-designer speed ranking
- Time-per-task tracking
- Automatic escalation of designer silence
- Overdue labels on design work
Always build
- Private AI nudges first
- Team health, not individual surveillance
- Designer-owned capacity
- Reflections in the designer's own words
- AI recommendations with reasoning
- Human override for AI suggestions
Lane is a working private-beta product, not a concept deck.
Built in ~4 months, solo, through AI-assisted development, the product currently includes around 40 screens, 20 core workflows, 60-70K lines of code, database tables/modules, and most AI features working.
- AI Intake Gate
- Admin override
- Auto-triage
- 4-phase model
- 5-stage design flow
- Prove gate
- Dev kanban
- Figma OAuth
- Impact tracking
- PM calibration
- Idea board
- Weekly digest
- Morning briefing
- Design Radar
- Role-based access
- Notifications
- Onboarding
The private-beta launch does not expose everything that has been built.
The v1 surface is deliberately narrowed to the AI Intake Gate, a stripped PM-intake loop, go-live and impact-date fields, in-app notifications, impact-delay counter, functional tags, admin override flow, and six lifecycle states.
Lifecycle states
- Created
- Assigned
- In progress
- Done
- Launched
- Impact marked
Hidden / deferred from v1
- 5-stage design pipeline
- Figma sync
- Idea board
- Weekly digest
- Morning briefing
- PM calibration
- Design Radar
These features are dormant, not deleted. The product is a single-product progressive launch, not a tiered offering.
Lane was built with a modern AI-native SaaS stack:
- Next.js App Router
- TypeScript
- Supabase
- Drizzle ORM
- Supabase Auth
- Claude via Vercel AI SDK
- Tailwind
- shadcn/ui
- Vercel
- Upstash Redis
- Resend
- Figma OAuth
- Stripe later
Built solo through AI-assisted development. The current popular shorthand would be 'vibe coding,' but the actual work was product judgment, system design, and relentless pruning.
Lane is in private beta with a progressive go-to-market motion.
The first GTM motion does not try to sell the entire design operating system. It tests whether design leaders and PMs feel the value of better problem framing before work enters the pipeline.
The first proof is not revenue or scale. It is whether the Intake Gate changes behavior.
Success signals
- Real workspaces using the gate
- PMs reframing solution requests into problems
- Override rate staying controlled
- At least one request moving end-to-end to impact marked
- Design leaders returning because the workflow improves clarity
I was the founder, product strategist, designer, PM, and AI-assisted builder.
This meant making the product decisions, defining the philosophy, designing the workflow model, building the system, cutting the launch surface, and deciding what must never be built.
The work combined design leadership, SaaS strategy, AI-assisted development, service design, workflow architecture, and founder judgment.
The most important decision was not what to build. It was what to hide until the core thesis was validated.
AI-native is not AI sprinkled on old workflows.
Lane works because AI is part of the operating model. It checks framing, suggests routing, generates context, and supports decision flow. It does not simply sit on top of a ticket system.
The hardest founder decision was cutting.
Building the full system was easier than choosing not to launch it all. The private-beta surface was narrowed to validate the riskiest assumption first.
Philosophy must become constraints.
Anti-surveillance is not a brand line in Lane. It is enforced through what the product refuses to measure, expose, or rank.
Inside Lane
The AI Intake Gate and the decision-first operating model, in the private-beta interface.