Can Sleek be vibe coded?
Prompt-to-design tool for multi-screen mobile app UI, with Figma and code export
One screen is already a yes, and you do not need this site for it: paste "design me a settings screen for an iOS app, Tailwind, 402x874" into the agent you already pay for and you get something decent. What Sleek sells is everything that makes twelve screens look like the same app, and most of that turns out to be prompt discipline rather than product. Decide the design system once, paste it verbatim into every later call, and hand the model the mobile conventions it does not apply unprompted: safe areas, 44px tap targets, native navigation instead of a website cropped to phone width. Two gaps survive that. There is no canvas, so every change is a re-prompt of a whole file rather than a click, and one call to one model is a rougher first draft than a tuned chain of them, which you pay for in your own iteration time. The Figma handoff is not one of the gaps: Sleek's own team ships the converter as MIT on npm, so the DIY build gets editable layers from one install.
Jump to the build brief ↓Checked Jul 2026
What you pay today, before any DIY hosting
medium editorial confidence
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- Generate one design system, generate each mobile screen as a standalone Tailwind HTML file against it, review them together in phone frames, and export PNGs plus editable Figma layers.
- Generate a constrained editing workflow with reusable templates and deterministic exports.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- clicking an element to change it instead of re-prompting the whole file
- a tuned multi-step pipeline · you get one prompt on one model, and you close the gap in your own iteration time
- sketch input · photograph a hand-drawn screen and get it back as a design
- share links, project history, and team seats
- The last 20 percent is sync, migration fidelity, speed, and edge cases.
Why people still pay
Nobody pays for one screen, and that is the honest read on this category: the single-screen version got free the day coding agents got good. What is left is thinner than it looks. There is no network here, no proprietary dataset, no integration treadmill, and the Figma converter that used to be the hard part is MIT on npm. What is left is real work all the same. The prompt below is one call to one model; the product is a chain of them, each step routed to whichever model is the right trade of quality against speed for that step, with the prompts behind each layer rewritten over months of iteration. None of that shows up on screen one. It shows up on screen nine, and in how many re-prompts it took to get there. The other thing money buys is a canvas, where a change is a click instead of a whole file re-prompted. Neither is a moat, and the prompt below is the honest test of what they are worth to you.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Sleek
Context
**Sleek** — Prompt-to-design tool for multi-screen mobile app UI, with Figma and code export. It currently costs $24.99/mo.
One screen is already a yes, and you do not need this site for it: paste "design me a settings screen for an iOS app, Tailwind, 402x874" into the agent you already pay for and you get something decent. What Sleek sells is everything that makes twelve screens look like the same app, and most of that turns out to be prompt discipline rather than product. Decide the design system once, paste it verbatim into every later call, and hand the model the mobile conventions it does not apply unprompted: safe areas, 44px tap targets, native navigation instead of a website cropped to phone width. Two gaps survive that. There is no canvas, so every change is a re-prompt of a whole file rather than a click, and one call to one model is a rougher first draft than a tuned chain of them, which you pay for in your own iteration time. The Figma handoff is not one of the gaps: Sleek's own team ships the converter as MIT on npm, so the DIY build gets editable layers from one install.
This brief describes a focused, single-operator replacement for the part of Sleek that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.
What you are building
Generate one design system, generate each mobile screen as a standalone Tailwind HTML file against it, review them together in phone frames, and export PNGs plus editable Figma layers.
Generate a constrained editing workflow with reusable templates and deterministic exports.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
Node 22+.
Playwright for screenshot export.
Data and integrations
LLM API key.
Each of these needs a real account, credential, or quota. Set them up before writing feature code.
Non-functional
Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
Security: server-side secrets, validated input, and no credentials in the client bundle.
Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
Portability: the operator can export their data and leave without losing it.
Implementation brief
Build me a mobile app screen designer to replace Sleek. Requirements:
A local Next.js app (App Router) calling the Anthropic API (claude-opus-5,
key in .env). Stream it with max_tokens 32000 · a screen plus its thinking
share that budget, and it rejects sampling params and assistant prefills
outright. Screens are files on disk, no database.
One route handler takes a plain-language description of the app, or a sketch
I drop on the page, and answers with a screen list first: 6 to 10 names, one
line of purpose each. I edit that list, then it builds every screen on it.
That same first call writes design-system.json (5 hex colors, 2 fonts with a
6-step type scale, radius, spacing unit, icon set) and _nav.html, and nothing
regenerates either afterwards · every later call gets both pasted in verbatim,
which is what stops screen 9 drifting away from screen 1.
Each screen is public/screens/<name>.html: one standalone file, Tailwind via
CDN, Lucide icons, a 402x874 viewport with 62px top and 34px bottom insets as
CSS variables, 44px minimum tap targets, and that same nav.
Edits re-send the current file plus my instruction and overwrite it in place,
so untouched parts stay put; every version lands in screens/.history/.
The page is a gallery: each screen in an iframe inside a phone frame, side by
side, a text box under each for the next edit. `npm run export` runs
Playwright at deviceScaleFactor 3 into exports/ plus a contact sheet.
A "copy all to Figma" button: @figit/dom-to-figma (MIT), one frame per screen
passing that iframe's contentDocument.body, convert({ frames }), then
clipboard.write with its toClipboardItem(). Cmd+V in Figma lands the whole
set as editable layers. Keep it in a client component and fire it from a real
click, or the write is blocked.
Out of scope, do not build: a click-to-edit canvas, share links, or hosting.
Runs on my machine, no accounts, no telemetry.
README: the API key, `npx playwright install chromium`, where files land, and
that remote images need an imageLoader proxying around CORS.
Delivery standard
Inspect the repository first, then write a short implementation plan before writing code.
Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
Add structured logs around every external call and return actionable errors without leaking sensitive details.
Write unit tests for the core logic and one automated test of the main user journey.
Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.
Acceptance criteria
A clean install starts the app using only the README and .env.example.
The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
Tests, type checking, linting, and a production build all pass with no ignored failures.
No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.
Non-goals
Do not build these, and do not claim to have replaced them:
Clicking an element to change it instead of re-prompting the whole file.
A tuned multi-step pipeline · you get one prompt on one model, and you close the gap in your own iteration time.
Sketch input · photograph a hand-drawn screen and get it back as a design.
Share links, project history, and team seats.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
What you still own after launch
Secure credentials, rotate secrets, and handle provider rate limits.
Run migrations, backups, restores, and dependency updates.
Test the critical journey after every model, API, or hosting change.
Monitor failures and fix the edge cases a first prompt will miss.
Risk
**Manageable.** A personal version is realistic if you test the critical journey and keep reliable backups.
Editorial confidence in this assessment: medium. No independent one-shot implementation is linked yet.
Prior art
Working open-source software you can read, fork, or borrow from before starting:
[dom-to-figma](https://github.com/figitdesign/web-to-figma) — MIT converter turning a DOM tree into editable Figma layers on paste; Sleek's own team ships it and the README says it runs in production there
[Penpot](https://github.com/penpot/penpot) — open-source design tool where a multi-screen mobile file stays editable, if you want layers rather than a folder of PNGs
[Onlook](https://github.com/onlook-dev/onlook) — Apache-2.0 visual editor for React codebases, the nearest thing to click-to-edit; web-focused, and the hosted product is now waitlisted
Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/sleek
You still own the product
- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
Open-source prior art
MIT converter turning a DOM tree into editable Figma layers on paste; Sleek's own team ships it and the README says it runs in production there
View project ↗Penpotopen-source design tool where a multi-screen mobile file stays editable, if you want layers rather than a folder of PNGs
View project ↗OnlookApache-2.0 visual editor for React codebases, the nearest thing to click-to-edit; web-focused, and the hosted product is now waitlisted
View project ↗Before you start
Can Sleek be vibe coded?
Partly, if you narrow it. One screen is already a yes, and you do not need this site for it: paste "design me a settings screen for an iOS app, Tailwind, 402x874" into the agent you already pay for and you get something decent. What Sleek sells is everything that makes twelve screens look like the same app, and most of that turns out to be prompt discipline rather than product. Decide the design system once, paste it verbatim into every later call, and hand the model the mobile conventions it does not apply unprompted: safe areas, 44px tap targets, native navigation instead of a website cropped to phone width. Two gaps survive that. There is no canvas, so every change is a re-prompt of a whole file rather than a click, and one call to one model is a rougher first draft than a tuned chain of them, which you pay for in your own iteration time. The Figma handoff is not one of the gaps: Sleek's own team ships the converter as MIT on npm, so the DIY build gets editable layers from one install.
What can an AI coding agent reproduce from Sleek?
Generate one design system, generate each mobile screen as a standalone Tailwind HTML file against it, review them together in phone frames, and export PNGs plus editable Figma layers. Generate a constrained editing workflow with reusable templates and deterministic exports. A responsive interface with real empty, loading, success, and error states.
What will a DIY Sleek replacement still be missing?
clicking an element to change it instead of re-prompting the whole file; a tuned multi-step pipeline · you get one prompt on one model, and you close the gap in your own iteration time; sketch input · photograph a hand-drawn screen and get it back as a design; share links, project history, and team seats; The last 20 percent is sync, migration fidelity, speed, and edge cases.
What do I still own after building a Sleek alternative?
Secure credentials, rotate secrets, and handle provider rate limits. Run migrations, backups, restores, and dependency updates. Test the critical journey after every model, API, or hosting change. Monitor failures and fix the edge cases a first prompt will miss.