Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Refine (YC S23) – Open-source platform for enterprise web apps
259 points by civan on Aug 9, 2023 | hide | past | favorite | 92 comments
Hi HN! We’re the co-founders of Refine (https://github.com/refinedev/refine), an open-source platform for developing enterprise web applications rapidly. In one year since launch we have 15K active developers each month, and over 5K projects in production. Among the 5,000+ projects deployed to production, we see a lot of admin panels, dashboards, B2B portals and SAAS interfaces.

Check out our online generator at (https://refine.dev/#playground) to create a custom Refine application and download it.

Before starting refine, we spent five years as a consultancy company building internal-facing applications for enterprise clients. We have seen many complex use cases where the demanded flexibility was much higher than what existing low-code/no-code solutions provide. Moving away from rigid architectures and pre-made components that are difficult to customize, developers tend to start from the scratch. This results in a significant waste of time and resources.

In order to find a sweet spot between “starting from scratch” and higher level solutions, we started working on refine. After a couple of iterations, we came up with a “headless” solution, separating the UI-layer completely from the rest of the frontend logic. This allowed us to support multiple UI frameworks and custom designs out of the box.

We understand the importance of frontend developers working with the stack and tools they love and are familiar with. So, we have built our project creation wizard that allows developers to mix and match their technology stack when creating a project.

After 1.5 years of development with the great support of the open-source community, Refine has become a mature framework that allows developers to rapidly build enterprise applications and have 100% control over their projects.

While remaining unobtrusive, Refine still saves a lot of development resources by eliminating repetitive tasks such as CRUD operations, state management, routing, authentication, access control, and i18n. It’s also backend-agnostic and works with any APIs or services.

The best way to start Refine development is visiting our extensive documentation at (https://refine.dev/docs/). Here, you can also find tutorials and real-life examples to use as a starting point for your use case.

We had one successful Show HN earlier this year (https://news.ycombinator.com/item?id=34515128), and have since had several major releases and added many more features.

Recently, we've released our enterprise edition featuring deployments, built-in security, backend integrations and auto-generated UI's. By expanding Refine's capabilities beyond the frontend, the enterprise edition offers a complete solution for the internal tooling requirements of larger organizations. To get more information, please see our pricing page: https://refine.dev/pricing/.

If you have any questions, ideas or suggestions please share them with us. The team will be here all day to answer. We look forward to all of your comments!




Why do people keep comparing refine with nocode tools like windmill or tooljet? Refine just scaffolds your codebase, gives you a good start and has some really cool hooks for common operations like auth / data management / tables etc. I use it for my SaaS and it's great (though they never replied to any of the enquires i made for enterprise). Once you scaffold the project, then you're on your own.


> Why do people keep comparing refine with nocode tools like windmill or tooljet?

Because they market it like that. Their tagline is "Open-source Retool for Enterprise", and retool is a nocode (or low-code) tool.


I’m really tired of all of these “low-code” tools for the enterprise.


It’s something like https://www.airplane.dev/ a closer alternative to Refine? Or how does it compare?


You've captured Refine's purpose perfectly – it's all about scaffolding your codebase and providing handy hooks for tasks like auth and data management. We're thrilled to hear that it's been a great fit for your SaaS needs.

We sincerely appreciate your understanding. While we regret any previous oversight in responding to your enterprise inquiries, we're actively addressing all incoming applications now. Your interest matters a lot to us, and we're working to ensure a smoother experience.


I once tried a Refine tutorial made by the Refine team, hosted on their website, when it was suggested as an alternative dashboard maker to Retool. I ended up being confused even more, so I went back to Retool.

I'm a noob. Retool can be used by a noob. Your tool can't, so it's not a Retool. That's just the bitter truth.


I am a bit confused by these tools. Can someone analogize what they are doing here? It somehow reminds me of the Django admin capabilities but expanded to any Typescript base technologies?

I have trouble wrapping my head around the use case for this. Is the target market existing businesses that already have APIs (probably as REST services), maybe some databases and they just want to quickly wire up some UI to it? It seems a bit heavy handed for writing an entire application.

I can imagine maybe a medium sized business where the data science, sales, marketing, customer service etc. teams want some access to the production system data in a format other than Tableau or Microsoft BI. And perhaps their engineering team is entirely focused on product development or operations and so no significant resources can be allocated. I guess this might allow more junior or jack-of-all-trades engineers to whip up basic admin features?

To be honest, even in small startups I've worked at, cranking out admin dashboards using React was just so trivial that I can't imagine paying to make it slightly easier. And looking at their code examples, it doesn't seem all that more simple. I suppose there maybe some goldilocks zone between startups that just crank that kind of stuff out and huge enterprises where entire teams exist to manage internal tools. In that zone perhaps having these kinds of platforms can expedite internal tooling creation.


> To be honest, even in small startups I've worked at, cranking out admin dashboards using React was just so trivial that I can't imagine paying to make it slightly easier.

I haven't tried Refine, but with Retool, we had non-developers able to build themselves functional admin tools in literally minutes.

Writing new code, regardless of how great the React components are, just doesn't come close. I can do things with Retool in 2-3 hours that used to take a week or more of a senior React dev's time. It's at least one order of magnitude of difference, maybe more.


If this was a no-code solution I would agree. But the developers themselves are in this thread saying things like: "One of the key differences is our code-first preference over no-code, which distinguish Refine from the drag-drop style workflows of Retool, Appsmith, Tooljet, Budibase etc." Their github README has a short 75 line snippet that shows the React-ish code one needs to implement a basic dashboard for a generic REST service. One of the top comments was from an operations guy asking: "Why do I have to choose between next.js and Remix?" Clearly they are targeting this towards development teams to lessen their burden and not directly at support teams to roll their own. Choosing between next.js vs. Remix only makes sense to a developer.

As for "2-3 hours" in no-code vs. "1 week" for a developer, I might challenge that. In many cases if a support team (sales, customer service, marketing, etc.) asked a product team to build something custom for them then they are going to quote product development timelines. However, Most places where I've worked where admin tooling was expected and high-quality the admin features were part of the product feature development. In general, most functionality would be added in some small part of the feature dev time. For example, a 2 week sprint for a new product feature might include 1 day of adding functionality related to that feature to the admin. That is to say, your 1 week quote is almost definitely not the time it would take to add the features but a block of time the product team is quoting to make you go away. That is an org problem, not a technology problem. With Refine, I don't think you will bypass this problem since you will need someone capable of using at least React and whatever stack you configure the tool with.


Cranking out an admin dashboard in react then also means supporting an admin dashboard. The dev is now on the hook for user issues, additional feature requests, hey can you just add this other field, etc… The dev is interrupted and distracted from other work while the other internal team is slowed down and blocked waiting for the dev to clear their tickets.

If you have semi-technical users (can muddle through generating SQL using stackoverflow) then unleashing them on a read-only DB copy with an app builder can be better for everyone involved.

Something like: “Hey I saw your ticket requesting a ‘user address’ field in the dashboard, do you want the mailing address or billing address? Lmk then I can probably add this today and it’ll go live in the next deploy” -> user instead adds the field on their own in < 5min

Lots of additional use cases for other db interactions too where “let’s just spin up an internal admin panel in the app” can turn into days or weeks of getting input and now the design needs to be thought about and more stakeholders consulted vs. absolute basic functionality being stood up in Retool in a couple of hours. It’s sort of similar to presenting a wireframe instead of high-fidelity mock-ups


My first point, which I elaborated on in another reply to my comment, is that this makes sense for tools that are completely no-code. Refine brags about being developer first. Their example on github is a 75 line React-ish script. So, someone is writing, testing, deploying code. If that isn't your dev team, then who is managing that process and supporting it when someone inevitably borks it?

My second point is that even no-code tools tend to require developer support sooner or later. What I've noticed for admin tooling is that it often works best when it is driven by the product team. For example, customer support requests comes in which requires devs to stop working, investigate the issue, manually fix up data where necessary, etc. Devs hate doing this. Give the dev the ability to add the functionality to the admin and they often will, just to make the support requests go away. If you take away the admin from the product team then there is more friction in this path.

I will admit however, that the quality of life improvements demanded by the support teams often go un-attended. But I don't see how Refine will help this go away if it requires someone familiar with next.js/React, Ant/MaterialUI, etc. to make changes.


Ah, I hadn't tried the Refine demo and was going totally off of past Retool experiences where creating or modifying an app can mean just picking a UI component and adding SQL.

Refine does appear to require developer build-out and is more of quickstart framework.


You can build low-code tools with Refine though. One of my side projects Jinjat (https://jinjat.com) uses Refine as the UI framework to render the data models that you have in your dbt project, as an example. Retool is an end-to-end tool whereas Refine focuses on the front-end and gives the flexibility in the backend for your business logic, which is often hard to scale out with Retool.


I believe this is an highly productive discussion, and the question narrows down to "which tool is a better match for a specific use-case?"

The domain of internal-facing applications is quite diverse. One use-case can be a single page internal tool, triggering a small script. On the other extreme, organizations build SAAS/B2B interfaces with 10+ pages/resources maintained by dedicated development teams.

Need to deploy atomic internal tools where technical and non-technical roles collaborate? Retool, Superblocks, Appsmith, Tooljet or Budibase are perfect solutions. Turning scripts/workflows to basic UI's with integrated security and observability? You can choose with Windmill, Airplane or Onu. You don't want any overhead or learning curve for your lean project? Start from scratch and build with the great tools React community offers.

Refine becomes a better option for complex cases and higher customization requirements. You can give it a try if * You have to implement a custom design / design system, * You want to be able to customize your stack instead of locking in a black-box architecture. * You a need robust architecture for your long-lasting project proven by thousands of community members.


I worked at a startup that had many internal tools for solving small problems using Retool. One frontend guy even added a "diff" component so we could compare json payloads and manually edit them.

I have to admit that it's not the best of the worlds, but for small, focused internal interfaces that call some APIs, it can serve well.

Don't know about this new tool, but talking of retool itself, I also don't see it being used for a full fledged customer facing application.


Retool and others are internal application platforms. The concept exists since the dawn on computer. SAP, IBMs of the world always had one offering like this.

You always need an internal platform may be for seeing the order status of the shipped product or some customer data etc. The consumer of the tool is a customer service agent or an internal employee etc. These tools does not have to be perfect , they have to be functional.

It has always been a huge market as it saves ton of money for an org. These days as building UI and APIs have become democratized, the market for internal applications platform have become very competitive.


I’m not sure I agree that it’s open source and enterprise. Many of the enterprise features (eg SSO) don’t appear to be part of the open source version. That’s fine, you can and should monetize your work, but your enterprise and open source editions seem separate.


You get the code with the Enterprise version, so it is open source but under the Enterprise license. The community edition is open source under an MIT license.

You need a license to get the Enterprise code. Many other software work this way.

I'm curious about what their Enterprise license looks like and what you can and can not do with the code.


Comments like this are proof positive to anyone still wondering. In the wild, open source no longer means open source.


I'm guessing you have to pay for it and that you can't freely redistribute it, in which case it's not open source.


That’s not what open source means.


There is a lot of activity in this space, and I think it's a good thing.

Other very similar but less code-heavy solutions include appsmith, tooljet, or budibase.

In the same spirit, but SQL-only instead of based on javascript, I am currently working on https://sql.ophir.dev . It also allows building entire data-centric applications and internal tools very quickly, but without having to think about things like "remix", "vite", or "next.js", which sound like chinese to most non-developers.


This does look handy for turning an SQL query into a table/cards on a webpage.

It basically seems to use SQL (instead of e.g. JSX) as the component configuring/templating language (in addition to querying). Which is a little odd, but does work for simple use cases like tables, cards, and grids.

I'll give it a try the next time I have to quickly present an SQL query as a non-customised report. Thanks!


I love this and already prefer the Hasura and Supabase based approaches where tryouts database/ data schema is your application - including business logic. Being able to scaffold an admin on top of that saves so much time.


Congrats on the launch!

How does your product compare to Retool and other products in the space including the OSS ones (Appsmith, Windmill, Tooljet etc)?


At Refine, we try to take a fresh approach to a space with very strong existing players, as you mentioned. Our philosophy is keeping the developer-centric focus and provide the best experience possible to make boring enterprise CRUD apps fun to build.

One of the key differences is our code-first preference over no-code, which distinguish Refine from the drag-drop style workflows of Retool, Appsmith, Tooljet, Budibase etc.

Instead of offering a fixed set of pre-made components, Refine outputs a real React project with collections of helper hooks and providers. The "headless" architecture enables developers to integrate any preferred UI framework or custom design, thereby maintaining the highest level of customization and styling options.

This level of flexibility fits use-cases like complex admin panels, SAAS interfaces and B2B portals rather then single-page internal tools which require little or no customizations.


Will also throw in react-admin there. React-admin is not the same space per se (it's basically a react framework, not a low/no code tool), but if I built an internal admin app in react-admin, what would you say the pros/cons are to moving to Refine?


refine's headless architecture offers developers the flexibility to implement their design using any UI framework to their apps. It also comes with built-in UI integrations for popular libraries like Material UI, Ant Design, Chakra UI, and Mantine.

With react-admin, you have no choice other than using Material UI for your app. refine's provides nearly all the features of react-admin enterprise provides as open-source.

Since refine's architecture is headless, router logic is completely detached from the business logic and UI layer. So you can use refine with React Router, NextJS, Remix, or any other framework may pop-up as long as it's React based. With react-admin, you can only use react-router and it doesn't have a real SSR support, while with refine, you can use SSR frameworks like NextJS and Remix without being limited.


React-admin lead dev here.

Short story: Refine and react-admin were in the same low-code space (targeting developers) until today, but it seems they've pivoted to no-code (targeting non developers) as they go after ReTool.

Long story: https://marmelab.com/blog/2023/07/04/react-admin-vs-refine.h...


That article is top 5% of biased articles I've read in my life. Really bad look to be honest, would have really liked a more objective comparison


Post an article biased the other direction to set a counter-balance.


Just for clarity: the author of this comment is not from our team. But if you ask for my opinion, I enjoyed reading the article. We always pursue ideas that will take 'refine' to the next level, and this piece was helpful to us.


One suggestion, as someone who is an Infra engineer and doesn't know frontend too well anymore, the first step in the demo asks me to "Select your React platform"

I don't know what that means, and what the implication of choosing between Vite, Remix, or Next.js -- it's meaningless to me.


Oops, you're absolutely right. The frontend ecosystem is quite complex, and the entry barrier for engineers working in other roles is getting a little higher every day. Perhaps by default, Vite should be used, and Remix or Next.js alternatives should be shown for advanced frontend developers. Thank you so much; we will definitely improve this area.


Something else people may want to consider is the community health. Vite, Remix and Next.js are all extremely healthy, but Next.js is currently in a league of its own. You can see the community information for all three at:

https://devboard.gitsense.com/vitejs/vite

https://devboard.gitsense.com/remix-run/remix

https://devboard.gitsense.com/vercel/next.js

The only other project that I've seen with greater engagement than next.js on GitHub is Microsoft's vscode.

Full Disclosure: This is my tool.


ha-ha, brother, I feel you. Infra engineer (VP last position) and built an app with Refine. I was exactly in your position not a long time ago. I tried to choose "The Best Framework Ever" and made a lot of mistakes, and at the end, if you don't know frontend go with the flow: React + Next.js. Not because they are Best Ever, but because the majority of content online is dedicated to these frameworks. StackOverflow, ChatGPT, a friend who speaks frontend, etc.

I did some work as part of my consultancy, had data left and decided to try my hands at frontend. Oh, boy, I think it was a mistake, but it was a lot of fun, will do again. https://cloudprice.io


The deceptive part of these types of frameworks is this: on the first day, you think it will solve all your problems. On the second day, you're happy, thinking about how much you've sped up because you chose this framework for your project. On the third day, you have a custom need, and you research how to do it within that framework. On the fourth day, you hack the framework to make it flexible. On the fifth day, you say, 'Why didn't I start from scratch myself?'

Our goal and motivation in developing refine is to ensure that the developer continues to feel the way they felt on the first day, even on the day they finish the project and begin to maintain it.


And on the sixth day you have uncontrollable flashbacks to the days of using jquery to manage your application state as a singleton in the global scope and you die a bit inside ;).


why no one came up with the idea of reactive jquery i don't know. or, may be someone did?


literally this. but to the benefit of refine.dev i should say that you made the framework extremely easily hackable, at least where lame me wanted to hack it. your data backend didn't work with my rest api, i've asked on discord and someone said: hey, it's actually in the docs, you just copy our default implementation into your project, import it, make sure it works as before and then hack it as your own code. a productized hack, i'd say.


If I understand correctly, using 'swizzle' to customize the data provider is not a hack for refine, but an expected behavior. But I'm curious about the conversation; could you possibly share the link?


the ease looks like a hack, since it's documented it's not a "hack as in workaround". in my vocabulary "hack" is a compliment, not a derogative. i grew up on jargon file.


I tried to use the site you mentioned at the end of your post, but when I tried to add an ec2 instance (searching for ec2 resource) I got a 500 error "Error talking to backend server: 500".


hm, indeed. thanks! interesting, i need to investigate. i just redeployed the same code to the cloudflare worker and it worked.


Would like to recommend an open source Low Code framework https://frappeframework.com, significantly reduces the code to be written.


The main page says “Eliminate 97.42%* of your software development effort”…

That’s a very specific percentage of effort to eliminate. How did you arrive at that figure?


73.6% of all statistics are made up.


This looks cool. The pricing page says the enterprise edition is open source, but I can't find it anywhere. Am I not looking in the right spot?


If you're building a Refine app and want to deploy it to AWS or GCP in your own account, I just posted a setup video of using Refine on Coherence (withcoherence.com): https://youtu.be/gFCXXU72Nec. We're happy to get you set up the same way if you get in touch (disclosure - I'm a cofounder).


How is it different from https://github.com/ToolJet/ToolJet ?


Refine is not low/no code like ToolJet or Windmill. It's still a framework that encapsulates a lot of the workflow, API clients, DBs, auth etc though


It is not AGPL licensed. Refine is MIT licensed and can be used over network without open sourcing your own code


I encountered several challenges with Refine v3 but it looks improved in v4 with the detached router and improved documentation, which I found often lacking. This still isn't as native as implementing all these features on your own though, you pretty much access everything through Refine-specific hooks and providers, so there is a learning curve. It's flexibility centric.


The foundation of our motivation to create v4 was community feedback. Thank you so much for providing us the opportunity to improve ourselves!


Congrats on the launch. I used Refine a couple of months ago to spin up an interview exercise for a SDET position. Working with the tool was admittedly a bit bumpy due to the somewhat sparse documentation (for portions), but I was pleased with the overall experience and felt that it allowed me to do in a matter of days what may have taken me a week or two in the past.


Congratulations and welcome to the open source low code club:

Budibase https://github.com/Budibase/budibase

Appsmith https://github.com/appsmithorg

Tooljet https://github.com/ToolJet


Here's what sets Refine apart: we're all about getting hands-on with the code, rather than relying solely on drag-and-drop like some other tools do, such as Retool, Appsmith, Tooljet, Budibase, and others. Instead of just giving you a set of pre-made building blocks, Refine goes the extra mile and creates a complete React project for you. This project comes packed with useful hooks and providers that make your work smoother.

We also have this 'headless' feature that lets developers seamlessly blend in their favorite UI framework or their own custom designs without any hassle. This flexibility is particularly great for things like complex admin panels, SAAS interfaces, and B2B portals. On the other hand, if you're working on simpler tools for internal use – you know, the ones that don't need a lot of tweaking – Refine might offer more complexity than necessary.


low-code doesn't necessarily mean drag-n-drop, though that is typically the association in people's minds

To us, low-code is really about creating simpler, or higher up the logical stack, abstractions, and then generating the implementation.

Our take is not so far off from yours, where we take a code first approach. Users declaratively define their application in CUE and then get most of the code. Rather than providing hooks, we let the user write directly in the output code. Unlike Refine, we enable our tool to continue to aid the developer beyond the initial scaffold phase, allowing things like the data model to update and the user gets new database migrations to be auto-generated and applied. We also make it really easy for anyone to create and share these application blueprints or generators (as we call them).

In this way, the user can select any mix of technology and make starterkits or addons for any application, not just webapps. For example we have users (ops team) injecting and maintaining CI & k8s files into their service fleets (dev team). This is a case where we see low-code, as a term, more generally.

https://github.com/hofstadter-io/hof


Also add Lowdefy onto the list https://github.com/lowdefy/lowdefy

co-founder here :)



I don't think Superblocks is open source.



Many "Enterprise" environments are still using Azure AD SSO, .NET, and other C# tools to drive internal tool development. I can't really see them jumping on this toolkit without grab-and-go support for those types of services.


This is pretty cool. I noticed in the flow I could choose which technologies to use. That's interesting because ReTool is fully hosted and abstracts that away. I could see this also being used to bootstrap regular sites at some point.


Thank you so much for your comment. We believe that the most valuable aspect is allowing developers to work in their own environment with the tools and integrations they prefer. We're very happy that we've been able to reflect this.


When I go to the win95 admin portal demo my entire monitor starts to flicker (almost with the refresh rate). Is this just brain playing tricks?

https://win95.refine.dev/


Oops, we haven't heard of this issue before. We're looking into it. Thank you


Ha, thanks for sharing this, I played with it and it was a nice fun demo, glad the Refine team had a sense of fun while putting together working demos :)


"refine is a React-based fram"

closes tab


if only more people had such sharp senses


There is a huge opportunity to integrate large language models w/ these types of platforms!


You're right, and it has already started. See for instance "Building AI-Augmented Apps With React-Admin" (https://marmelab.com/blog/2023/08/09/ai-augmented%20react-ap...)


Have you checked out windmill by rubin ?

edit: link https://github.com/windmill-labs/windmill


Incidentally I was about to comment on how peculiar it is that there are two open-source Retool alternatives backed by Y Combinator.

I know, I know, they're covering their bases, but nonetheless find it if only slightly amusing.

Piss-off a VC and they might back your competition. Get on their good graces and they'll give you both money and wait to see who comes out on top.


Coming from Enterprise and having used Retool ~3 years, I am also buffled… low code biz apps is one of those product categories that seems good initally, especially if you never worked for a Corporation, but it is really not. These tools normally don’t do governance, testing, security, users management, that well, which puts them in direct competition with MS Access. If you think MS Access is old and not web based, just use it’s evolution: MS Power Apps. Can you compete in this area? Sure, but at 100$ per seat prices, about 3-5 times less these low code tools demand. By the way, I have been quite pleased with Flask Appbuilder, which has a clean approach to crud apps, has good governance, and it is truly open source.


Does your Auth solution support Server Components from NextJS?



"Retool for Enterprise"

I assume you have no ties to Retool but using it to explain your product ? Sounded like it is a product offered by Retool so you might want to rethink that.


Agreed, really bizarre. Confusing because most people have never heard of Retool. Potentially misleading because to some it implies either a relationship or a very icky gimmick.


Sorry, that's partly my fault - I've replaced "open-source Retool for enterprise" with a more generic phrase now. Is it better?


No worries. Looks good.


Changed again by founders' request. Hopefully still clearer than the original!

Edit: never mind, people are still complaining so I backtracked.


So could we use this with DynamoDB?


Hey, with our open-core, you can connect to any data source as long as it provides a Public API. In our Enterprise edition, however, we support Direct Database connections (PostgreSQL, DynamoDB, Oracle DB) and other integrations that cannot be used client-side (such as Salesforce, Slack, Stripe, etc.)


Here are some questions, suggestions, and thoughts roughly categorized as I went through and understood a bit more about refine (the open source) and what I can glean from enterprise.

Landing Page / Initial impressions

* You mention "enterprise" a lot on the landing page, along with being open-source, but then you also call your commercial version "enterprise". It is a tad confusing delineating what is what. Having built and sold developer facing tools, *I* have enough context to understand that you mean is "this isn't a toy, you can actually use it in for-real production apps with for-real big company requirements even in open source", but I don't think you are doing yourself favors by calling your commercial tier enterprise, as it really confuses the message.

* The above is made a bit worse by the fact that you don't have any mention of a commercial product on your landing page, so when I got to pricing (usually my second page) and see enterprise, now I am not sure if the landing page is just for commercial project and open-source is just a toy.

* As far as I can tell, you don't have any marketing pages for the enterprise offering beyond the pricing page? I want to know how it differs. I want to click on the list of additional integrations. I want some docs. Anything you can give me besides contacting sales is going to help. I am not saying it is a paper launch / painted door, but it seems like one, and a thin one at that. You may have a really great product, but your GTM seems like it is lacking, and GTM for products built on open-source is super important, but generally underdeveloped by dev led teams.

* Your landing page doesn't really tell me who the target audience is, unless I have context of another product. I totally get a play that uses the momentum of another company, but I do think you lean on it a bit too hard here. I need a tagline like "Refine is an opinionated project builder for React developers designed to 10x your ability to stop fighting frameworks and start getting work done" or something to tell me who this is for without relying entirely on knowing retool. Similar, the enterprise product has really compelling features, but without more context on pricing, use-cases, etc, I don't know if it is for me.

* Your CTA and getting started is reasonable, but, as others mention here, it is giving the user a ton of choices that they may not have a clear idea of pros and cons. I suggest changing from a horizontal card arrangement to a vertical card where you have more space to provide some guidance.

* Animations and graphics for marketing pages is very subjective, but imo, the animation of the different domains of front-end apps (backend, react, auth, etc) along with the rotating list of "enterprise-ready" features is really busy and don't tell me much. I kept thinking that the firing concern would link with the enterprise ready feature, but it seems they were unrelated which just made it noisy.

Architecture / deployment model / commercial differentiation

* Are you doing the hosting directly for enterprise version and including the direct database access? If that is hosted in your cloud... that seems really tricky security wise. If you are hosting in the customer account that seems really tricky in terms of a wide range of clouds etc. I would be curious to know how this has gone so far.

* With enterprise and the direct database offerings, it seems like you have two choices of generating APIs that connect to DBs or are doing a more "direct" API that can execute SQL. Both have challenges. is there anything unique there on offer?

* The differentiation of features between open source and commercial seems reasonable... but I am concerned that because you don't have *any* ability to use any server side integration, it becomes such a different beast that you don't have an opportunity to get people to learn it. I would think that moving a "taste" of the server-side capabilities into open-source might be really helpful

Small Nits / Fixes

* The generated project has a lot of places with hardcoded configuration that I know I would need to change for my app... but no docs/comments/hints to tell me to do that? For example, using Auth0, I have a hardcoded (real) auth0 key and secret. I found it by chance. I personally wouldn't do that in a production app, as I want to centralize all config in one place. That seems like something I wouldn't be happy with

* Your docs are expansive... but could use some refinement. They are hard to navigate, especially the tutorial section, which doesn't appear to have any representation in the left nav? They also aren't navigable they way I expect docs to be (for example, https://refine.dev/docs/tutorial/getting-started/chakra-ui is not a page). I also was able to break the back button in the tutorial section.

Hopefully this is helpful, that was a lot of negative stuff, but I do want to close with overall feedback that this is a *really* hard problem and it is clear that there is a lot of potential value here.

If you want to get deeper into any of these questions, the email is in my profile, always happy to chat with companies building cool things :)


Do you all support TRPC?


I've used Retool and absolutely love it. It's a godsend for folks like me who want to create quick internal tools without delving into frontend frameworks and code. It's very drag-and-drop, intuitive, and easy to use. I describe it as MS Access on steroids.

This thing looks nothing like Retool. As other people have mentioned here, Refine "just scaffolds your codebase, gives you a good start, and has some cool hooks". So the whole "Open-Source Retool Alternative" angle seems very confusing and off-base to me. They look like very different tools built for very different audiences, imho.

Seems like you're trying to piggyback on the Retool wave. Why not just be honest (and a bit creative, perhaps) with your marketing? My $0.02


Please make your substantive points without impugning people's honesty. That's against the site guidelines: https://news.ycombinator.com/newsguidelines.html. Your comment would be fine without that last paragraph.


I agree with Retool alternative tagline here. Doesn’t make sense to me as well.

I am researching viability of no-code tools like Retool as a business and was wondering if you were developer preferring Retool over coding to save time and resources for internal tools vs a non-developer trying to take care of the business without bothering the development teams.


I've always been confused (and rather peeved) at people who refer to Retool as a low-code / no-code tool. The vast majority of our users are software engineers, and that has always been our focus. In fact, we purposely try and filter out non-engineers from signing up. They have lower conversion rates, require more support (they oftentimes ask us to teach them how to write JS), and have lower NPS.

Our target audience is the developer who doesn't believe that building a simple form (that submits a POST request) should involve: 1) installing 30 dependencies, 2) learning a new framework, 3) spending hours researching the best table library, and 4) mucking around with redux trying to figure out how to get a spinny indicator on a button.

The state of web development today is _insane_, and we want developers focusing on being productive, instead of everything listed above. (Fortunately for us, most developers agree and think that web development has gotten too complicated, especially for simple internal forms.) Developers who want to ship is our market, not "non-developers" who don't know how to code.

Perhaps we should write a blog post about this one day, hmm...

(David, founder @ Retool here.)


I see windmill mentioned a few times (founder here). I think we are both anchoring our tools around "Retool for enterprise" because Retool is known and it give a quick overview of the domain we are in: Internal tools, but the audience and pain solved by refine and windmill are likely to be quite different. Windmill caters towards software engineers that want to write powerful backend logic in typescript/python/bash/go, long running jobs and complex workflows for internal use (we compete there with temporal, airflow, airplane), and share them with the rest of their orgs with all permissions handled for them, ability to scale on large clusters, and observability baked in (full history of all executions, including args, logs, and result) AND in addition have a low-code dashboard builder similar to retool because webhooks, schedules and automatically generated UI from scripts are not always sufficient.

Refine looks more like a headless retool for software engineers that are comfortable with frontend frameworks but want an opinionated stack that is tailored toward internal uses and do not want to deal with the rest of the boilerplate, user management, and connection/management of databases etc. I could see myself preferring refine for some use-cases and would probably recommend it if you are comfortable with writing frontend and the logic is limited to CRUD. So I wish them good luck and I am happy to see such diversity in the open-source space!


> I could see myself preferring refine for some use-cases

Nice to see you giving a positive testimonial to another company with some overlap, rather than tilting at windmills




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: