A couple of them mentioned that they plan to cancel subscriptions totaling more than $100k/year for the apps they will replace with that SaaS. According to them, they have many subscriptions they keep only because of one feature. Another issue is that their workflows become a real mess when they need to copy and paste data into multiple tabs. Custom-built internal tools seem like an obvious solution. Those who migrate to custom-built tools, however, will face the challenge of orchestrating their lifecycle and creating a consistent deployment workflow, but this is one of the challenges we are trying to solve at UI Bakery.

In my understanding, SaaS products that provide customers access to proprietary data are in a much better position than other SaaS platforms. HubSpot’s acquisition of Clearbit a couple of years ago now makes even more sense because it will help them retain some of their clients.

I have also seen multiple similar use cases where non-technical users build internal tools and dashboards on top of existing data for our users (I'm building UI Bakery). This approach might feel a bit risky for some developers, but it reduces the number of iterations non-technical users need with developers to achieve what they want.

Many of you have probably used drag-and-drop builders to create internal tools or dashboards. They’re great for quick prototypes - but as projects grow, the same problems always appear:

1) Performance issues. D&D builders add a lot of runtime overhead. Once you add more screens, logic, or connected data sources, things start to lag - and you have little control over optimization. 2) Limited flexibility. You’re restricted to the vendor’s components and configuration options. Anything custom usually turns into a hack. 3) Design overhead. You still spend a lot of time manually picking components, arranging layouts, and tweaking spacing before even connecting data - and the final result often looks… meh. 4) Maintenance pain. Opening an old project (or one handed off to a new teammate) often means digging around to find where things live. There’s no simple way to reason about structure or reuse.

At UI Bakery, we kept asking ourselves how to fix these issues without losing the speed of a low code builder.

First, we built an AI assistant trained on our docs. Then, about 1.5 years ago, we launched the AI App Generator, which could generate UI Bakery apps from text prompts. That helped, but under the hood it was still drag-and-drop - with all its inherent limits.

That’s when we decided to rethink the foundation entirely. “What’s the most flexible, customizable project model possible?” The answer: code.

So we rebuilt our approach and are now launching UI Bakery AI App Agent - a new way to build secure internal software by chatting.

Key features:

- Data connectors: Connect to SQL, NoSQL, REST APIs, and third-party services. - Speed: Start from a plain-text prompt - AI generates a fully functional app in minutes. - Code ownership: Access and edit the generated React code directly. - Security: RBAC, SSO, SOC 2 compliance, audit logs, and deployment either in our cloud or fully on-prem. - Customization: Use any React component you find online or build your own - it’s all just code.

Who is it for?

- Founders/CTOs automating internal processes. - Developers tired of rebuilding CRUD/admin UIs from scratch. - Enterprise teams needing internal tools with advanced security (on-prem, SSO, RBAC).

We see UI Bakery as the next evolution beyond drag-and-drop builders — from "fast but limited" to "fast, customizable, and secure."

We’d love to hear what the HN crowd thinks: If you’ve used drag-and-drop builders, what’s been your biggest pain scaling or maintaining them? Would you trust AI to generate internal tools that you can later expand like a normal codebase?

Try it here: https://uibakery.io

Comments URL: https://news.ycombinator.com/item?id=45669218

Points: 3

# Comments: 0

Does anyone have experience migrating from Height, and what did you choose as an alternative?

Comments URL: https://news.ycombinator.com/item?id=43454034

Points: 2

# Comments: 2

When deciding whether to build a replacement yourself, consider whether this solution could become a competitive advantage in the market. This is unlikely to be the case for a logistics company unless you plan to sell the software you build. From a business perspective, it's usually better to invest in your core strengths and outsource everything else as much as possible. Otherwise, securing the budget to hire the right talent in the right amounts will always be more challenging.

Assuming software is not your core strength, it may be wiser to search for one or several solutions that you can combine to support your strategy for decades while providing a certain level of flexibility. This might also mean building some parts of your system with low-code or even custom code, but I would try to keep that to a minimum.

If you still decide to build something custom, my recommendation would be to avoid replacing everything at once. Instead, replace your existing solution gradually. Start by rebuilding the most problematic functions first, and then add other features as you go. You might find along the way that some parts of the older solution's functionality are no longer needed.

As the founder of a low-code SaaS product (https://uibakery.io) and a service provider company (https://www.akveo.com), I can definitely relate to your challenges, which are quite similar to those of my clients. If you need any help with your transition, feel free to reach out at vlad a-t uibakery.io, and I can look at your use case in more detail or connect you with others who might help.

Additionally, I know many great developers who do not have portfolio websites.

Just like the title of the article suggests, GraphQL is great, but ONLY in the right context.

Since the release of ChatGPT, there have been multiple attempts to simplify the work of software engineers. UI Bakery is excited to join this trend by introducing our AI App Generator.

This tool enables non-technical users to generate internal tools, CRUD apps, and admin panels simply by connecting their data source and providing a text prompt with their desired outcome, all without the involvement of software engineers. Additionally, it is possible to modify the generated app with a follow-up prompt or by using the UI Bakery visual editor. Once the app is ready, it can be shared with other users by inviting them to the workspace.

Currently, we support connections to external SQL databases and UI Bakery's managed Postgres database as data sources. However, we are eager to learn about the use-cases you envision for our tool and to explore ways to expand its capabilities.

Comments URL: https://news.ycombinator.com/item?id=39968961

Points: 7

# Comments: 1

However, it's still sad that in the end, the customers suffered the most. While I agree that the founder probably did fairly well in his situation, it's unfortunate that he did not consider or did not manage to achieve other options, such as buying out the company from investors. They had a decent product that could have become a successful and profitable business within its niche.

Comments URL: https://news.ycombinator.com/item?id=39387529

Points: 2

# Comments: 0

2019 - 1,744,299 2020 - 1,904,694 2021 - 1,445,042 2022 - 1,278,496 2023 - 633,163 (which is a 66% decrease from 2020)

Does anyone think StackOverflow will be able to pivot?

Comments URL: https://news.ycombinator.com/item?id=38984742

Points: 9

# Comments: 12