> TRM obtains 45% test-accuracy on ARC-AGI-1 and 8% on ARC-AGI-2, higher than most LLMs (e.g., Deepseek R1, o3-mini, Gemini 2.5 Pro) with less than 0.01% of the parameters.
what would be the minimum set of customization required to satisfy the majority of the tweaks requested by internal users?
would it be sufficient to offer themes (dark/light modes), a custom logo, and control over font sizes? or, is it more fundamental, like adding your own css and changing the size/positioning of components?
Even your "more fundamental" examples are just scratching the surface.
I know you're a Chief Technology Officer not a Chief Product Officer or Chief Sales Officer, but if you're not already getting an earful from prospects or clients about wishlist items on the frontend, gird your loins, because it's coming.
I work on a Bioinformatics team, so we are a bunch of programmers, but not fully-fledged software engineers. We know Python well but have no front-end experience.
Some examples:
- Another non-technical team needs to know if our test covers specific genetic variants. The code to answer this is 10 lines of Python + a 100 line CSV. We can solve this with a CLI on our local computers but to serve it to the other team was a huge blocker until we started using NiceGUI. Now its 10 lines of Python + 10 more lines of NiceGUI Python and they have a website to go to so they can self-serve the answer to that question. All done in a 2-4 hours.
- More complicated, we have a workflow where we want to select data from a database via a series of filters, run some automated algorithms on it to generate new data, denormalize and view the data, manipulate it using an Excel-like interface, and then update the database with the edits that were made. NiceGUI + their AG Grid integration let me build an application that has all the great GUI features of Excel when it comes to grid-based data manipulation but is fully programmable with 99% Python (and like 1% JavaScript).
- I also built a data hub that integrates and displays data from a bunch of our different data sources and displays it based on some queries. If I can write a tool in Python to do something, I can now easily deploy an internal app that does that too, without knowing any front-end code. It even has the flexibility that when needed I could dive into a bit of HTML with the help of ChatGPT to embed iframes of PDF files getting served directly from S3 links.
The great thing is that this is all done in Python, all version controlled in the same repo as the rest of our codebase, uses open source software, and can be deployed easily within our VPC using terraform+docker. So it's a very maintainable dev ops experience compared to most other no-code/low-code tools, while at the same time enabling people who have programming (but not really engineering) experience and are subject matter experts in other areas to build fairly complex and customized GUIs.
It's also using FastAPI under the hood so you can implement some things at that layer as well. I know that's how they suggest implementing Auth, but I haven't dabbled with that as well.
these are great examples, thanks for sharing! the second one is particularly interesting. python seems like a perfect fit for that use case.
are there any limitations you encounter with NiceGUI? do you need a user permission feature or does each user get admin access? can you see it scaling up easily?
Auth is a big limitation. It's not a built-in component, they have an example [1] using the FastAPI layer for auth, but I haven't had the time to try implementing it. It's definitely not something you get out of the box with NiceGUI.
For scaling, I am viewing it mostly as an internal tool builder. I wouldn't recommend it for external applications. So as far as scaling an internal app I think it works fine. Their website [2] is built with NiceGUI, and it works fine, but you can feel the lag occasionally on some of their larger demo pages.
yes, that’s us. glad to see you remember our previous iteration :)
internal app builder is certainly a challenging market to break into, but we believe we have something interesting to offer and are quite optimistic about our approach.
were you a customer of the previous dropbase version (csv to database)?
thanks again for your interest, it is always appreciated!
correct. internal apps are usually built by developers for internal users. examples include processing refunds, updating customer information, managing user permissions, triggering batch jobs, and etc.
the goal of internal apps is to optimize tasks that are tedious and time consuming, but not too common for an off-the-shelf product to be available.
since the internal apps aren't the main product developers work on in a company, they prefer to build them quickly with minimal resources.
internal tools usually run on a server, as does Dropbase
i second that. for external-facing tools, you probably want something custom, branded, and more flexible. when it comes to internal tools, you typically want something quick to get the job done.
at dropbase, our focus was on enabling developers to get stuff done efficiently. we noticed that for 90% of internal tool use cases, you only need a table and modal to get user input. so we focused on developing those. while it may not be sufficient for external apps, for internal tools, it should cover most of that you need
Are you aware how most companies external apps look like? Here's how: They don't.
What you compete with, what you have to beat, is not "something custom branded and more flexible". It's nothing at all. Cutting yourself out of that market with a tool that would easily be powerful and user friendly enough to fill this gap does not make any sense to me, if that is in fact your true reason. (And also I don't understand how that could make any sense intuitively if you just look at how often you see google forms being used by a big company as an external data collection tool).
It could be such an obvious differentiator for any of the competitors – but, like I said, I suspect the actual reason to why people are so ready to give up on this is rooted somewhere else.
This is actually quite encouraging for us as product developers (although maybe it's not a good thing if end users don't get good tools). It just means there's a lot more room to grow. I wouldn't say we've given up on external, but there's definitely a part of us that's hesitant to communicate the product as a "build anything" app so early. The fact that you think that could actually be an obvious differentiator is quite intriguing and thought provoking. I should do more research and understand the extent to which customers of big companies are exposed to google forms (and similar tools). Maybe we'll discover something interesting in the process. Thanks!
I understand. Maybe a niche for you, that might be interesting to explore,from my latest personal experience: Managing a medical business, including a combined portal for patients and providers.
For the patients, you might need submission process, you might need a place for people to see or cancel their next appointments, fill out a form or upload some pictures from other, while also making this information available internally, with doctors being able to document therapies and such.
Nothing fancy; I would hardly call it "build anything", it's all fairly CRUDy and on the face could be very effectively handled by all retool-alikes. (In fact budibase for example could have easily filled the need from a technical standpoint – but having to pay xx$ indefinitely per "customer" just does not work out, when you see most of them only once a year and maybe only once total, while having to keep records for many years.)
That's an interesting use case. Thanks for sharing. I think I understand your point better after reading this. I agree that having to pay xx$ indefinitely for presumably many end users who will only fill up the form once (or very rarely) doesn't make sense. We don't have a solution to this just yet, but I have a couple of ideas on how to tackle this.
PS. CRUDy sounds like a fun and quite literal name for an app builder!
yes, it's a bit inconvenient, but user management and ui component definitions are managed by the dropbase server. because of this, we need an account, with a token to identify and authenticate a workspace
frankly we're new to open source. and technically we're not really open source. we wanted to take advantage of the self hosted nature of data processing worker, which are safety, extensibility, and developer trust. that's why the worker is under the source-available model.
as we grow and learn, if we get interest from the community to contribute, we'll definitely consider opening more of the codebase.
Also fun fact: originally we only intended to enable self-hosting for the Worker, but we ended up enabling self-hosting for the Client too. If we also end up enabling self-hosting for our backend API then we'd probably rethink our distribution approach
