Building Cuplikin: From Idea to Release on Mac, iPhone, and Android
An honest story of building Cuplikin, our AI video clipper: five weeks to the Mac App Store, a rejection from Apple, then iOS and Android from a single Flutter codebase.
Most articles on this blog are about how to work with a software house. This time we open our own kitchen. Cuplikin is an AI video clipper we built and released ourselves: an app that turns long videos into short, ready-to-post clips, with AI helping to find the interesting moments.
This isn't a product brochure. It's a process log: the problem we wanted to solve, the decisions made early, what took longer than expected, and what we'd do differently. If you're considering building an app, especially one with AI inside, this story gives a realistic picture of what happens behind the scenes. The stages are the same ones we describe in SDLC for business owners.
The problem we wanted to solve
If you've ever made short-form content from a long video, you know the feeling: rewatching an hour of footage, hunting for the part that "lands", cutting it, then typing captions word by word. The work is tedious and slow, yet the result largely decides whether the content gets watched or skipped.
Similar tools exist, but almost all of them are cloud-based: your video is uploaded to a third-party server, processed there, and you pay per minute of footage. For creators whose videos are large, sensitive, or who simply want to keep control of their own files, that model is uncomfortable.
That led to Cuplikin's premise: the video and the edits stay on the user's device, AI handles the most tedious part, finding moments and preparing captions, and the user still makes the decisions.
Discovery: cutting the scope of version one
Our initial feature list was long, as usual. There were ideas for brand context, a full timeline editor, direct publishing to social media. Everything sounded great on paper.
Version one was eventually locked to a single core flow:
- Pick a source video, from a local file or a YouTube link.
- Automatic transcription with per-word timestamps.
- AI suggests moments worth clipping, each with a score and a short reason.
- The user picks a moment, tidies the transcript and captions, chooses the aspect ratio (9:16, 1:1, 16:9, 4:3).
- Export the clip with captions burned into the video, no watermark.
Everything else went on the waiting list. The principle is the one we wrote about in MVP vs full product: the first version has to be enough to learn from real users, not enough to satisfy all of our own ideas.
Honest note: in the initial planning document, the mobile version was placed at the very bottom, "V4, low priority". In reality, iPhone, iPad, and Android followed less than two months after the Mac release. That's not because the plan was wrong, but because the architecture chosen at the start made expanding to mobile far cheaper than expected. Day-one architecture decisions determine the options you have in month three.
Decision 1: Flutter, one codebase for desktop and mobile
Before writing any code, we compared three options for the desktop app: Flutter, Tauri (Rust + web), and Electron. The question wasn't "which is the most advanced", but which best fits three needs: heavy video processing, flexible AI integration, and a planned expansion to mobile.
| Option | Strengths | Why not chosen |
|---|---|---|
| Electron | Mature desktop ecosystem | Heavy app, and mobile needs a separate stack |
| Tauri | Lightweight, Rust is strong for native processing | New stack for our team, mobile support still young |
| Flutter | One codebase for desktop + mobile, existing team experience, FFmpeg and Whisper plugins available | Chosen |
The "we already have experience" factor was counted deliberately. Learning a new stack is a real cost, and for a product that wants to reach users quickly, team experience often matters more than benchmarks. This is also our advice to clients: pick the stack your team can maintain, not the one with the most buzz.
Decision 2: local-first, cloud only where needed
This is the most important decision in Cuplikin. Transcription with Whisper, and cutting and rendering video with FFmpeg, run directly on the user's device. Projects, videos, and exports are stored locally and never expire.
There's still a backend, but its job is narrow: accounts and login, credits and subscriptions, AI moment analysis for users who choose the built-in mode, and resolving YouTube links. The video is not uploaded for moment analysis; only the minimum data needed is sent to the server.
The impact is large in three areas:
- Privacy. User media never passes through our servers. A clear differentiator against cloud-based tools.
- Cost. The heaviest compute, transcription and rendering, is handled by the user's device. Our cloud cost is reduced to a small, measurable part. We go deeper in the cost of running an AI product.
- AI flexibility. Users can use our built-in AI, or connect their own OpenAI-compatible provider, including local models through Ollama on Mac.
There is a price: the Mac version of Cuplikin supports Apple silicon only, because the Whisper plugin we use doesn't yet support a universal build for Intel. We chose to accept that limitation rather than delay the release.
Architecture: forced to be tidy from the start
Cuplikin is built as a workspace of more than twenty packages, separated by layer (domain, data, presentation) and by feature (project, transcription, hook search, editor, settings, billing). A script rejects forbidden cross-layer imports, and at the time of writing there are around 1,270 automated tests on the app side and around 200 on the backend.
That sounds excessive for a newborn product. But it's exactly what made the mobile version quick to build: the business logic and state management were reused as is, and the only new code was the presentation layer for small screens. Without that separation, "the mobile version" would have meant rewriting half the app.
The backend uses NestJS on Fastify, PostgreSQL, Redis for the job queue, and a separate worker for media tasks. Everything runs with Docker on a single server. Not a fancy architecture, and it doesn't need to be.
What took longer than expected
App Store review. Cuplikin's first commit was on 10 August 2026. The app went live on the Mac App Store on 16 September 2026, about five weeks later. In between was one rejection from Apple on 12 September: the reviewer flagged the behaviour of the login window on macOS and asked for a clear account-deletion flow, complete with a screen recording from a physical device. We fixed both, resubmitted with the recording, and were approved two days later.
The lesson: for any app with user accounts, build the account-deletion flow from the start. It's not an extra feature, it's a condition of entry.
macOS sandbox. The original plan downloaded YouTube videos with a tool inside a Docker container on the user's machine. App Store apps aren't allowed to run external processes like that. The feature moved to the backend as a resolver service, with temporary files deleted automatically after download. One seemingly small technical decision redrew the architecture map.
Subscription tiers. We briefly had three tiers: Free, Standard, and Pro. In early October we removed Standard entirely because it only added confusion without adding value. Now there's just Free and Pro (weekly, monthly, yearly) plus credit packs. Fewer choices turned out to be easier to explain and easier to maintain.
Release by release
| Date | Milestone |
|---|---|
| 10 August 2026 | First commit |
| 12 September 2026 | Rejected by App Review (login window, account deletion) |
| 16 September 2026 | Live on the Mac App Store, version 1.0 |
| 17 September 2026 | Version 1.0.2, post-release fixes |
| 7 October 2026 | Version 1.2.0: Sign in with Apple and Google, weekly Pro, analytics |
| 11 October 2026 | First iOS version (1.2.1) submitted to the App Store |
| 12 October 2026 | Google Play listing prepared for the first Android release |
This rhythm feels normal to us, and it's what we offer clients too: small, frequent releases rather than one big launch after months of silence.
What we'd do differently
- Prepare store requirements from day one. Account deletion, privacy policy, a demo account for reviewers. All of it eats time at the end if it's only considered at the end.
- Decide the cloud boundary earlier. The question "does this feature run on the device or on the server?" should be answered during design, not during packaging.
- Fewer pricing tiers from the start. Begin with Free and one paid plan. Add tiers only when user data asks for them.
What we wouldn't change: the choice of Flutter, the local-first approach, and the discipline of separating layers early. Those three are what let this product reach four platforms in two months with a small team. If you want to know how the AI part works, continue to how AI works in Cuplikin.
Next steps
The process we went through with Cuplikin, from discovery and scope cutting to architecture selection and store release, is the same process we use for client projects. If you have an app idea, with or without AI, tell us about it for a free initial consultation, or chat on WhatsApp. See also our services.
Frequently asked questions
What is Cuplikin?
Cuplikin is an app built by Rancangin Aja that turns long videos into short clips. AI finds the moments worth clipping, then the user picks, tidies the captions, and exports. Available on Mac, iPhone, iPad, and Android.
How long did Cuplikin take to build and release?
About five weeks from the first commit to going live on the Mac App Store, with iPhone, iPad, and Android versions following within the next two months from the same codebase.
Why was Cuplikin built with Flutter?
Because one codebase can reach both desktop and mobile, we already had Flutter experience, and heavy requirements like FFmpeg and Whisper transcription are available as plugins that run on the device.
Can the same approach be used for client projects?
Yes. The process we used for Cuplikin, from discovery and scope cutting to architecture and store release, is the same process we run for client projects.