BLOG · 14 October 2026

Vibe Coding for Production Teams: Building Your Own Tools with AI

What vibe coding does for small teams and where it needs care. At Sceneva Labs, we build apps that make our own work easier.

Close-up of a hand typing on a laptop with lines of code on the screen

Production companies sit on a lot of information waiting to be put to use: projects waiting to happen, behind-the-scenes footage from finished ones, emails from people asking for internships, dozens of archive files waiting on hard drives, personnel files for new hires, invoices, receipts and so on. To work with this data, you either buy ready-made software and bend your workflow to fit it, leave it to be forgotten in a corner, or work with a developer to build your own apps. For a small team, ready-made software and a developer are both expensive and slow.

Lately there has been another way: vibe coding. You describe what you want in plain language to an AI coding assistant, it writes the code, and you try it and keep going. At Sceneva Labs we build our own apps this way and use them every day. We have released two of them as open source on GitHub; you can find them on our website. We also built an equipment tracking app for a location sound company, which now uses it to keep track of equipment worth millions of liras. This post is about what worked along the way and what needs care.

What we built

qRaf is a free, open-source app we made for keeping track of external hard drives. It runs on macOS, Windows and Android. It shows you which drive the project or folder you are looking for is on, and measures read and write speed every time a drive is plugged in. A drop in speed can be the first sign that a drive's health is starting to fail.

Tastamam is open source too. It's an employee records app that runs in the browser. It keeps track of the documents and deadlines Turkish labor law asks for, and tells you what's missing. That keeps you from fines of thousands of liras in a social security (SGK) inspection. And the app keeps up with changes in the law.

We built the Equipment Tracking System for Zeplin Sound, a location sound company. It records who has each piece of kit, what faults it had, its repairs and what they cost; when a fault is logged, the repair shop gets an automatic e-mail.

There are developers on our team, of course, but these are apps you can build even if you aren't one. We'd only suggest being careful about security holes, or getting help from an expert. When you tell an AI to "close the security holes in my website or app", it can miss quite a lot.

What it does well

Vibe coding works best on a narrow problem you know very well. A tool written only for your team doesn't have to please a thousand different customers. It uses your words, follows your order of work, and doesn't bother you with features you'll never use.

It also speeds up the parts where non-developers used to get stuck: setting up a project, connecting a database, building forms and PDFs. An assistant like Claude Code can read the existing files and explain what they do, and it can tell you what it is going to do before it makes a change. You can ask as many questions as you like, and you learn your own system along the way.

Trying out a new idea gets cheaper as well. When someone on the team says "it would be nice to see the last repair date on this screen", it doesn't become a request that waits weeks at a software firm. The screen can be in use the next day.

Where it needs care

Code that runs on your computer isn't necessarily code you can rely on. There are a few things we never skip:

Security check. An app that runs on the internet, especially one with logins and user roles, should get a separate security check. You can ask your AI assistant to review its own code the way an attacker would, or set up an agent that does nothing but this, but if the job is serious, we'd say have an expert look at it. Check regularly whether the libraries you use are up to date.

Data privacy. ID numbers, phone numbers and client details are the data that do the most damage when they leak. Decide at the very start where the data will live, who will see it, and what the app should never store.

Test with sample data. Don't develop on real records. Try things with made-up employees, drives and equipment. It's safer, and you can experiment without worrying about breaking something.

Backups and version control. Put the project under version control (such as Git) from day one, so you can undo a change that went wrong. Back up the data separately too.

Scan before publishing. If you are going to publish the app as open source, scan the code and its history from start to finish for passwords, API keys, and personal and company information. A client's name or a password typed during testing can stay in an old record even after you've deleted it. When we decided to release qRaf and Tastamam as open source, we did this scan as a separate job.

Plan, small step, try, approve

A person thinking at a desk in front of a large monitor and two laptops

How you work matters more than the tool you use. Ours goes like this:

Plan. Before any code is written, write down what the app will do and what it won't. Let the assistant ask questions. A short plan you've agreed on saves hours later.

Small step. Ask for one change at a time: a screen, a button, a report. With big requests the changes get tangled, and when something breaks it's hard to find out why.

Try. Run the app and use it yourself with sample data. Even if the assistant says "done", look at the result with your own eyes.

Approve. If it works, save that version and move on. If it doesn't, go back a step instead of piling new fixes on top.

It looks slow, but in practice it's the fastest way, because you never end up untangling code that has become a mess. And at every stage, read everything, every file. Just saying "approve" and moving on makes the work less efficient.

Is it for you?

If you run a small company, a production or a brand team, and you keep having to shape your work around software that doesn't fit you, it's worth trying. Start with something low-risk that stays in-house: an inventory list, a checklist, a tracking sheet. Or rebuild an app you use often to suit you. Don't use real data until you are sure. Keep the first tool small; the second one comes much more easily.

If you'd like support with this or want your own app built, get in touch. Let us help your company through its move to AI.

Photos: Lukas Blazek / Pexels · olia danilevich / Pexels