Forem: Aleksandr Sakov

From Vibe Coding to Shipping: My Spec-Driven Workflow with Claude Code

Aleksandr Sakov — Thu, 30 Apr 2026 13:24:40 +0000

On February 2, 2025, Andrej Karpathy coined the term "vibe coding": "fully give in to the vibes, embrace exponentials, and forget that the code even exists." A year later, on February 4, 2026, he retracted it. The new word was "agentic engineering" — because, as he put it, the new default is that you are not writing the code directly 99% of the time. You are orchestrating agents.

Twelve months. From a meme to a discipline. Most teams I talk to have not noticed the difference.

In between those two tweets, a 2025 METR study ran a controlled experiment on senior open-source developers using Cursor and Claude on mature codebases — the kind of code base where you know all the corners. The developers forecasted AI would make them 24% faster. After completing the tasks, they estimated they had been 20% faster. Measurement showed they were actually 19% slower. Senior people, on code they had been writing for years.

In an earlier post I said AI made me 30-40% faster on my own client work. Both numbers can be true at the same time. The difference is not the tool. It is the workflow around the tool.

This post is that workflow.

It is not theoretical. It is what I run every day on production code at sundr. Claude Code is the engine; a small set of open-source tools are the guardrails. Together they turn AI from an enthusiastic intern who ships 70% of a feature into a senior pair who ships the other 30%.

If you have ever watched Claude generate a clean-looking pull request, hit merge with a smile, and then watched the same code break three days later under real traffic — this post is for you.

AI is an amplifier

The single most useful sentence I read about AI in 2025 came from Google's 2025 DORA report, which surveyed nearly five thousand developers in September: "AI doesn't fix a team; it amplifies what's already there."

Same report: 90% of developers are now using AI at work, and over 80% report productivity gains. About 30% report little or no trust in the code AI produces. That last number is what spec-driven workflow exists to address.

Three months later, Stack Overflow's 2025 developer survey dropped a sharper data point. Developer trust in AI accuracy fell from 40% in 2024 to 29% in 2025. Forty-six percent now actively distrust it. Sixty-six percent report being frustrated by output that is "almost right but not quite". That is exactly the failure mode that destroys you in code review six months later, when the bug is yours to debug and the original prompt is long gone.

Adoption is up. Trust is down. The gap between those two lines is the discipline gap. AI is going to amplify whatever workflow you already have. If your workflow is "type until it compiles," that is what you are amplifying.

The rest of this post is the workflow I amplify instead.

The 70% problem and the math of compounding

Addy Osmani named the trap clearly in December 2024: "AI can rapidly produce 70% of a solution, but that final 30% — edge cases, security, production integration — remains as challenging as ever."

I see this in every client review. The demo works. The pull request looks clean. The tests pass — because Claude wrote the tests too, which is its own problem. And then the bug surfaces three days into production traffic. A null check that was never wired up. A timezone offset that nobody noticed. An auth header that worked in development because the dev environment was permissive. Plausible-looking code that does not actually do the thing.

Why does this happen? It is not Claude being dumb. It is compounding probability.

Imagine each AI decision in a non-trivial task as a step that succeeds 99% of the time. Picking the right library. Understanding the data shape. Handling the empty case. Naming the variable. Calling the API correctly. Catching the right error. A real feature has dozens of these decisions in sequence.

One hundred decisions at 99% success: 0.99 to the power of 100. That is about 37%. A 37% chance the whole chain holds together end to end.

This is not pessimism. It is multiplication. You can see it in your own pull requests. Most of the line-by-line code is fine. The aggregate is broken because it has to be — even at 99% per decision, a hundred-step chain fails the majority of the time.

You cannot out-prompt compounding probability. You can only insert review. A workflow that catches errors at three or four checkpoints during the work — instead of one big review at the end — bends the math back in your favor. That is not bureaucracy. That is arithmetic.

CLAUDE.md — where Claude's memory lives

Every project I run with Claude Code has a file at the root called CLAUDE.md. It is the first thing Claude reads on every session. It is the closest thing the AI has to memory. It is also the smallest, cheapest investment that gives you the biggest return.

Per Anthropic's documented memory hierarchy, CLAUDE.md files cascade — there is one at ~/.claude/CLAUDE.md for your global preferences, one at the project root that everyone working on the repo sees, and optional per-directory files for module-specific rules. I commit the project root one. I do not commit my personal one.

I aim for twenty to fifty lines, structured into five short sections:

# {Project Name}

## What this is
{2-3 sentences: what the product does, what stack it runs on}

## Key directories
- src/domain/  — pure business logic, no framework imports
- src/infrastructure/  — Express, DB, external services
- tests/  — unit + integration + characterization

## Code standards
- TypeScript strict mode; type hints required
- Test framework: vitest
- Imports: external, then internal, then relative

## Common commands
- pnpm test  — run all tests
- pnpm dev   — start dev server
- pnpm build — production build

## Anti-patterns
- Do NOT use console.log — use logger from app/utils
- Do NOT mutate objects — spread {...obj, key: value}
- Never use a double-hyphen in user-facing text; use em dash with spaces
- Do NOT import infrastructure/ from domain/

The single most important section is the last one. Anti-patterns with concrete // DO NOT examples are read as constraints. Abstract rules are read as suggestions. Claude responds to the difference. So do humans, but they have the option to forget — Claude does not. That is the leverage.

Keep the file short. Long files dilute attention. If a rule does not earn its line, cut it. I have started deleting items from CLAUDE.md when I notice myself violating them — not because the rule was wrong, but because if it could not survive my own habits, Claude was never going to internalize it either.

Boris Cherny — who created Claude Code — publicly says his own setup is "surprisingly vanilla" and that he does not customize Claude Code much (see his Threads on how he uses Claude Code). That tracks with what I see in practice. Most projects need twenty to fifty lines, not two hundred. The file does its job by being noticed, not by being elaborate.

The compound effect is bigger than it looks. Claude starts every session with this file in its head. That is what lets it follow conventions on the first try, write commands the way you actually run them, and refuse anti-patterns without being asked. Without CLAUDE.md, the AI is a brilliant amnesiac who reintroduces himself every morning. With it, you have continuity. And continuity is what turns "works in this prompt" into "works in this codebase."

The four phases: Specify, Plan, Tasks, Implement

Anthropic's recommended workflow for Claude Code is four phases: Explore, Plan, Implement, Commit. That is the foundation. On top of it I run a four-phase artifact discipline that turns ambiguous intent into shippable code: Specify, Plan, Tasks, Implement — with the Commit step folded into the TDD-driven commits inside each task. Same shape as EPCC, but with explicit gates between phases that mean a human reads the artifact before AI starts on the next one.

The workflow pairs two open-source tools, both of which I would point a new client at on day one.

GitHub's Spec Kit is the artifact half. It defines the file structure: a constitution.md that captures operating principles, a spec.md that captures intent and acceptance criteria, a plan.md that captures the technical approach, a tasks.md that breaks the work into bounded units. Each artifact has its own slash command — /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement — that asks Claude the right questions in the right order. Open source, framework-agnostic, works with Claude Code, Copilot, Cursor, and Gemini.

Anthropic's official superpowers plugin is the discipline half. It bundles a set of skills that enforce the rituals around the artifacts: brainstorming insists on a design conversation before any code, writing-plans decomposes work into 2-to-5-minute tasks before implementation, test-driven-development enforces RED → GREEN → REFACTOR, verification-before-completion demands evidence — actual command output — before I am allowed to claim something is fixed.

Spec Kit is the what. Superpowers is the how. Either one alone leaks. Plenty of teams use Spec Kit and still vibe-code their way through implementation because nothing is enforcing the test-first habit. Plenty of others run superpowers and skip the spec because nobody made writing one a precondition. Together, they close the gaps where AI usually wanders off.

Here is what each phase actually does in practice.

Specify answers what we are building and why. Five components, in order: functional requirements, acceptance criteria, input/output examples, constraints, and — the one most teams skip — out of scope. AI expands scope by default. The line you do not draw is the line AI will cross. I write the explicit "do not implement X, Y, Z in this feature" list before I write anything else, even if Z feels obvious.

Acceptance criteria use EARS notation — short, machine-parsable lines like WHEN the user submits a checkout form without a payment method, the system SHALL reject the order AND display a recoverable error. EARS was published in a 2009 IEEE paper and has nothing to do with AI; it just happens to be unambiguous, and unambiguous is what AI needs.

Plan answers what technical shape it should take. The output is a plan.md with the architectural sketch, the data model, the integration points, the risks, and an explicit "if this fails, here is the rollback." This is the highest-leverage gate in the workflow — the last cheap moment to change direction before tasks get cut.

Tasks breaks the plan into 30-to-60-minute units of AI work, each independently testable. Markers like [P] indicate parallelizable tasks. The list is ordered. Nothing is "TBD" — if I do not know how to bound a task, the spec is wrong, not the task list.

Implement is the only phase where AI is in the driver's seat — and only inside one task at a time, with the test running before and after every change. Specify, Plan, and Tasks all stay in human hands. The artifact is mine; the implementation is Claude's. That flip is what makes the workflow work. Every gate between phases is a place where I can stop, edit, restart, or reverse course without losing more than the last task's worth of work.

Two more pieces of this discipline are worth their own section: the Claude Code modes that compound the most, and the specific class of bug that only a fresh-context reviewer can see.

Two free tactics that compound

Most of what I have described costs effort. The two tactics in this section are nearly free, and they are the ones I use the most.

The first is Plan Mode. Claude Code has a read-only mode where the AI can see every file and run every search, but cannot edit anything, run shell commands, or write to disk. Toggle it on, paste your task, and Claude reads, plans, and writes a markdown plan back at you — without touching the codebase. Then you toggle it off and let Claude execute the plan.

I run Plan Mode before every non-trivial change. It costs me sixty seconds and saves me — conservatively — twenty minutes of cleanup per week. The plan that comes back is also a great input to Spec Kit's /speckit.plan, since it surfaces files and risks I had not thought through.

The second tactic is Writer-Reviewer with /clear. The setup: ask Claude to do a thing. When it claims to be done, type /clear to wipe the context, then in the same session ask Claude to review the diff. The reviewer is technically the same model, but with no memory of the writer's reasoning or assumptions.

This catches a specific class of bugs that pure in-session review misses — cases where the writer's mental model was wrong from step one and every subsequent decision compounded the error. The writer cannot see those bugs because the writer's mental model is the bug. A fresh-context reviewer comes at the diff cold and asks "wait, why is this casting userId to a number when the schema says it is a UUID?"

In my experience, the post-/clear review catches a meaningful share of issues that in-session review misses — roughly the lift you would expect from a second pair of eyes, except the second pair never gets tired and never has Friday-afternoon brain. It is not magic. It is just a different head reading the code. If you only adopt one tactic from this post, adopt this one.

Both Plan Mode and the /clear trick are also free of any plugin or extra tool. They ship with Claude Code as it stands.

Tasks sized for thirty minutes of AI work, not three hours

The single biggest lever inside the Implement phase is task size. Too small, and the overhead of starting and committing each one drowns the value. Too large, and Claude drifts: the context fills up, the test runs become unreliable, and you find yourself reviewing a sprawling diff at the end.

The size that works for me is thirty to sixty minutes of AI work per task. Each task ships its own commit and is independently verifiable. A real tasks.md looks like this:

- [ ] T1: Add /api/health endpoint  [P]
- [ ] T2: Wire health check to monitoring  [P]
- [ ] T3: Write characterization test for legacy /api/order  [blocks T4]
- [ ] T4: Refactor /api/order — extract validation helper
- [ ] T5: Add e2e test for /api/order happy path

The [P] markers say which tasks can run in parallel. [blocks Tx] markers express dependencies. T3 has to ship before T4 because you do not refactor what you cannot characterize.

Inside each task I run a tight loop: write the failing test, watch it fail, write the minimal code to pass, watch it pass, commit. This is just TDD; the superpowers test-driven-development skill enforces the cycle when I am moving fast and tempted to skip steps. The loop matters because every committed step is a known-good rollback point. If a task goes off the rails, I lose minutes, not hours.

One operational rule: I watch context utilization. Once Claude's context is over about 70%, output quality falls off — the reasoning gets sloppy, the code starts repeating earlier patterns wrong. When I see that bar climb, I either run /compact, start a new session, or stop. Pushing past it is wasted tokens and wasted time.

What this looks like on a real project

Make this concrete: last month I shipped a tournament-staking system for MTT Tracker, the poker analytics product I run on the side. Players sell shares of their tournament action to backers; the tracker now models the full economy — markups, settlements, swaps, staking-adjusted P&L.

One proposal.md defined motivation and scope. The Out of Scope section explicitly excluded a backer-facing portal, payment integration, a staking marketplace, and tax-reporting features — none of those were "obvious" exclusions, and every one of them is something AI would happily have expanded into. Drawing those lines up front saved hours of "let me add this while we are here" detours.

The tasks.md grew to 195 ordered, bounded items, staged across three phases: feature flag and gating, schema and calculations, then UI and analytics. Each task carried a TDD micro-loop — write the failing test, watch it fail, write the minimal code, watch it pass, commit. Six locale files updated in lockstep with every UI change because the rule was in CLAUDE.md.

The interesting part is not how fast it shipped. It is that nothing leaked outside the spec. (For more on the product itself, I wrote a longer MTT Tracker case study here.)

What I would skip — and what changed in 2026

Three things this post does not recommend, even though they show up in plenty of agentic-engineering write-ups.

Heavyweight multi-agent teams for sub-day features. Spinning up a "team" of specialized agents — backend, frontend, devil's advocate, reviewer — is genuinely useful for cross-cutting work that takes a couple of days. For a one-hour change, single-agent EPCC plus the Writer-Reviewer trick from Section 6 is faster and produces less noise.

Magic-word thinking budgets. Throughout 2025, prompts laced with ultrathink or think harder were a real lever — they bumped Claude's reasoning depth. As of January 16, 2026, Anthropic deprecated those keywords. Current models manage thinking budgets adaptively. If you see them in someone's CLAUDE.md, that file has not been updated this year.

The "AI coding makes you faster" headline as a single number. Even METR — the team that ran the original 2025 −19% study — updated their estimate in early 2026 to roughly −18% with wide confidence intervals and an explicit caveat that the data is "very weak evidence." The honest framing is not that AI is universally slower. It is that AI without discipline is a coin flip on mature codebases. With discipline, it is a multiplier. The headline number depends entirely on the workflow around the tool.

That coin-flip-versus-multiplier framing is what ThoughtWorks calls cognitive debt in their April 2026 Tech Radar. Spec-driven development is on their short list of habits that stop cognitive debt from piling up. They are right.

That is also the answer to the puzzle I opened with. The same Claude can make a senior engineer 30-40% faster on one team and 19% slower on another. The model is identical. The workflow around it picks the outcome.

If you want this discipline applied to your codebase

Reading about a workflow is one thing. Running it on your actual repository — with your actual stack, your actual deadlines, and your actual technical debt — is another. If you are building a real product and would like the workflow described here applied directly to your codebase, not in theory, that is what I do at sundr.

The two easiest first steps: try the project calculator for a quick sense of timeline and budget, or book a free thirty-minute call and tell me what you are working on. I will give you a straight answer about whether this approach fits — and if it does not, I will tell you that too. (If you are still deciding between hiring solo and an agency, my honest take on that question is in another post.)

No hard sell. Just an experienced engineer giving you a real opinion.

React Native Cross-Platform Development: One Codebase for Mobile, TV, and Beyond

Aleksandr Sakov — Fri, 17 Apr 2026 17:18:53 +0000

Every article about React Native says the same thing: it lets you build iOS and Android apps from one codebase. That's true, but it's only half the story. I've spent 9+ years building cross-platform applications — not just for phones, but for Smart TVs, set-top boxes, and streaming platforms serving 80M+ viewers. React Native cross-platform development in 2026 means targeting 7+ platforms from a single monorepo. Here's what that actually looks like in production.

React Native in 2026: More Than a Mobile Framework

When people say "cross-platform," they usually mean iOS and Android. That definition is 5 years out of date. React Native now runs on iOS, Android, tvOS, Android TV, Fire TV, Web, Windows, macOS, and as of February 2026 — Meta Quest VR.

The New Architecture is no longer optional. RN 0.82 made it mandatory — the old bridge code is physically removed from compiled binaries in 0.84. Hermes V1 is the default engine, delivering ~55% faster startup times and 26% lower memory usage compared to JavaScriptCore. Libraries that still depend on bridge APIs simply will not compile.

Enterprise adoption tells the real story. Shopify reported 86% code unification with 59% faster screen loads after migrating to the New Architecture. Microsoft runs 40+ Office experiences on React Native for Windows, including parts of Copilot. Discord, Coinbase, and the Call of Duty companion app all ship on React Native.

But the most significant development for cross-platform is Amazon Vega OS. Launched in October 2025, it integrates React Native at the operating system level — the Hermes runtime is pre-loaded and pre-warmed by the OS, giving apps near-instant cold starts. Currently Vega ships with RN 0.72, which means maintaining a separate build configuration. But RN 0.82 support is coming in May 2026, and when it lands, we'll target Vega OS from the same monorepo as our mobile and other TV builds. That's a turning point for teams building cross-platform products.

The Business Case: Why One Codebase Changes the Economics

Let me put this in terms that matter to the person signing the check.

Building a content app for 7 platforms the traditional way — native iOS, native Android, native tvOS, native Android TV/Fire TV, and a web-based Tizen (Samsung)/webOS (LG) app — means 5 codebases, potentially 5 different teams, and 5 separate bug-tracking cycles. A conservative estimate for a mid-complexity streaming app: $400K-600K and 6-9 months.

With React Native and a monorepo architecture, I build one codebase that targets all five. Business logic, state management, API layer, and data models are written once. Platform-specific work — focus management for TV, touch interactions for mobile — accounts for 20-40% of the total effort. In practice:

One senior developer instead of 5 platform specialists
3-4 months instead of 6-9
One test suite, one CI pipeline, one deployment process
Bug fixes ship to all platforms simultaneously

I ship mobile and TV apps as a solo developer. That's not theoretical — it's how I work daily. AI-powered workflows handle the boilerplate, while I focus on architecture and platform-specific edge cases that require real expertise. The result: startup-speed delivery at a fraction of agency cost.

What Code Gets Shared Between Mobile and TV (And What Doesn't)

The "60-80% code sharing" claim gets thrown around a lot. Let me be specific.

The shared 60-80% is almost entirely business logic and data. Zustand stores, API clients, data models, authentication flows, feature flags, validation — all platform-agnostic. A simplified example of a store that runs identically on phones and TVs:

interface ContentStore {
  readonly items: readonly ContentItem[]
  readonly isLoading: boolean
  readonly error: string | null
  fetchItems: (categoryId: string) => Promise<void>
}

export const useContentStore = create<ContentStore>()(
  persist(
    (set) => ({
      items: [],
      isLoading: false,
      error: null,
      fetchItems: async (categoryId) => {
        set({ isLoading: true, error: null })
        const items = await api.getContent(categoryId)
        set({ items, isLoading: false })
      },
    }),
    { name: 'content-store', storage: createJSONStorage(() => AsyncStorage) }
  )
)

This store works everywhere without a single line of platform-specific code. Same for hooks, utilities, and the entire networking layer.

The platform-specific 20-40% is disproportionately expensive because it covers the parts that determine whether users feel the app is native or a bad port:

Focus management and spatial navigation. On mobile, users tap what they want. On TV, they navigate with a D-pad. Every focusable element needs explicit spatial relationships. More on this below — it's an architectural concern, not a widget toggle.
Input handling. Samsung Tizen's back button sends keycode 10009. LG webOS sends 461. tvOS uses a gesture-based Siri Remote. Each needs explicit handling.
Layout and sizing. A phone screen is 375px wide at arm's length. A TV is 1920px wide at 3 meters. Font sizes, spacing, focus targets — everything changes.
Animation strategies. A phone with 8 GB RAM handles 10 parallel animations. A TV with 512 MB gets one, and you hope the GC doesn't stutter.

The ratio depends on your product. A content browsing app (movie catalogs, channel guides) pushes toward 80% shared. An interactive app with live features drops to 55-60%. Even at 55%, that's one codebase instead of five.

React Native vs Flutter: The TV Factor Nobody Mentions

Every "React Native vs Flutter" comparison frames them as mobile frameworks. Flutter leads in market share — 46% to React Native's 35%. Flutter's Impeller rendering engine delivers excellent animation performance. For a mobile-only product, it's a legitimate choice.

But if your product needs to run on a TV, the comparison ends before it starts.

React Native has a production-grade TV ecosystem. Amazon built an entire operating system on it. DIRECTV ships their app on it. The react-native-tvos fork tracks core releases. Expo has official TV build support. Callstack publishes enterprise guides for TV development.

Flutter's TV support is experimental. No official TV framework exists, no major streaming platform ships Flutter on TV, and community effort is fragmented.

Kotlin Multiplatform is the more interesting comparison — it's tripled its adoption to 23% and Airbnb chose it for shared business logic. But KMP shares logic, not UI. For a team that wants to share the entire component layer across mobile and TV, React Native is the only framework that delivers this in production.

If you're evaluating frameworks for a multi-surface product, read my post on what Smart TV development actually involves before deciding.

The Architecture: How One Project Targets 7+ Platforms

Here's the monorepo structure I use for cross-platform projects:

├── apps/
│   ├── expo/          # iOS, Android, tvOS, Android TV, Fire TV
│   └── web/           # Samsung Tizen, LG webOS
├── packages/
│   ├── platform/      # Device detection, keycodes, capabilities
│   ├── uikit/         # Focus-aware UI components
│   ├── shared/        # Hooks, state, API client, navigation
│   └── theme/         # Design tokens via React Context
└── turbo.json

The dependency direction is deliberate. uikit depends on platform and theme. shared depends on platform. Apps depend on all four. Nothing flows backwards. When I change a keycode map, only platform and its dependents rebuild — Turborepo's caching handles the rest.

The platform package is the anti-corruption layer. It abstracts the hardware zoo behind a capability-based API:

// Samsung Tizen keycodes
export const tizenKeyCodes: KeyCodes = {
  ENTER: [13],
  BACK: [10009],   // Samsung's unique back button
  RED: [403],      // Color buttons on Samsung remote
  GREEN: [404],
}

// LG webOS keycodes — completely different
export const webosKeyCodes: KeyCodes = {
  ENTER: [13],
  BACK: [461],     // LG's back code
  RED: [403],
  GREEN: [404],
}

We program against capabilities, not platform names. The package exposes PlatformCapabilities — hasColorButtons, maxResolution, hasVoiceControl — so the UI adapts to what the remote can actually do. Detection uses platform-native APIs first (tizen.systeminfo, webOS.platform, Platform.isTV) with user agent parsing as a fallback.

The dual-build strategy. Expo with the react-native-tvos fork handles native platforms (tvOS, Android TV). Vite with react-native-web handles web-based TVs (Tizen, webOS). Platform-specific file extensions — .tizen.tsx, .webos.tsx, .web.tsx — are resolved at build time. The same component can have a shared version and platform-specific overrides, and the bundler picks the right one automatically.

Real Gotchas: What I Learned Shipping to Phones and TVs

Focus management is architecture, not a widget. This is the single biggest misconception about TV development. On mobile, navigation is solved — stack, tabs, drawer. On TV, spatial navigation is a cross-cutting concern that affects your entire application.

When a user presses DOWN on a hero carousel, the focus system must calculate which item in the content rail below should receive focus. This depends on the rail's horizontal scroll position, the width of the focused hero item, and whether the rail has finished layout. Get this wrong and focus jumps to an unexpected item across the screen.

Focus requires a history stack — not just current state, but the ability to restore focus on back navigation. It shapes your testing strategy: you can't test a TV app with click events, you need D-pad sequence simulation. And it's the primary performance bottleneck — traversing a grid of 200 items to find the nearest focusable neighbor must complete in under 16ms or the UI feels broken.

Every component in our UIKit declares whether it's focusable, defines its spatial boundaries, and knows how to animate focus transitions. This is what separates a "React Native app on TV" from a "TV app built with React Native."

Memory is your invisible ceiling. A phone has 6-8 GB of RAM. A Smart TV has 512 MB to 1.5 GB, and your app gets a fraction. The same React Native code that runs smoothly on an iPhone will crash a Samsung TV in 10 minutes if you're not virtualizing lists and actively managing image memory. I covered this in detail in my post on Smart TV challenges.

The react-native-tvos fork is a managed risk. Using "react-native": "npm:react-native-tvos@..." as an npm alias creates upgrade friction — every Expo SDK bump needs a compatible fork release. We mitigate by pinning versions and running a dedicated upgrade validation pipeline. The ecosystem is more stable than 2 years ago (Expo SDK 54+ with RNTV 0.81 works well), but it's a cost to budget for.

TV animations need different thinking. Focus-driven animations must coordinate with focus state that lives in JavaScript. This means consciously choosing JS-driven animations for focus transitions — a trade-off between architectural simplicity and raw frame rate. React Native Reanimated 3.x largely solves this with native-level performance while reading JS-side state, but you need to design for it from day one.

How AI Makes This Possible for One Developer

Shipping to 7+ platforms as a solo developer would have been absurd a few years ago. AI-powered development changed that equation.

Claude, Cursor, and Copilot handle boilerplate that used to eat half my day. Scaffolding a new Zustand store, writing test suites, generating platform-specific configuration — tasks that took 30-40 minutes now take 5 minutes of review.

But AI doesn't replace the expertise. It can't decide that focus management needs a history stack. It doesn't know Samsung Tizen's back button is keycode 10009. It won't tell you to virtualize everything because the TV's WebView gets 200 MB of RAM. That's 9+ years of domain knowledge that makes AI output useful rather than plausible-looking but subtly wrong.

The combination — deep platform expertise plus AI acceleration — is what lets one senior developer outperform agency teams. The expertise sets the architecture. The AI fills in the implementation.

Need a React Native App for Phones and TVs?

If you're building a product that needs to run on both mobile and TV — a streaming service, a content platform, a live events app — this is exactly what I do. I've built OTT platforms serving 80M+ viewers across 15+ device types and ship React Native mobile apps with the same monorepo architecture. Whether you need a cross-platform app from scratch or want to extend an existing mobile app to Smart TV, I can give you an honest assessment.

Originally published at sundr.dev.

Deploy Apps to Samsung Smart TV: The Bash Script That Saves Hours

Aleksandr Sakov — Tue, 31 Mar 2026 16:28:17 +0000

If you've ever deployed a web app to a Samsung Smart TV, you know the pain. Connect via sdb, resolve the device name, package the .wgt file with the right certificate, uninstall the old version, install the new one, run it, pray it doesn't crash. Every. Single. Time.

After 9+ years of doing this across dozens of OTT projects — including platforms serving 80M+ viewers — I finally snapped and wrote a script that automates the entire thing.

I'm sharing it here because I wish someone had shared something like this with me years ago.

What You Need Before Starting

Before the script can do its magic, you need three things set up on your machine and your TV.

1. Install Tizen Studio. Download it from the official Tizen Studio page. You need the CLI tools — specifically sdb and the tizen command-line utility. The script expects them at ~/tizen-studio/tools/. After the base installation, open Package Manager, go to the Extension SDK tab, and install TV Extensions and Samsung Certificate Extension. The full process is described in the Samsung TV SDK installation guide.

2. Create a Samsung certificate. This is the part that trips most people up. You need a signing certificate to package and install apps on a physical TV. Follow the Samsung certificate guide: open Certificate Manager in Tizen Studio, create a Samsung certificate profile (not a Tizen one), authenticate with your Samsung Developer account, and register your TV's DUID as the target device. Keep the certificate backed up — future updates must use the same author certificate or the TV treats them as a completely new app.

3. Enable Developer Mode on the TV. On the TV itself, go to the Apps panel, open App Settings, and enter the code 12345. This opens the Developer Mode popup. Toggle it on, enter your computer's IP address, and reboot the TV. After restart you'll see "Develop Mode" at the top of the Apps panel. The full walkthrough is in the Samsung device setup guide.

Also required: Java 8. Tizen CLI tools still depend on Java 8, not newer versions. On macOS, install it with brew install --cask temurin8. The script automatically detects and switches to Java 8 for the session, so it won't mess with your system Java.

What the Script Does

The script gives you an interactive menu powered by gum (a terminal UI toolkit that it auto-installs if missing). You get 8 options:

Run All Steps — connect, resolve device, package, uninstall old version, install, and run. One selection, done.
Connect to TV — establishes sdb connection to your TV's IP.
Resolve device name — reads the device identifier from sdb, needed for all Tizen CLI commands.
Package app — signs your build directory as a .wgt file with your certificate. Handles filename sanitization automatically.
Uninstall app — removes the existing version from the TV (gracefully ignores if not installed).
Install app — pushes the .wgt to the TV.
Debug app — launches a debug session and forwards the debug port so you can attach Chrome DevTools.
Run app — launches the app in non-debug mode.

You can also pass a pre-built .wgt file directly, and the script skips the packaging step entirely.

Config Persistence: Set Once, Deploy Forever

On first run, the script asks you four things: TV IP address, certificate name, package ID, and the path to your build directory (or .wgt file). The package ID comes from your project's config.xml — it's the combination of the tizen:application package attribute, in the format AbCdEf1234.MyApp. The script saves all of this to ~/.tizen_deploy_config, so every subsequent run just works — no re-entering values.

Working on a different project or switched TVs? Run the script with --clear-config to reset everything:

./tizen_deploy.sh --clear-config

This wipes the saved config and prompts you fresh.

The Full Script

Here's the complete source. Save it as tizen_deploy.sh, make it executable with chmod +x tizen_deploy.sh, and run it.

#!/bin/bash

# PLATFORM DETECTION
OS_TYPE="$(uname -s)"
IS_MAC=false
IS_LINUX=false
IS_WIN=false

case "$OS_TYPE" in
  Darwin*) IS_MAC=true ;;
  Linux*) IS_LINUX=true ;;
  MINGW*|MSYS*|CYGWIN*) IS_WIN=true ;;
esac

# CONFIG PATH
CONFIG_PATH="$HOME/.tizen_deploy_config"
$IS_WIN && CONFIG_PATH="$HOME/_tizen_deploy_config"

# --clear-config ARG HANDLING
if [[ "$1" == "--clear-config" ]]; then
  echo "Clearing config at $CONFIG_PATH"
  rm -f "$CONFIG_PATH"
fi

# INSTALL GUM IF NOT FOUND
install_gum() {
  if command -v gum &>/dev/null; then return; fi
  echo "'gum' is not installed. Installing..."

  if $IS_MAC; then
    if ! command -v brew &>/dev/null; then
      echo "Homebrew is required on macOS." >&2
      exit 1
    fi
    brew install charmbracelet/tap/gum
  elif $IS_LINUX; then
    if command -v apt &>/dev/null; then
      sudo apt update && sudo apt install -y gum
    elif command -v dnf &>/dev/null; then
      sudo dnf install -y gum
    elif command -v pacman &>/dev/null; then
      sudo pacman -Sy gum
    else
      echo "Unsupported package manager." >&2
      exit 1
    fi
  elif $IS_WIN; then
    echo "On Windows, install gum manually:"
    echo "  scoop install gum"
    read -p "Press Enter when installed..."
  fi
}

if ! command -v tizen &>/dev/null; then
  echo "Tizen CLI not found. Install Tizen Studio first."
  exit 1
fi

install_gum

# FORCE JAVA 8 FOR TIZEN
if command -v /usr/libexec/java_home &>/dev/null; then
  JAVA_8_HOME=$(/usr/libexec/java_home -v 1.8 2>/dev/null)
  if [[ -z "$JAVA_8_HOME" ]]; then
    echo "Java 8 is required. Install: brew install --cask temurin8"
    exit 1
  fi
  export JAVA_HOME="$JAVA_8_HOME"
  export PATH="$JAVA_HOME/bin:$PATH"
fi

# LOAD / PROMPT CONFIGURATION
prompt_or_load() {
  local var_name=$1
  local prompt_msg=$2
  local current_value=$(grep "^$var_name=" "$CONFIG_PATH" 2>/dev/null | cut -d'=' -f2-)
  if [ -n "$current_value" ]; then
    eval "$var_name=\"$current_value\""
  else
    read -p "$prompt_msg: " user_input
    echo "$var_name=\"$user_input\"" >> "$CONFIG_PATH"
    eval "$var_name=\"$user_input\""
  fi
}

prompt_or_load TV_IP "Enter TV IP address"
prompt_or_load CERTIFICATE_NAME "Enter Certificate/Profile name"
prompt_or_load PACKAGE_ID "Enter PACKAGE_ID (e.g., abc123.MyApp)"
prompt_or_load INPUT_PATH "Enter build dir or .wgt file path"

# Derive behavior based on INPUT_PATH
if [[ "$INPUT_PATH" == *.wgt ]]; then
  BUILD_DIR="$(dirname "$INPUT_PATH")"
  APP_NAME="$(basename "$INPUT_PATH")"
  SKIP_PACKAGE=true
else
  BUILD_DIR="$INPUT_PATH"
  APP_NAME="$(echo "$PACKAGE_ID" | cut -d. -f2).wgt"
  SKIP_PACKAGE=false
fi

SDB="$HOME/tizen-studio/tools/sdb"
TIZEN_CLI="$HOME/tizen-studio/tools/ide/bin/tizen"

TV_PORT="26101"
DEVICE_NAME=""
DEBUG_PORT=""

# STEP FUNCTIONS
connect() {
  echo "Connecting to $TV_IP:$TV_PORT..."
  CONNECT_OUTPUT=$($SDB connect "$TV_IP:$TV_PORT" 2>&1)
  echo "$CONNECT_OUTPUT" | grep -Eq "connected to|is already connected" \
    && echo "Connected." || { echo "Failed."; echo "$CONNECT_OUTPUT"; exit 1; }
}

resolve_device() {
  DEVICE_NAME=$($SDB devices | grep "$TV_IP:$TV_PORT" | awk '{print $3}')
  [[ -z "$DEVICE_NAME" ]] && { echo "Could not resolve device."; exit 1; }
  echo "Device: $DEVICE_NAME"
}

package_app() {
  $SKIP_PACKAGE && { echo "Skipping packaging (.wgt provided)"; return; }
  PACKAGE_OUTPUT=$($TIZEN_CLI package -s "$CERTIFICATE_NAME" -t wgt -- "$BUILD_DIR" 2>&1)
  if echo "$PACKAGE_OUTPUT" | grep -q "Package File Location"; then
    PKG_FILE=$(echo "$PACKAGE_OUTPUT" | grep "Package File Location" | sed -E 's/.*:\s*//' | xargs)
    NEW_BASENAME=$(basename "$PKG_FILE" | tr -d ' ')
    mv "$PKG_FILE" "$(dirname "$PKG_FILE")/$NEW_BASENAME" 2>/dev/null
    APP_NAME="$NEW_BASENAME"
    echo "Packaged: $APP_NAME"
  else
    echo "Packaging failed."; echo "$PACKAGE_OUTPUT"; exit 1
  fi
}

uninstall_app() {
  $TIZEN_CLI uninstall -t "$DEVICE_NAME" -p "$PACKAGE_ID" 2>&1 | \
    grep -q "uninstall completed" && echo "Uninstalled." || echo "Not installed, skipping."
}

install_app() {
  INSTALL_OUTPUT=$($TIZEN_CLI install --name "$APP_NAME" -t "$DEVICE_NAME" -- "$BUILD_DIR" 2>&1)
  echo "$INSTALL_OUTPUT" | grep -q "successfully installed" \
    && echo "Installed." || { echo "Install failed."; echo "$INSTALL_OUTPUT"; exit 1; }
}

debug_app() {
  DEBUG_OUTPUT=$($SDB shell 0 debug "$PACKAGE_ID" 2>&1)
  DEBUG_PORT=$(echo "$DEBUG_OUTPUT" | grep -oE "port: [0-9]+" | awk '{print $2}')
  [[ -z "$DEBUG_PORT" ]] && { echo "Debug failed."; echo "$DEBUG_OUTPUT"; exit 1; }
  $SDB forward "tcp:$DEBUG_PORT" "tcp:$DEBUG_PORT" 2>&1
  echo "Debug on port $DEBUG_PORT"
}

run_app() {
  RUN_OUTPUT=$($TIZEN_CLI run -t "$DEVICE_NAME" -p "$PACKAGE_ID" 2>&1)
  echo "$RUN_OUTPUT" | grep -q "successfully launched" \
    && echo "Launched." || { echo "Launch failed."; echo "$RUN_OUTPUT"; exit 1; }
}

run_all() { connect; resolve_device; package_app; uninstall_app; install_app; run_app; }

# INTERACTIVE MENU
choice=$(gum choose \
  "Run All Steps (1-5, 7)" \
  "1. Connect to TV" \
  "2. Resolve device name" \
  "3. Package app" \
  "4. Uninstall app" \
  "5. Install app" \
  "6. Debug app + forward port" \
  "7. Run app (non-debug)" \
  "8. Disconnect from TV")

case "$choice" in
  "Run All Steps (1-5, 7)") run_all ;;
  "1. Connect to TV") connect ;;
  "2. Resolve device name") resolve_device ;;
  "3. Package app") package_app ;;
  "4. Uninstall app") resolve_device && uninstall_app ;;
  "5. Install app") resolve_device && install_app ;;
  "6. Debug app + forward port") resolve_device && debug_app ;;
  "7. Run app (non-debug)") resolve_device && run_app ;;
  "8. Disconnect from TV") disconnect ;;
  *) echo "Invalid selection." && exit 1 ;;
esac

echo "Done."

How to Debug Your App with Chrome DevTools

One of the most useful features of the script is remote debugging. Here's how to connect Chrome DevTools to your app running on the TV.

Step 1: Close the app on the TV. If the app is already running, close it first. The debug session needs to launch the app itself — it won't attach to an already running instance.

Step 2: Run the debug command. Launch the script and select "Debug app + forward port" from the menu. The script will output a port number — copy it.

Step 3: Open Chrome DevTools for devices. In Chrome, go to chrome://inspect/#devices. Make sure "Discover network targets" is checked, then click Configure...

Step 4: Add the debug port. In the Target discovery settings dialog, add localhost:{port} where {port} is the number the script returned. Click Done.

Step 5: Inspect. Your TV app should appear under Remote Target. Click inspect on the first item in the list — a full Chrome DevTools window opens, connected to your app on the TV. You can inspect DOM, debug JavaScript, profile performance, and see network requests just like you would on a regular web page.

Important Notes and Limitations

A few things to keep in mind:

Tested on macOS. The script has platform detection for Linux and Windows (Git Bash), but I've only battle-tested it on macOS. Linux should work with minor adjustments. Windows via Git Bash/MSYS is experimental — your mileage may vary.
Java 8 is mandatory. Tizen CLI refuses to work with Java 11+. The script handles this by temporarily switching JAVA_HOME for the session only — your system Java stays untouched.
Certificate issues are the #1 problem. If install fails with a signing error, check three things: the certificate profile name must match exactly, the TV's DUID must be registered in the distributor certificate, and the certificate type matters — you need a Samsung certificate (not Tizen), and the privilege level must be correct (Partner for apps using privileged APIs, Public for basic apps).
gum is auto-installed. The interactive menu uses gum from Charm. If it's not installed, the script installs it via Homebrew (macOS), apt/dnf/pacman (Linux), or asks you to install it manually (Windows).

About Me

I'm Aleksandr Sakov — a full-stack developer with 9+ years of experience building OTT streaming platforms, mobile apps, and web products. The platforms I've built serve 80M+ viewers across 15+ device types including Samsung Tizen, LG WebOS, Android TV, Roku, and more.

If you're building a Smart TV app or any streaming product and want someone who's already solved the hard problems — book a free 30-minute call or try the project calculator for a quick estimate.

sundr.dev | LinkedIn