A Report on the Hitabis SkillDay 2025
We’re a software development team based in Berlin. A few weeks ago, a client approached us and asked, half-jokingly, why we still do so much programming by hand and why our development process takes so long. After all, there are so many AI tools that could handle these tasks completely and in no time at all. Vibe Coding, they said, is the tool of choice for quick success. Our client is tech-savvy and has a very optimistic view of the capabilities of AI tools. However, we didn’t have a well-founded answer ready for his very direct question.
We’ve been using developer assistance tools like Copilot for quite some time now, of course, but as developers, we have rather mixed feelings about them. In some cases, they make our work easier. In others, they vehemently suggest solutions that are wrong or impractical.
To get a clear picture of the current state of affairs – even for “the big project” – we’ve been taking a close look at product studios. These are modern, often AI-powered platforms that promise to replace entire product teams in software development. They offer everything from design and implementation to operations, without requiring in-depth technical expertise.
But how realistic is this promise? We decided to conduct an experiment to find out exactly that:
What exactly are product studios?
Product studios are modeled after traditional design or film studios – only for digital products. Whether they’re called startup studios, venture studios, or digital innovation studios, their goal is clear: to turn an idea into a working product in record time.
Characteristic features include:
Rapid MVP Development
UX/UI-first approach
Use of No-Code / Low-Code
Modular tech stacks
Out-of-the-box Deployment
Iterative, collaborative processes
What is possible – and what isn't?
As part of the pilot project, the “HitabisSkillDay” app was designed with a clearly defined set of features:
Login/Registration
Access to news, events, and members
Bookmarks and Messenger
A special feature called “Call for Help” where members can post requests for assistance
We’ve now asked the product studios to build this app for us. We wanted to see how they’d handle the instructions and what results we could achieve together.
Studios used
We’ve selected the current market leaders in this field and put their marketing claims to the test: Lovable, Bolt.new, and Firebase Studio..
lovable.dev
Lovable is an AI startup founded in Sweden that offers a design-centric product studio which develops digital products with high-quality user interfaces and a cohesive aesthetic – true to the motto: “If Apple were an indie product studio.”
The experiment begins with a brief prompt.
I want to build a PWA using SvelteKit, with Prisma as the database and ORM. The app is called “HitabisSkillDay,” and here is the logo
OK. Lovable ignored our instruction to use Sveltekit for now, but at least provided a good explanation for choosing the alternative. We can live with that. We’ll wait and see what happens.
The result was impressive – an attractive website was created—but, of course, the information provided in our prompt was far too limited. This is where the much-discussed concept of prompt engineering comes into play: You must always give an LLM as specific instructions as possible. A new attempt should fix this.
OK. The app should be more suitable for mobile devices. It should be an iOS/Android PWA. Also, the focus is off. I need a login and registration feature, and the page after login should look like this. For now, the following features are required:
* News articles marked as outdated by the editorial team—you retrieve these via the API from a WordPress instance: https://externalblog.hitabis.de
* Events are events that are also maintained in this WordPress instance: https://externalblog.hitabis.de
* Users can search through news, events, and members
* Users can add members to their personal favorites * Users can send messages to other members
After a minor glitch that lovable was able to fix on their own, the result looked much better.
Unfortunately, the white text on a white background was the first thing to go. Unfortunately, the login didn’t work either.
Despite the success message, unfortunately nothing happened. But that was because Lovable hadn’t implemented any logic. A look at the generated code showed that only UI elements had been created. Lovable had put a lot of effort into the design, but hadn’t implemented any backend functionality.
The app itself, however, was quite impressive.
The implementation was once again presented in an appealing design, though unfortunately it differed slightly from the previous design. It didn’t quite fit together. Furthermore, these were mostly mockups again. No functionality was implemented, even though the prompt explicitly requested it.
bolt.new
Bolt.new is a U.S.-based product studio developed by StackBlitz (known for WebContainers) that enables ultra-fast MVP development through its platform – promising launch-ready prototypes in just a few days.
We gave Bolt the same task.
At least Bolt had been persuaded to use Sveltekit. The file generation process then began, but Bolt failed to implement the project.
StackBlitz’s core competency – providing development environments – kept failing repeatedly when attempting to install the dependencies. Over several days and across multiple sessions, this error occurred time and again, and the AI was unable to resolve it on its own.
Local download and interim results
To avoid writing off the attempt as a failure right away, the generated source code was downloaded and the dependencies were installed. After resolving a few issues with the dependencies and imports, the project started up. However, the result was more than disappointing.
Apart from a few generated components, all that was visible was the Svelte landing page.
Firebase Studio
With Firebase Studio, a major player has entered the fray: Google offers a powerful no-code/low-code platform that is particularly well-suited for rapid prototyping, admin interfaces, and internal tools – all directly integrated with the proven Firebase ecosystem. Everyone can decide for themselves whether the latter is more of a blessing or a curse.
Firebase had a clear plan.
but remained unimpressed by our suggestions for improvement.
Firebase refused to adapt to our design. Even our choice of framework was simply ignored, despite our repeated requests.
After the generation process, several errors occurred. It’s a shame that so many errors occurred, especially since a template was being processed anyway and our instructions were ignored.
At least Google was able to fix these errors on its own. The result was anything but convincing.
Conclusion: Impressive, but not (yet) a replacement
Product studios can significantly speed up many aspects of product development – particularly design, prototyping, and testing.
Similar to the experience with Copilot and similar tools, they reduce the developer’s workload and accelerate many parts of the development process. However, they do not replace full-stack development, especially when it comes to complex logic, authentication, real-time communication, or API security.
Presenting product ideas is greatly aided when, for example, potential investors are given something “tangible” to hold in their hands. For digital products, a prototype is ideal. Product studios are particularly well-suited for presenting product ideas, as they allow you to quickly produce presentable results that make a strong impression. The backend integration, which has largely been missing so far, plays a rather minor role in this case.
So the straightforward customer question can be easily answered: Product studios are a good way to create click-through mockups. However, the bold marketing claims made by the platforms mentioned above can only be partially substantiated. Even using a product studio requires an experienced developer.
Interim results, such as individual UI components, can be incorporated into the development of the final product by the product studios. However, AI systems are not yet capable of handling the complexity of “normal” software projects. With the ever-expanding context windows of large language models (LLMs), this hurdle could eventually be overcome. We’ll have to wait and see.